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