Klaus Schmidinger wrote:
> On 05/09/07 20:56, Artur Skawina wrote:
>>> void cRecorder::Receive(uchar *Data, int Length)
>>> 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 lo
On 05/09/07 20:56, Artur Skawina wrote:
>> 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 dat
> 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
> 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,
vdr uses quite a lot of memory, RSS here used to be ~70M, so i decided to see
if it could be
reduced a bit. First suspects became the ringbuffers, cause i was seeing a lot
of log lines
such as "buffer stats: 96068 (1%) used". Turns out many buffers are way over
sized, only a few
percent of the m
