hi, I agree this is a off-topic... (but I hope on topic for the mailing list anyway) Reinhard Nissl writes: > 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. I understand that, and I also understand that some people have unstable hardware/drivers. I just wonder if this is the right way to deal with it. As I told in an earlier post, I have removed the driver reloading stuff from my runvdr script and had no problems whatsoever. > 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. The problem is that it can take quite a long time before there is a new authorization packet in the programme stream. As far as I understand, they are customer (or smart card) specific and tell the card which streams it is allowed to allow decrypting, and naturally it is not very useful to spend a very high percentage of the stream for these authorization things. Another solution that has come to my mind is a patch that would tune free cards to the muxes that contain CA stuff. This way they could receive the authorization information and could possibly have new key info whenever it is changed instead of just trying their luck when they should start a recording. But I do not know whether this would work. And it would not be a very beautiful solution in my mind. Btw. I just concluded from this mailing list a couple of weeks ago that I am not the only one with this CA problem. Of course I might have made the wrong conclusion, though. And, my current solution is not to record from encrypted channels. It works quite well. > 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. I would guess that if your driver hangs it might be difficult to distinguish from the case of just waiting for the worst shower to pass or the encryption authorization to arrive. yours, Jouni
