On 04/08/08 21:10, Arthur Konovalov wrote:
> Klaus Schmidinger wrote:
>> At this point...
>>
>>> Apr 7 09:06:41 vdr vdr: [4862] ms: 3
>>> Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
>>> Apr 7 09:06:41 vdr vdr: [4862] ms: 2
>>
>> ...the module status changed from 3 ("ready") to 2 ("present").
>> The module status is retrieved from the driver in
>> cDvbCiAdapter::ModuleStatus():
>>
>> eModuleStatus cDvbCiAdapter::ModuleStatus(int Slot)
>> {
>> ca_slot_info_t sinfo;
>> sinfo.num = Slot;
>> if (ioctl(fd, CA_GET_SLOT_INFO, &sinfo) != -1) {
>> if ((sinfo.flags & CA_CI_MODULE_READY) != 0)
>> return msReady;
>> else if ((sinfo.flags & CA_CI_MODULE_PRESENT) != 0)
>> return msPresent;
>> }
>> else
>> esyslog("ERROR: can't get info of CAM slot %d on device %d: %m",
>> Slot, device->DeviceNumber());
>> return msNone;
>> }
>>
>> So for some reason the sinfo.flags doesn't seem to have the
>> CA_CI_MODULE_READY
>> flag set any longer.
>
> Please take a look to the test code in attachment, provided by Christoph
> Pfister. With it I got the following output:
>
> root@vdr:/video/vdr/cam# ./test
> 0.000008: 3
> 0.000161: 0
> 0.014133: 1
> 1.694142: 3
>
> 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.
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
