Hey all,
Got my Vero 4K yesterday and am enjoying it - except for some reason when using it the cache is at max ~187.9MB. I thought by default it was supposed to be around 500MB? I also added the advancedsettings.xml file, and even with that there it’s still ~187.9MB.
What am I missing?
Yep, that’s the expected figure.
Kodi allocated half of the cache to video and the other half to audio caching. Then it keeps 75% of the cache for read-ahead and keeps the other 25% for a reason that I’ve yet to find out, but might be some kind of fast skip back.
Generally, around 190 MB of read-ahead video cache should cover most short-term network glitches and any memory that’s not used by the audio cache is still available for the operating system to use.
Good lord. That’s really not clear at all! I upped it to 900MB and yep, now I get a “visible” 330MB. I’ll revert to default, but it’s good to know it’s working as intended, and that if I need to modify anything that I’m doing it right.
It’s not documented and was gleaned from a reading of the Kodi source code plus some helpful explanations from a developer.
Yes – that’s the definitely an understatement
As we have a chunky 2GB RAM, I think we should increase things. Thoughts @dillthedog @grahamh?
CMA prevents us from realistically falling short for video decoding, so I’d like to be a bit more aggressive.
Sam
I’m unconvinced of the need for a "chunky^ video cache.
We currently have around 190 MB of video cache. Ballpark figures: an 80 Mbit/sec average video stream is 10 Mbytes/sec. So we have 19 seconds of read-ahead cache to allow for peaks in the bitrate and/or network congestion. That ought to be enough for most situations.
The read-ahead cache is populated using spare bandwidth. Beyond 80-90 Mbits/sec the spare bandwidth becomes virtually non-existent and the cache is unlikely to be fully populated.
So the irony is that with high bitrate movies, when you really need it, the amount of read-ahead data in the cache might not be sufficient – and increasing the maximum size of the cache won’t overcome this basic limitation. For lower-bandwidth material, 190 MB should be more than enough.
That said, I think that there is possibly some scope improving the readfactor.
Agreed.
But I’ve also seen this on some material that spikes sharply. I was analysing a clip recently and it spiked from 10Mbps to 40Mbps for a couple of minutes, which is rather aggressive.
Just checking - so the cache is of the (compressed) received stream, not raw video?
And I can’t think why audio would need the same size cache as video, but if it’s shared, fair enough.
I might be wrong but I’ve always assumed that it’s a byte-for-byte copy of a portion of the video file that’s being played.