[vdr] CAM auto resetting - feature request??

[Simon Baxter]

>> I was afraid that might be the suggestion!
>>
>> It seems pretty random when the CAM will crash.  It is possible it's
>> only on certain channels, and only one of the CAMs - it only happens
>> very rarely....
>
> So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
> and exactly one of them sometimes fails, right?
>
> Have you tried swapping the two CAMs?
> This should tell us whether the problem is with the CAM or with
> the CI adapter.
>
> Klaus

I've discovered this happens to both CAMs, so it's either not a hardware 
issue, or both CAMs are affected.

Managed to capture the following logs prior to the CAM dropping from 
"AlphaCrypt" to "CAM Ready" (with no decrypting)

Sep  2 08:17:21 freddy vdr: [27702] switching to channel 11
Sep  2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702, 
tid=1150)
Sep  2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
Sep  2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702, 
tid=6564)
Sep  2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended 
(pid=27702, tid=1152)
Sep  2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
Sep  2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended 
(pid=27702, tid=1151)
Sep  2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started 
(pid=27702, tid=6565)
Sep  2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started 
(pid=27702, tid=6566)
Sep  2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
Sep  2 08:17:34 freddy vdr: [27702] switching to channel 1
Sep  2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702, 
tid=6564)
Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS continuity 
errors
Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS continuity 
errors
Sep  2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
Sep  2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702, 
tid=6567)
Sep  2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended 
(pid=27702, tid=6566)
Sep  2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
Sep  2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended 
(pid=27702, tid=6565)
Sep  2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started 
(pid=27702, tid=6568)
Sep  2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started 
(pid=27702, tid=6569)
Sep  2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702, 
tid=6567)
Sep  2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread ended 
(pid=27702, tid=6569)
Sep  2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
Sep  2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended 
(pid=27702, tid=6568)
Sep  2 08:17:39 freddy vdr: [27702] switching to channel 1
Sep  2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
Sep  2 08:17:39 freddy vdr: [27702] info: Channel not available!
Sep  2 08:17:41 freddy vdr: [27702] switching to channel 9
Sep  2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702, 
tid=6570)
Sep  2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on 
device 0: Input/output error
Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on 
device 0: Input/output error
Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on 
device 0: Input/output error
Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and 
initialised successfully


I've done the usual "select and reset the CAM 3 times from VDR" and it's 
back in action.

Any ideas on how to further debug this?    AND   any suggestions on how I 
should configure VDR to send an email alert when this problem occurs?  I 
could probably hack dvbci.c to send an email or something??


Thanks
Simon