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):


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).

  • 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
    Commented Jun 28, 2015 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
    Commented Jun 28, 2015 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
    Commented Jun 28, 2015 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
    Commented Jun 28, 2015 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
    Commented Jun 28, 2015 at 18:20

3 Answers 3


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"?>
  • 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
    Commented Dec 4, 2017 at 19:06

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.

  • 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
    Commented May 15, 2016 at 16:52

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
  • 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
    Commented Sep 24, 2015 at 8: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
    Commented Oct 10, 2015 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
    Commented Oct 10, 2015 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.