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 loose data here? IOW can this function sleep (and 
>>> retry)?
>> It took a while to trigger the condition again, but now it happened and 
>> trying a bit
>> harder payed off. Running vdr /w following patch resulted in this log (and 
>> no overflow):

>>From receiver.h:
>   virtual void Receive(uchar *Data, int Length) = 0;
>                ///< This function is called from the cDevice we are attached 
> to, and
>                ///< delivers one TS packet from the set of PIDs the cReceiver 
> has requested.
>                ///< The data packet must be accepted immediately, and the 
> call must return
>                                     ****************************              
>       ******
>                ///< as soon as possible, without any unnecessary delay. Each 
> TS packet
>                     **************************************************
>                ///< will be delivered only ONCE, so the cReceiver must make 
> sure that
>                ///< it will be able to buffer the data if necessary.

Yes, saw that, that's why asked if it couldn't sleep after all... And is why i 
it sleep only for for short periods. ASAP is relative ;) Avoiding corrupting 
is worth some small glitches when live viewing. Now, the max 1.26s sleep is 
too much, but i'll need to run with this for a few weeks to gather some 
statistics. So far the overflow has triggered twice in three days, first time 
Receive()) some data was lost, second time the "unnecessary" delays rescued a 
few bytes.
Another way to look at this is -- given how rarely this happens i don't think 
statistically significant ;) There will likely be many more errors due to other 
during these 36h or so of recordings. So this change isn't necessary, but i'd 
like to
find out if the data loss can be avoided and it lets me monitor that.

The advantage of auto tuning the buffer sizes is that the max size can be 
cheaply, as the unneeded parts won't be used at all; i'll do this for the TS 
whether that will be enough to cope with the extra delays i'll probably find 
out in
a few days...


vdr mailing list

Reply via email to