Kodi Community Forum

Full Version: Video cache settings, some problems
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm trying to understand how the settings explained here are intended to work: http://kodi.wiki/view/HOW-TO:Modify_the_video_cache

I set this up in advancedsettings.xml (correctly placed and confirmed by logs):


First of all, the playback info (O) report something around 218MB of cache being filled. Shouldn't it be higher? I have 16GB of RAM on the machine where I'm testing this, it shouldn't be a problem.

Second, on local files, the file starts pretty instantly (understandably), with the cache pretty much already filled to 218MB. The same file, played through a virtual drive (I'm using NetDrive2, accessing Google Drive) fills abou the same amount of cache but it waits a lot before starting, stating that it's "buffering". Now if I revert to standard cache settings, eliminating the entries in advancedsettings.xml, this doesn't happen.

The same holds true when seeking. I sometimes see the cache filling up to 60MB or so before playback resuming. And it doesn't make any sense.

It's as if, according to some of the above settings, there's a certain minimum amount of buffer that Kodi "thinks" it's needed before starting playback.

The real problem is that this happens, with the above settings, even when accessing "local" SMB resources, and that's more problematic for me than the gDrive stuff (which is more or less archival material).

Is this something already known? Expected behaviour?

I see this happen, more or less with no differences, with both 14.2 and 15 nightlies.

To have cache working (assuming I'll manage to have it work correctly) with SMB shares, do I need buffermode 0 or buffermode 1?
v14 and earlier would sometimes miscalculate when it needed to stop and buffer, but that should be a lot more accurate in v15 nightlies. Can you get us a debug log for when you try this with a v15 nightly?
Ok, here's the log for cache set up with huge buffer:


And here with the same settings REMed out:


Both files played back were bluray remuxed in mkv container, so high bitrate.
With the first configuration, when seeking, I had to wait several seconds for the buffer to fill up and even the movie took several seconds to start.
With the second configuration, everything was much faster.

This makes me think that Kodi waits for the buffer to be reasonably full (but not completely full, this I could tell from the O statistics, which showed that the buffer was filling up even after the movie started/restarted) and I think, while reasonable, the user should have the choice. With a fast enough connection is more a failsafe in case the connection temporarily drops (at least, for me that would be the case).

I also repeat my question: To have cache working (assuming I'll manage to have it work correctly) with SMB shares, do I need buffermode 0 or buffermode 1?

Thank you.
SMB requires buffermode 1. The log shows a bunch of stuff that doesn't seem quite right, but one of the devs will be needed to tell us what it means.
While waiting for a dev, I humbly suggest an extra setting for buffermode that distinguishes between real local files and files accessed remotely (even through SMB, I mean... people could have an hectic wi-fi connection to access SMB but being perfectly fine with no extra buffering for real local files).

Thanks Ned for your help and assistance.
In any case, even with nothing in advancedsettings.xml and with a network that hits a sustained 170Mbps (it's gigabit etherne) if I copy the file from the server to the HTPC, while playing back a high bitrate file (BD remuxes) that often hit 30Mbps or more... well, network utilization stays around 2.5% (25Mbps)... and after a while the movie starts stuttering, while cache goes to 0%. This with bandwidth to spare... it's as if Kodi is not "asking" for the file fast enough, given its bitrate. This on Isengard Beta 1.

Edit: this seems to happen especially with files where I seek (again, with no special settings under advancedsettings.xml) or resume from a certain point (movies partially watched).
Trying to be thorough, I installed a portable version of 14.2 and it shows no sign of this. When I seek cache rapidly grows in percentage, with Isengard it barely moves from 0% before stuttering begins. If I pause the video it grows to 100% then rapidly falls. Again, Helix good, Isengard bad. I think there must be a bug somewhere. Same machine, same ethernet.

Edit 2: Helix displays the aforementioned problems with the network settings, that led me to open this thread. But at least with regular settings it worked correctly when seeking and pausing.
A new log with today's nightly.

I play back Guardians of the Galaxy muxed into mkv. I start from the beginning. Everything seems fine. I seek, cache is not filling up and frames are lost like there's no tomorrow. I pause, cache fills up. Unpause, cache gets consumed fast and frames are lost once more. I stop the movie and exit Kodi.


The reason I provide this new log is that I updated to the latest nightly but also that, with the same exact version, on an untouched portable install on the server, while getting the same file from the HTPC (which I previously copied over for the test), I do not get the same problem. There might be something in the HTPC configuration that creates a problem.


Last test. I installed both Helix and Isengard (today's nightly) on the HTPC, in portable mode. With no advancedsettings.xml both seem to work fine, as soon as advancedsettings is added to the mix, with network section, they both fail in the same way.
So I basically have two problems ongoing. One is what causing the problems with my regular install in the log in this post (http://xbmclogs.com/p3pj3ajnc)? The other is of concern because it appears that the network settings for managing the cache under advancedsettings.xml lead to problems in any combination of version or machine.
Should I be posting a bug on Trac?
I can't find anything already on Trac, so if you could add a new ticket then that would be very appreciated.