9

Every time I try to stream heavy (mostly 1080p) videos trough the network (webdav, sftp...), it either fails or I got the message “cache is full” etc. Videos start playing, but randomly stop (to buffer again, I guess).

I know this is a common issue and I know the the tweaks I can do (curl too).

The environment:

I use a RPi model B and I have a 100M/b internet connection. I’ve been testing with Kodi 14.2 and Kodi 15 (openelec 5.0.7, openelec 5.95.2).

The tests:

So far, among many additional options, this is what I tried:

Cache\Protocol | Webdav      | SFTP (local and internet)
--------------------------------------------------------------------------
No cache       | not loading | loads quickly, no error, stops frequently
--------------------------------------------------------------------------
(5mb cache)    | not loading | slow to load, cache error, stops randomly
--------------------------------------------------------------------------
(25mb cache)   | not loading | very slow to load, cache error, stops randomly
--------------------------------------------------------------------------
sdcard cache   | not loading | incredibly slow to load, no error, fine
--------------------------------------------------------------------------

Video problem?

Nope. If copied on the sd card, it runs smoothly.

RAM problem?

I would understand the hardware limitation if the RAM was full, but, while watching videos, free -m gives me this:

             total         used         free       shared      buffers
Mem:           373          236          137            4           34
-/+ buffers:                202          171
Swap:            0            0            0

It seems there are plenty available...

Interesting fact, as @goldilocks noticed, buffers is unusually low.

Network problem?

If I’m downloading a video file manually with SFTP, while playing this very same file at the same time, it works. Download speed: ~1.5MB/s. So, nor the network, nor the decryption is a bottleneck.

Other problem?

Errors in logfile (with video debug, ffmpeg debug), except debug and notices:

ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached
ERROR: OMXPlayerVideo: Got MSGQ_IS_ERROR(-1) Aborting

OK, so curl is not optimised for video streaming. But what about SFTP? It should be a piece of cake.

Configuration problem?

The last test above (sdcard cache) is interesting. It start playing the video, after dowloading about 150M (!) on the sdcard (.kodi/temp/filecache000.cache). Although it runs well, it’s not a viable solution as it is too slow to start.

It seems to try to download the same amount of RAM, ignoring the configuration in advancedsettings.xml. I checked, the file is loaded without any issue. This is an exemple of something I tested (.kodi/userdata/advancedsettings.xml):

<advancedsettings>
    <network>
        <buffermode>1</buffermode>
        <cachemembuffersize>5242880</cachemembuffersize>
        <readbufferfactor>4.0</readbufferfactor>
        <curlclienttimeout>60</curlclienttimeout>
        <curllowspeedtime>20</curllowspeedtime>
    </network>
</advancedsettings>

Note: some of these options are not longer correct in kodi 17, see @ZacWolf answer for update

So, somebody has any idea? What could be wrong here? Whatever the solution, I also want to know why normal usage (RAM buffer) fails in this case.

EDIT: Test on Archlinux

I installed kodi on Archlinux, to determine if it’s a kodi or openelec issue. It’s the same: HD videos are choppy, so it seems to be a bug in kodi. It’s more like a protocol problem (SFTP and WebDAV: http) because my test with SSHFS works great. Unfortunately, it’s not trivial to install SSHFS on openelec.

EDIT 2: A workaround

I write it here, because it doesn’t directly address the buffering problem, but I have installed kodi on Archlinux for more than a year now, and it works perfectly well. It’s less noob-friendly than openelec, but for those who are interested:

  • Install Archlinux for ARM (very easy, just follow the guide - it’s for rpi1, for more recent one, just change the platform);
  • Install Kodi (follow the Archlinux wiki guide - basically, install kodi-rbp package);
  • Enable the kodi service to automatically run kodi on startup: # systemctl enable kodi.service;
  • Install SSHFS: pacman -Suy sshfs;
  • Use the very useful SSHFS automounting with /etc/fstab to mount your distant share.

Done. Don’t forget to update frenquently (pacman -Suy).

