Andrew de Quincey wrote:
On Tuesday 14 Dec 2004 18:54, Werner Hauger wrote:On Tue, 14 Dec 2004 13:08:02 +0000, Andrew de Quincey <adq_dvb@lidskialf.net> wrote:Hmm, or perhaps the CI driver should reset the CAM automatically on a retune... but that might cause other problems. My feeling is it should be up to the userspace application to reset CAMs when appropriate - anyone have any comments?AFAIK resetting the CAM takes quite a while - I don't think people would like to wait that long when switching channels...Yeah I agree. Have you seen this problem yourself BTW? Werner, when does this occur? 1) When changing from encrypted->encrypted channel?When I start VDR on an encrypted channel, decrypting works. Switching to another encrypted channel, decrypting does not work. Even switching back to the channel that worked before, decrypting does not work anymore.[..]3) unencrypted->encrypted?Unencrypted channel is fine, encrypted channel never gets decrypted.
And as you said previously, there is nothing reported in dmesg (now you've patched it to the latest fixes). If the driver fails to transfer a packet to/from the CAM, it will moan quite a lot. If there isn't anything, then I dunno if it is the driver as there is nothing else it really does - although it certainly could be an obscure bug obviously.
Klaus, is there any VDR debugging that Werner could enable to see whats happening in more detail?
Werner says the only message from VDR he sees is:
ERROR: no useful data seen within 10552440 byte of video stream.
What does this mean? It sounds like it is receiving data correctly, but that it is scrambled,
I guess that's pretty much what's happening.
implying the CAM is not actually decrypting anything after
being set up once. As the CAM is not being reset, the TS data *will* be flowing through it - its just not decrypting it.
Will VDR moan if it is unable to transfer packets to/from the CAM module after a timeout?
If the communication with the CAM fails, VDR will automatically try to re-establish it. Klaus