Be careful of altering the caching settings

Hi learnt the hard way today that there are often unforseen consequences of changing settings.
I was having glitching on my music playback (not video) which altering the caching settings helped cure. These were the advancedsettings.xml that I applies:


Only later did I notice that kodi would no longer play any network shared file larger than 2gb, after much searching for the cause I finally remembered my changes to caching and removed them and hey presto large files would play again.

Just an educational lesson for me, and a lot of wasted time finding the cause.


Do You remember ?

I learnt it a few years ago wasting a lot of time.

Kodi Wiki: HOW-TO:Modify the video cache

It never suggested that it would clamp a 2gb limit on files in those instructions.


Note: For the memory size set here, Kodi will require 3x the amount of RAM to be free. Setting this too high might cause Kodi to crash if it can’t get enough RAM.

Thats not what happened, and there was no warning that it would impose a size limit on files.


Very odd that it had that effect. The default cache Kodi uses is 20mb, which requires 60mb of free RAM. Your setting is only set to 50mb, which I’m certain you have 150MB free RAM available. Perhaps it’s because you never set a readfactor in your file?

Try <readfactor>25</readfactor> and take it for another spin…

My advancedsettings.xml file is set to use 1024mb (3GB free RAM) and I never have any issues playing anything. In fact, I can fast forward/rewind streaming 4K files in 10 minute increments with no issues at all (over WiFi). My box would feel crippled if I didn’t use this file.

Below are the exact settings I have. Feel free to take them for a test drive:


P.S. - My N2 has 4GB RAM. If yours only has 2GB, then use 500mb instead:
Or if you have many services running hogging up RAM… go even smaller, 333mb (requires 1GB free RAM):

P.P.S. - any time you change this file… do a reboot after.

1 Like

I have just discovered that at least part of my issue is related to problems accessing FAT32 drives over a SMB share. This seems to be an unstable combination on Linux systems. I have just migrated my media drive to ext4 and not only is it significantly faster on read/write it also seems to have resolved other issues I was facing with large files. I would say that I should be OK on standard caching given the increase in file access responsiveness.

See this link for a description of the SMB+FAT32 issue:


That didn’t even cross my head! We’re dealing with HD files so FAT32 hasn’t been in my radar for some time. lol

I set the drive up a few years ago with the intention of maintaining maximum compatibility with windows just in case. A stupid decision at the time since I have no windows machines, and even more stupid when you consider it took me most of the day to migrate it off FAT32 :rofl:

It seems its the glacial speed of accessing the FAT32 drive which causes the problems.


Good catch.

Hi I did a bit of research on this in this post.