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



_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to