[ sorry for breaking thread - but people don't seem to honor CC ]
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).
Klaus
Christoph
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
-
Christoph Pfister -
Klaus Schmidinger