XBMC buffering issues can be an annoyance while trying to watch a video on your HTPC. The problem amplifies if the video is of HD quality or if your HTPC has less available resources. Raspberry Pi, with only 512 MB of RAM and modest CPU power is prone to slow buffering. In this post, I will show you some ways to fix slow buffering on XBMC running on Raspberry Pi. These fixes should solve XBMC buffering problems in OpenELEC, Xbian, Raspbmc or a full-scale HTPC running XBMC. Note that some of the fixes for XBMC buffering issues listed below require XBMC 13 Gotham.
One of the first places to check if you have XBMC buffering problems on Raspberry Pi is your video source: Internet, USB drive, SD Card, or network attached storage.
Internet Streaming: Ensure that your router has enough horsepower and is able to fight any network interference and deliver the content to your device. On the other hand, ensure that your device is able to connect to your router at consistent speed. On Raspberry Pi, I strongly recommend using a wired connection with good ethernet cable. If you have to use Wifi, use a good compatible Wifi adapter (check this list).
USB Drive: Check this list to ensure you have a good compatible USB Drive. A slow or incompatible USB drive can may not support the bandwidth required for HD video.
Network Attached Storage: If you store your media centrally on a network attached storage or a file server, ensure that the file server protocol you are using can support the bandwidth. While Samba file server is good, if you have the option choose NFS file server. You also need to ensure that your router has the power to support the bandwidth required for streaming videos. [Read:Enable and configure OpenELEC Samba share on Raspberry Pi]
Once you have ensured that the you have minimized the source or network issues, check again to see if the Raspberry Pi XBMC buffering still exists or is too slow. If so, move on to modifying your XBMC setup configuration.
Some of the slow XBMC buffering issues can be solved by modifying XBMC configurations, especially how video cache is handled. These tweaks require editing the advancedsettings.xml file in the userdata folder. If the file does not exist one has to be created. Information on the structure of advancedsettings.xml and its location on various operating systems is available here. On OpenELEC, Xbian, or Raspbmc, it's located in these folders:
Add the following section to your advancedsettings.xml and then tweak them as explained later in this post.
<advancedsettings>
<network>
<buffermode>0</buffermode> <!-- Comment: Default is 1 -->
<cachemembuffersize>20971520</cachemembuffersize> <!-- Comment: Default is 20971520 bytes or 20 MB -->
<readbufferfactor>1.0</readbufferfactor> <!-- Comment: Default is 1.0 -->
</network>
</advancedsettings>
Note that these presets may differ with distro you use and some of the tweaks may not work on XBMC 12.X Frodo and below.
buffermode
Works on XBMC 13 Gotham and above. The buffermode sets what videos XBMC will cache. The default is 0, which will cache all videos from the internet (http, FTP, WebDAV, etc.). Listed below are other options:
1 - Buffer all videos, including local videos
2 - Buffer only true internet streams (http, strm, etc.)
3 - No buffer
If you experience XBMC stuttering while playing videos from your local network storage, then choose 1 as Buffermode. Playing from a USB drive or SD card should almost never cause XBMC buffering issues unless there is some hardware compatibility issue.
cachemembuffersize
By default XBMC allocates 20 MB for cache (note that in reality this is require 3 times more free RAM, 60 MB in this case). If you choose to cache videos, then increasing the available cache memory may help. On Raspberry Pi, with OpenELEC, Xbian or Raspbmc, I would not go beyond 40 or 50 MB (note that this requires 120 or 150 MB of free RAM) or else XBMC might crash frequently. To set cachemembuffersize to say 40 MB use 41943040 (40 x 1024 x 1024). If you are on a full-blown HTPC with say 4 GB RAM, you could go higher.
Alternatively, you could set the cachemembuffersize to 0, which would force XBMC to use your local storage (SD Card) for caching videos. In this case, the cache size is only limited by the amount of free space available. Upon stopping the video the cache is automatically cleared to free up space. Note that this will increase the read/write on your SD card, which may reduce its lifespan. But SD cards are cheap and doing this can help low RAM devices such as Raspberry Pi. But a good SD card with higher class rating is definitely recommended. [Read:10 Tweaks to improve XBMC performance on Raspberry Pi]
readbufferfactor
Works on XBMC 13 Gotham and above. The default value is 1.0, which will make XBMC cache a little above what is needed to play it back. This setting affects how much of your network bandwidth is hogged to cache the video. In my home, while I am while I am watching a video, it take priority over anything else. So setting a 2.0, 3.0, or 4.0 will that many times higher bandwidth usage. In most cases setting it at 4.0 should not cause any issues. However, if you notice any spikes in CPU usage or network bandwidth unavailability for other devices then reduce the readbufferfactor.
Recommended XBMC Cache Settings
The recommended entry in advancedsettings.xml file to reduce XBMC choppiness, stuttering, and buffering problems on Raspberry Pi is given below:
<advancedsettings>
<network>
<buffermode>1</buffermode> <!-- Comment: Default is 1 -->
<cachemembuffersize>0</cachemembuffersize> <!-- Comment: Default is 20971520 bytes or 20 MB -->
<readbufferfactor>4.0</readbufferfactor> <!-- Comment: Default is 1.0 -->
</network>
</advancedsettings>
Go ahead give these settings a try, and see your Raspberry Pi XBMC buffering issues go away. Hopefully you get to enjoy your HD videos.
Anand is a self-learned computer enthusiast, hopeless tinkerer (if it ain't broke, fix it), a part-time blogger, and a Scientist during the day. He has been blogging since 2010 on Linux, Ubuntu, Home/Media/File Servers, Smart Home Automation, and related HOW-TOs.
