Jouni Karvo wrote:

>> it will take 37000+ ms until VDR receives the stream. In the case of a
>> recording, this is simply to long as recorder.c defines a
>> MAXBROKENTIMEOUT of 30 seconds. VDR's recorder considers a stream to be
>> broken when it doesn't receive a PES packet for that time. So I'd
>> suggest to double this timeout.
> Do I understand then correctly that defining MAXBROKENTIMEOUT to for
> example 1h would fix the problem of broken recordings due to expired
> keys (so that VDR would actually be patient enough to wait until the
> stream contains the right authorization information for the Conax
> module and the stream would start and the vicious restarting cycle
> would disappear)?

The use of MAXBROKENTIMEOUT is a last resort of getting a recording
recorded when for example the driver or hardware is in a state where
only reloading the driver can help out of this situation. Prior to 1.3.x
even a lost DiSEqC message while tuning could lead into such situation
where the recorder didn't see any input.

Increasing MAXBROKENTIMEOUT might help in your case, but I would be
careful to set it simply to 1 hour. Consider the case where your
hardware/driver runs into trouble, then you would loose 1 hour of a
recording. Luca Olivetti posted a patch to this thread which initially
uses a 10 times higher MAXBROKENTIMEOUT. Maybe this could be an
acceptable solution for you, too.

Recently there was a discussion in another thread on this ML concerning
the restarting cycle in bad weather conditions, especially when you have
more than one recording running on different devices or when you are
going to replay a recording. Currently I have no idea whether there
should be a rather complex detection logic for real driver issues (given
that such a detection logic is feasible) or whether the current
detection should simply be dropped. But that's off topic in this thread.

Dipl.-Inform. (FH) Reinhard Nissl

vdr mailing list

Reply via email to