Hi folks, I hate to follow up on myself, but as it appears I cheered too soon. It now also happens reproducibly when recording, and independent of vnsiserver or anything else. The machine has been up for 4 days, and when starting a new recording, this is what happens after some seconds: Feb 9 11:41:37 seneca vdr: [624] i/o throttle activated, count = 1 (tid=624) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 60% (tid=623) Feb 9 11:41:46 seneca vdr: [624] buffer usage: 70% (tid=623) Feb 9 11:41:51 seneca vdr: [624] buffer usage: 80% (tid=623) Feb 9 11:41:55 seneca vdr: [624] buffer usage: 90% (tid=623) Feb 9 11:41:59 seneca vdr: [624] buffer usage: 100% (tid=623) Feb 9 11:41:59 seneca vdr: [624] ERROR: 1 ring buffer overflow (1 bytes dropped) Feb 9 11:42:05 seneca vdr: [624] ERROR: 31446 ring buffer overflows (5911848 bytes dropped) Feb 9 11:42:11 seneca vdr: [624] ERROR: 32635 ring buffer overflows (6135380 bytes dropped) (needless to say the recording is entirely crippled.) VDR is 2.2.0, plain but with PLAYERBUFSIZE and RECORDERBUFSIZE enlarged to 50 megs each. As I suspected earlier, enlarging the buffers only cures the symptom. It's only a matter of time. As if memory regions and pointers weren't cleanly free()'d but reused next time instead of malloc()ing new ones. Looking at the cRingBufferLinear class this seems to be the case. But how can this persist across VDR restarts? I'm puzzled. Restarting VDR, reloading the DVB drivers (dddvb-0.9.22 from Digital Devices) does not remedy the overruns. Only restarting the machine does. If anyone had an idea where to look, that would be great. e.g. were there any significant changes in the TS buffer code between 2.2.0 and devel-latest? I'm a bit reluctant to try 2.3.x because some plugins may not work with it. TIA! On Mon, Feb 08, 2016 at 08:17:08AM +0100, Harald Milz wrote: > Richard, > > On Sun, Feb 07, 2016 at 12:34:17PM +0000, Richard F wrote: > > One of the things that the vnsi developer said to do set this in the VDR > > config > > > > vnsiserver.AvoidEPGScan = 1 > > (http://forum.kodi.tv/showthread.php?tid=203396) > > Now that you mention it - I also see interruptions sometimes when Kodi appears > to update its timers. That is, when it scans through the timer list, > displaying the respective message windows bottom left. Sometimes, live > streaming just crashes, and needs to be restarted manually. > > I'll give AvoidEPGScan = 1 a try - thank you! > > > I don't know where PLAYERBUFSIZE is - Kodi config file - which one? > > No, that's in vdr: > > dvbplayer.c:#define PLAYERBUFSIZE MEGABYTE(1) > > and > > recorder.c:#define RECORDERBUFSIZE (MEGABYTE(10) / TS_SIZE * TS_SIZE) // > multiple of TS_SIZE > > Please not that it really cures only the symptom. If there is a problem with > filling any emptying the buffer, leading to an overrun, then it will > eventually happen, no matter what the size is. So far, I haven't seen this > yet with 50 megs each. > > -- > A gift of a flower will soon be made to you. -- Never be led astray onto the path of virtue. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
