That to me indicate some other issue with the caching logic that might be
the explanation of wlan caching madness. That CFileCache logic should be
almost transparent when empty.

Please try to find out the real cause since it's likely affecting others
too not just the RBPI.


On Fri, Nov 1, 2013 at 1:11 PM, arnova <notifications@github.com> wrote:

> In xbmc/filesystem/File.cpp:
>
> >
> >      if (m_flags & READ_CACHED)
> >      {
> >        // for internet stream, if it contains multiple stream, file cache need handle it specially.
> > -      m_pFile = new CFileCache((m_flags & READ_MULTI_STREAM)!=0 && isInternetStream);
> > +      m_pFile = new CFileCache((m_flags & READ_MULTI_STREAM) != 0 && URIUtils::IsInternetStream(url, true));
>
> @popcornmix <https://github.com/popcornmix>: Yeah it's maxing out on cpu
> and the busy indicator seems to spin forever so there's still some activity
> but the video never starts playing. I've obviously tested all cases with
> the same file(s). The problem is debugging this on RPi itself.
>
> Do note that I also tested sftp + always-buffer and that does work
> (although video starting is quite slow). My best guess is that due to the
> cpu maxing out, one (or more) threads (either DVDPlayer's or Curl's) die
> off.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/xbmc/xbmc/pull/3429/files#r7367773>
> .
>