On 04/08/08 23:46, Christoph Pfister wrote:
> [ sorry for breaking thread - but people don't seem to honor CC ]
Sorry, my MTA automatically inserts a Reply-to header for messages
coming from the VDR-ML.
> On 04/08/08 22:49, Klaus Schmidinger wrote:
> <snip>
>>> And explanation:
>>> After a reset CAM is "absent" for a very short time (<14ms == less than
>>> a scheduler tick) and then it takes ~1.7s to become ready again. (The
>>> intervall between reset and status query seems to be a bit bigger in vdr
>>> - so we only see the 3-->1 change == 3-->2 in vdr numbers).
>>>
>>> It's an endless loop: cam detection --> cam reset --> cam not
>>> present/ready for a short while --> vdr thinks cam has been physically
>>> removed --> cam detection --> cam reset etc.
>>>
>>> Big thanks to Christoph for assistance.
>>>
>>> Is it realistic to hope for a workaround/solution for this kind of CAMs
>>> (Technotrend CX at my case)?
>> Since this apparently happens also without VDR, I guess it will have to
>> be fixed in the driver.
>
> No. If you issue a reset, you have to deal with its consequences. And
> one obvious consequence is that the cam is unusable for a certain time
> (and thus reports not-ready).
The CAM reports 3 ("ready") for several seconds...
Apr 7 21:20:37 kali vdr: [23845] CAM DEBUG: ms: 3 resetTime: 0
...
Apr 7 21:20:39 kali vdr: [23845] CAM DEBUG: ms: 3 resetTime: 0
...and then all of a sudden falls back to 2 ("present")..
Apr 7 21:20:39 kali vdr: [23849] CAM DEBUG: ms: 2 resetTime: 1207592439
...and I guess that's where the tc[i]->Process() call in cCamSlot::Process()
fails and triggers a reset.
Maybe additional debug output could shed more light on this.
However, my CAMs here all work fine, so I'm afraid I can't help much here.
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