Gui-Don
  • 191
  • 1
  • 1
  • 6
  • 150 MB may be on the high side, but 5 MB is probably too low for ~1 MB/s bitrate content if you want to avoid choppiness. I would ditch the paranoia about the SD card. You bought it to use right? If not, it will be even safer in a cool, dry cupboard somewhere. – goldilocks Jun 28 '15 at 18:00
  • Thanks for your concern. But, be aware my question isn’t about sdcard buffer alone. Second, 150M, at ~1MB/s... Yes, 150s. This IS absurdly long. Is there an option to change the buffer size when using sdcard? This could be a solution. Then, whatever the cache size, it will load the entire video (sometimes several GB) on the sdcard, not just the buffer. I know, sdcard are cheap. It’s not a big deal. I know. But why should I bother about sdcard while RAM should be working? – Gui-Don Jun 28 '15 at 18:01
  • Sorry -- I toned that down a bit after glancing back at it. I haven't used Kodi so I can't be of much help here, it was just a general observation. IMO, buffering to disk is a better strategy than buffering to RAM because if you fill up RAM 100%, the system has no disk cache left which will noticeably impact all aspects of operation. However, if you don't fill up RAM and nothing else does, what you are writing to (and simultaneously reading from) disk will certainly get put in the disk cache -- i.e., RAM, but managed dynamically by the kernel, which is what makes this a better strategy. – goldilocks Jun 28 '15 at 18:05
  • In case that's not clear: the OS uses as much uncommited RAM as it can for caching (I referred to this above as "disk cache", which is a slight misnomer, but emphasizes the fact that usually it is mostly stuff frequently read from disk). On the pi it would not be unusual for that to be all uncommitted RAM, this is the "buffers" figure from free -- so something interesting in your post is the fact that this number is relatively small. If you increase Kodi's to-disk cache, that number could/should increase while in action to about match it. – goldilocks Jun 28 '15 at 18:10
  • 1
    I saw ;) OK, I understand using the disk is better than filling up the RAM. It is a good solution to make it works, if I can reduce the needed buffer size to play the video. BTW, it seems to be a percentage, rather than an absolute amount. Still, I’m curious about what happens here. It’s odd I got so much RAM unused, even while video is buffering. – Gui-Don Jun 28 '15 at 18:20
  • About RAM and caching: yes. I thought it might be an openelec “feature”, to “save” as much RAM as possible but I don’t know if it’s an absurd guess, as this “RAM buffer” should be freed as running softwares reclaim it. – Gui-Don Jun 28 '15 at 18:29
  • It depends how Kodi's cache is implemented. The basic method would be to just allocate 100% of whatever you say, but even if it does that it won't show up immediately in free because the kernel won't actually do it, it will just pretend (this is the difference between "virtual" memory and actual RAM) and then provide it in small chunks as the application actually goes to use it. Hence, the basic method is reasonable, but it is also possible that Kodi incorporates a similarly complicated scheme itself, only asking for chunks when needed up to the maximum. – goldilocks Jun 28 '15 at 18:46
  • It might be enlightening to watch Kodi in top (get the pid and use top -p [pid] so there's only Kodi shown) with various settings, paying attention to how the VIRT and RSS figures jump around. Another test, if feasible, would be to watch a stream from another box on the same local network, to see how smoothly that goes. – goldilocks Jun 28 '15 at 18:47
  • OK @goldilocks, so I did a few monitoring with top on kodi. I set a 20MB buffer. Two videos on SFTP, for about 2 minutes: VIDEO that cause trouble (1GB x264 - ~650KB/s) and VIDEO that works well (3.5GB x264 - ~180KB/s). Pretty same figures for both, at start: VSZ: ~475M RSS: ~90M, while running: VSZ: ~505M RSS: ~100M. The main difference is how it moves during playing. With VIDEO , VSZ and RSS barely changes. With VIDEO , they both reduce (~10M). Then, VIDEO stops, and VSZ and RSS slowly go up (buffer I guess). – Gui-Don Jun 28 '15 at 21:46
  • Has this ever been resolved? otherwise try to monitor your network traffic during video playback and see if it's stable. I use nethogs for this. Also when you use an android remote called "kore" there is this 'i' (for information I guess) button that shows you some video overlay with logging information. This could prove handy. – Havnar Jan 22 '16 at 11:11
  • @Havnar, no it’s not. I finally used another solution: to get rid of openelec for now and installed an Archlinux and SSHFS (which works great). I might make this test in the future, I’ll keep this question up to date. – Gui-Don Feb 05 '16 at 11:33

3 Answers3

2

EDIT (12/2017)

Kodi v17 renamed and relocated tags in advancedsetting.xml

<cachemembuffersize> renamed to <memorysize>

<readbufferfactor> renamed to <readfactor>

AND they've been removed from <network> and added to <cache>

My advancesettings.xml now looks like:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>
ZacWolf
  • 140
  • 5
  • This is specifically for a Vero4K device, which has more memory that a Pi, so you'll need to tweak these settings specific to your available memory. – ZacWolf Dec 04 '17 at 19:06
1

I am running Pi 3 with OpenElec on it and I ran into lots of buffering issues as well.

I was streaming to it over Wi-Fi as I figured it was right next to the router and shouldn't have any issues. Well after plugging in via Ethernet I got to remove the advanced xml file all together as the buffering issues stopped.

My laptop and phone both play fine via Wi-Fi without buffering so something with the Pi 3's built-in Wi-Fi on OpenElec is causing the issue.

Darth Vader
  • 4,206
  • 24
  • 45
  • 69
Marcus
  • 11
  • 2
  • I’m glad you fixed your issue and I’m sure it’ll help lots of people who ran into this problem. In my case I used ethernet from the beginning though. For rpi1 I don’t think this is the solution. That being said, it’s strange you had a similar problem on rpi3, as it has twice as much RAM as rpi1… I can be wrong but it seems cache handling on kodi is just crappy. – Gui-Don May 15 '16 at 16:52
-1

I had the same problem and I used this 'hack', things run smoothly now.

--- edit --- Following @Simulant suggestion:

  • Install xunity maintenance tool.
  • Got into program (not settings), xunity - tweaks.
  • Select 'Add 0 Cache Advanced XML
Meir
  • 99
  • 2
  • 1
    Please line out the key fakts from your linked source. Otherwise if the linked source would get offline your post would be useless. – Simulant Sep 24 '15 at 08:46
  • 1
    Isn’t Xunity just a GUI for that purpose? I mean, how is it different from tweaking the advancedsettings.xml file myself? Actually, I did the no cache setting, it is way to slow to load for SFTP or webdav videos. – Gui-Don Oct 10 '15 at 10:50
  • It is a gui. But from my experience direct editing can be tricky (due to permissions etc.). The addon works nicely, I used it :-) – Meir Oct 10 '15 at 10:52