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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
