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