Kodi on Linux buffers video ahead of playback to smooth over network hiccups and slow storage, and the advancedsettings.xml file is where you control how aggressively it does that. The defaults are conservative, tuned for devices with limited RAM, which means a Linux box with memory to spare is leaving buffering performance on the table. A few well-chosen settings turn a stutter-prone stream into a calm one, especially on a Raspberry Pi pulling media over the network.
How Kodi's buffering works
Kodi reads ahead from the media source into a memory buffer, then plays from the buffer rather than directly from the source. When the source delivers data unevenly, a Wi-Fi hiccup, a busy NAS, a slow USB drive, the buffer covers the gaps and playback continues smoothly. The buffer has a target fill level; when playback starts, Kodi fills the buffer first, which is why there is a brief delay before the video begins, and then maintains it during playback.
Two things limit the buffer's effectiveness: its size and the read rate. A small buffer empties quickly when the source stalls; a slow read rate cannot refill it fast enough when the source recovers. The advanced settings control both, and tuning them to the machine's actual capabilities is the whole exercise.
The key settings and what they do
The memory size setting controls how much RAM Kodi dedicates to the read-ahead buffer. The default is modest; on a machine with a gigabyte or more of free RAM, increasing it substantially gives the buffer real depth. Set it in bytes, and size it to what the system can spare without starving the OS and Kodi itself: a few hundred megabytes is a reasonable target on a well-provisioned Linux box, less on a memory-constrained Pi.
The read rate factor controls how aggressively Kodi fills the buffer relative to the playback rate. A factor of 1.0 reads just fast enough to keep up; higher values fill the buffer faster when bandwidth is available, which means the buffer recovers quickly after a stall. Setting this too high on a slow network accomplishes nothing, since the source is the limit, but on a healthy local network a higher factor builds the buffer cushion fast.
The buffer mode setting controls which sources get buffered: local files, network filesystems, internet streams, or all of the above. The default skips buffering for local files on the assumption that local storage is fast and reliable, which is usually true for internal drives but not always true for USB drives or SD cards. If local playback stutters, enabling buffering for local sources is worth trying.
Sizing for the Raspberry Pi
The Pi's limited RAM constrains the buffer size, and its network interface constrains the fill rate. On a Pi, allocate a modest buffer, enough to ride through a few seconds of network interruption but not so much that the system starts swapping. The Pi's shared memory architecture means the GPU's allocation also counts against the total, so check how much RAM is actually free before sizing the buffer.
For Pi-based media centers, the network is usually the real bottleneck, not the buffer size. A wired connection transforms buffering behavior more than any settings change; if the Pi is on Wi-Fi and struggling, the advanced settings can mitigate but not cure. Fix the network first, then tune the buffer to match.
Writing and testing the configuration
Create or edit advancedsettings.xml in Kodi's userdata directory, add the cache settings block, and restart Kodi. Test with the most demanding content on the most marginal source: a high-bitrate file over the slowest network path the setup will see. Watch for the symptoms the buffer is meant to cure: brief pauses, audio dropouts, and the buffering spinner.
Change one setting at a time and re-test. Buffering behavior interacts with the network, the source, and the content in ways that resist prediction, so empirical tuning beats theory. When the worst-case content plays cleanly, the configuration is done; resist the urge to keep increasing the buffer, since unused buffer is just RAM Kodi cannot use for anything else.
When buffering is not the problem
Not every stutter is a buffering problem. If playback stutters on local files with the buffer full, suspect decoding performance: the Pi struggling with a codec or a bitrate beyond its hardware decoding. Check whether the stutter correlates with scene complexity rather than network conditions. Buffering fixes delivery problems; it cannot fix a processor that cannot decode the stream.
Size the buffer to the machine's RAM, set the read rate to match the network, enable buffering where the source needs it, and test against the worst case. Smooth playback is a buffer deep enough to cover the gaps the source actually produces.
Related Guides
- ALSA Audio Buffer Tuning on Linux Centers: Audio dropouts on a Linux media center, the tiny clicks, pops, and gaps that ruin music and dialogue, almost always trace back to buffer sizing in
- Hardware Video Decoding Buffers in Libreelec: LibreELEC turns a Raspberry Pi into a dedicated Kodi media center, and smooth playback depends on hardware video decoding: the Pi's GPU decoding the
- Configuring PulseAudio Buffer Latency for Streamers: For a streamer, audio latency is not an abstract number. It is the delay between your mouth moving and your voice reaching the broadcast, the gap
- HDMI EDID Handshake Overrides on Headless Servers: A headless server has no monitor, but its GPU does not know that: the graphics hardware expects an EDID handshake, the display's self-description of