Kodi Community Forum

Hi,

Was wondering if there was a way to force Kodi to wait a second or two before playing a channel so as to build a small buffer? When I play a channel, the buffer hovers at around 10% according to the "stats" OSD, and drops to zero every few seconds, forcing playback to stutter for a moment, and every few seconds thereafter. I can fix this by simply skipping back until the buffer is 100%. I don't know why the buffer drops at all, since no frames are skipped or dropped.

I have tried </minvideocachelevel> and </minaudiocachelevel> in advancedsettings, and they did not help. Running OE Jarvis on rPi 2, and this has been happening since Helix at least (I think). I use a file timeshift that is written to a usb stick, if that matters.

Thanks!

I already dropped minvideocachelevel and friends on my branch. Could you try those builds: http://forum.kodi.tv/showthread.php?tid=231092

I am already on those builds, #1108 I think

then something must go wrong on Pi. will check with pi devs

please post a debug log first

Log of me playing a couple of channels: http://pastebin.com/qS9fnbCj

Have you had a chance to look at this yet? Could it be a tuner problem? Using this one, if it matters: http://www.leadtek.com/eng/product/6/622/intro.aspx

I need to ping the Pi dev. Looks like the Pi audio sink reports a too small buffer size.

we will add some more logging into tonights Milhouse build. could you please post a new log tomorrow?

Sure, build #1126 when it's up?

Using build #1126: http://pastebin.com/vdAmttv6

could you please create another log? there is something strange I would like to get confirmation for.

Sure, another one: http://pastebin.com/uk9BHXiB

we added some more logging to tomorrow's build. same procedure

Log file too big for pastebin: https://www.dropbox.com/s/i06t07k8rkgfcaq/kodi.log?dl=0

With build #1130 it's harder to reproduce, since the slower channel switching forces a slightly bigger buffer (~20% usually instead of ~10%) but it happened on the last channel I played in that log

Any headway on this bug? I was mistaken in it being harder to reproduce. The long channel switch times were the cause of improperly scanned channels by VDR. Once the channels.conf is corrected, channel switches are as before, and the problem happens just as often.