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.
So does this mean that with the small test.c program the module status
is continuously going on and off, without VDR even being involved?
Can you post more than the above 4 lines from ./test (like 20 or so)?
Since cCamSlot::Reset() is the only place where resetTime is set to
a non-zero value, and you had lines like "resetTime1: 1207548401" in
your syslog_1 file, apparently the tc[i]->Process() call in
cCamSlot::Process() must have failed. If the communication with the
CAM fails, how should VDR continue to work with it?
Klaus
> 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)?
>
> Regards,
> AK
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
