> Patch below changes the interpretation of the 'Size' parm given when creating a buffer from a
> fixed length to a max limit. The buffers start out much smaller (currently 128k, instead of many
> megabytes) and grow automatically when they become almost full. This way all callers benefit,
> and they don't have to be modified at all.
> I've tested this on two vdrs for a few hours and it seems to work, but it needs a lot
> more testing.
I did a few test recordings (total duration likely more than 24h) and the new code
seems mostly fine; just some tweaking of the sizes and grow heuristics left.
However one problem did appear after many hours of simultaneous recordings:
08:17:38 vdr: [24052] buffer usage: 70% (tid=24051)
08:17:39 vdr: [24052] buffer usage: 80% (tid=24051)
08:17:39 vdr: [24052] buffer usage: 90% (tid=24051)
08:17:39 vdr: [24052] buffer usage: 100% (tid=24051)
08:17:39 vdr: [24052] ERROR: 1 ring buffer overflow (61 bytes dropped)
08:17:45 vdr: [24052] ERROR: 9053 ring buffer overflows (1701964 bytes dropped)
08:17:47 vdr: [24052] Enlarging ring buffer "Recorder": 442368 bytes
08:17:47 vdr: [24052] buffer usage: 0% (tid=24051)
Apparently the 'Recorder' consumer stalled for several seconds at a point when
growing the ringbuffer wasn't possible - to keep Get/Put lockless resizing is
only possible when the ringbuffer data is continuous; and if the consumer stops
making progress at the wrong moment, the buffer will not be enlarged and overflow.
In this case the buffer was ~300k and ~2m would have been needed.
I can think of a few ways to make the ringbuffer growing more aggressive, but
they all make the buffer handling much more complex, so i'd like to avoid that.
Looking at the caller:
void cRecorder::Receive(uchar *Data, int Length)
{
if (Running()) {
int p = ringBuffer->Put(Data, Length);
if (p != Length && Running())
ringBuffer->ReportOverflow(Length - p);
}
}
it simply drops any data that does not fit into the buffer, which would be fine
for live viewing, but isn't ideal when recording.
Can we try harder not to loose data here? IOW can this function sleep (and retry)?
(not that i think doing this would be enough; it could help for short stalls, but
for the longer ones a much larger buffer size is necessary, i'll have to find a
clean way to handle that anyway. It's kind of hard to test though as the overflow
only happened once during ~24h of recording...)
artur
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
