Hi, 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. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx
