Hello
My v 1.6.0 system has 2x Alphacrypt multi-CAMs.
Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both.
I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back.
Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed".
My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state
or
2)Be notified, by generating a console/kernel message, so I can know to come in and fix this.
Any ideas?
Hi!
Got the same problem here, would be nice to have at least a possibility to check for crashed CAM's per SVDRP and maybe the possibility to reset it.
Regards
Marco
Simon Baxter schrieb:
Hello
My v 1.6.0 system has 2x Alphacrypt multi-CAMs.
Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both.
I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back.
Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed".
My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state
or
2)Be notified, by generating a console/kernel message, so I can know to come in and fix this.
Any ideas?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 03.08.2009 22:54, Simon Baxter wrote:
Hello
My v 1.6.0 system has 2x Alphacrypt multi-CAMs.
Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both.
I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back.
Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed".
My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state
or
2)Be notified, by generating a console/kernel message, so I can know to come in and fix this.
Any ideas?
I would prefer alternative 3: find out why the CAM "crashes" and fix that ;-)
Klaus
Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both.
I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back.
Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed".
My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state
or
2)Be notified, by generating a console/kernel message, so I can know to come in and fix this.
Any ideas?
I would prefer alternative 3: find out why the CAM "crashes" and fix that ;-)
Klaus
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....
On 16.08.2009 21:38, Simon Baxter wrote:
Occasionally one of the CAMs seems to "crash" and if I go into Setup > CAM one of the CAMs changes from "Alphacrypt" to "CAM Ready" - and will no longer decrypt channels. I then correspondingly get a bunch of timer conflicts, as 1/2 my CAM resources have vanished. Only ever one CAM fails, never both.
I rectify this by selecting the CAM, and then hitting "reset" (sometimes a couple of times) - and it comes back.
Unless I go into the Setup > CAM menu, I'm unaware that the CAM has "crashed".
My request is...... Is there a way I can either 1)Automatically reset a CAM if it falls into this state
or
2)Be notified, by generating a console/kernel message, so I can know to come in and fix this.
Any ideas?
I would prefer alternative 3: find out why the CAM "crashes" and fix that ;-)
Klaus
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 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
On 01.09.2009 23:38, Simon Baxter wrote:
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
This looks more like a driver bug to me.
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)
This looks more like a driver bug to me.
Klaus
Can I do a "CAM Reset" from svdrp?
On 08.12.2009 18:36, Simon Baxter wrote:
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)
This looks more like a driver bug to me.
Klaus
Can I do a "CAM Reset" from svdrp?
There is no direct SVDRP command for this, but you could send the appropriate HITK command sequence. Or you write a plugin that implements a "CAM reset" command (see PLUGINS/src/svdrpdemo for an example).
Klaus
Hi, On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
On 01.09.2009 23:38, Simon Baxter wrote:
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
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb / linux-media mailinglist for that problem.
@Klaus: If that problem happens, a manual reset of the cam under vdr's menu->settings->ci brings the cam back.
What about trying to reset a cam automatically when it's Status is != msReady?
Like this: diff --git a/device.c b/device.c index 681049b..7904de2 100644 --- a/device.c +++ b/device.c @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView if (Channel->Ca() >= CA_ENCRYPTED_MIN) { for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) { SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used + if (CamSlot->ModuleStatus() == msPresent) + CamSlot->Reset(); if (CamSlot->ModuleStatus() == msReady) { if (CamSlot->ProvidesCa(Channel->Caids())) { if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
On 01.12.2010 16:28, Halim Sahin wrote:
Hi, On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
On 01.09.2009 23:38, Simon Baxter wrote:
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
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb / linux-media mailinglist for that problem.
@Klaus: If that problem happens, a manual reset of the cam under vdr's menu->settings->ci brings the cam back.
What about trying to reset a cam automatically when it's Status is != msReady?
Like this: diff --git a/device.c b/device.c index 681049b..7904de2 100644 --- a/device.c +++ b/device.c @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView if (Channel->Ca() >= CA_ENCRYPTED_MIN) { for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) { SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot->ModuleStatus() == msPresent)CamSlot->Reset(); if (CamSlot->ModuleStatus() == msReady) { if (CamSlot->ProvidesCa(Channel->Caids())) { if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
Have you tested this? Did it actually work?
Klaus
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
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb / linux-media mailinglist for that problem.
@Klaus: If that problem happens, a manual reset of the cam under vdr's menu->settings->ci brings the cam back.
What about trying to reset a cam automatically when it's Status is != msReady?
Like this: diff --git a/device.c b/device.c index 681049b..7904de2 100644 --- a/device.c +++ b/device.c @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView if (Channel->Ca() >= CA_ENCRYPTED_MIN) { for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) { SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot->ModuleStatus() == msPresent)CamSlot->Reset(); if (CamSlot->ModuleStatus() == msReady) { if (CamSlot->ProvidesCa(Channel->Caids())) { if(!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
Have you tested this? Did it actually work?
Klaus
Will give it a try and report back....
hello Klaus,
I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module
always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says "channel not available" if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
maybe its a general vdr 1.7.x cam handling problem
any idea - what I can do or test to identify where the problem is?
thanks
marco
On Mon, 13 Dec 2010, Simon Baxter wrote:
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
This looks more like a driver bug to me.
Well maybe but unfortunately responds to my mails in linux-dvb / linux-media mailinglist for that problem.
@Klaus: If that problem happens, a manual reset of the cam under vdr's menu->settings->ci brings the cam back.
What about trying to reset a cam automatically when it's Status is != msReady?
Like this: diff --git a/device.c b/device.c index 681049b..7904de2 100644 --- a/device.c +++ b/device.c @@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView if (Channel->Ca() >= CA_ENCRYPTED_MIN) { for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) { SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot->ModuleStatus() == msPresent)CamSlot->Reset(); if (CamSlot->ModuleStatus() == msReady) { if (CamSlot->ProvidesCa(Channel->Caids())) { if(!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) {
Have you tested this? Did it actually work?
Klaus
Will give it a try and report back....
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------------------------------------------- AMMEC - Accessible MultiMedia Entertainment Center
http://www.ammec.de Support Telefon: +49 6421 968255
hello Klaus,
I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module
always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says "channel not available" if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
maybe its a general vdr 1.7.x cam handling problem
any idea - what I can do or test to identify where the problem is?
thanks
I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get "channel not available", but haven't found any way to recreate the problem at will.
I also occasionally have a CAM crash - where the status in goes from "ALPHACRYPT" to "CAM PRESENT" or "CAM READY". A manual reset (or multiple) fixes this, but I get no decryption during a "crash".
...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels.
On 12/23/10 00:14, Simon Baxter wrote:
hello Klaus,
I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module
always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says "channel not available" if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
maybe its a general vdr 1.7.x cam handling problem
any idea - what I can do or test to identify where the problem is?
thanks
I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get "channel not available", but haven't found any way to recreate the problem at will.
I have exactly this aswel. It happens from 'surfing channels'. Never happens while watching the same channel continuously. Cannot say for sure it doesn't happen when surfing within the same bouquet.
I also occasionally have a CAM crash - where the status in goes from "ALPHACRYPT" to "CAM PRESENT" or "CAM READY". A manual reset (or multiple) fixes this, but I get no decryption during a "crash".
Yep, also this, only for "Conax Conditional Acess". Resetting it works best when using an FTA channel it seems.
...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels.
I'm looking at an oscam solution right now, but need to get a proper card reader, or try to get my old towitoko chipdrive going.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi, This Problem is really strange. I have also tested it with different kind of hw combinations and got always the same result. I don't like the answers like use and ... plugin etc. I have asked many times in vdr-portal's irc channel about this problem and got not one useful answer.
Well except the ff card I have now tried all available dvb-c cards which support a ci interface.
@Klaus: It would be really nice if you can have a look into this. Regards Halim
On 12/23/10 00:14, Simon Baxter wrote:
hello Klaus,
I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module
always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says "channel not available" if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
maybe its a general vdr 1.7.x cam handling problem
any idea - what I can do or test to identify where the problem is?
thanks
I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get "channel not available", but haven't found any way to recreate the problem at will.
I have exactly this aswel. It happens from 'surfing channels'. Never happens while watching the same channel continuously. Cannot say for sure it doesn't happen when surfing within the same bouquet.
I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA. I sometimes get these messages when watching FTA too, when encrypted channels are recording and changing in the background.
I also occasionally have a CAM crash - where the status in goes from "ALPHACRYPT" to "CAM PRESENT" or "CAM READY". A manual reset (or multiple) fixes this, but I get no decryption during a "crash".
Yep, also this, only for "Conax Conditional Acess". Resetting it works best when using an FTA channel it seems.
...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels.
I'm looking at an oscam solution right now, but need to get a proper card reader, or try to get my old towitoko chipdrive going.
Don't know anything about oscam...
On 12/23/10 04:48, Simon Baxter wrote:
On 12/23/10 00:14, Simon Baxter wrote:
hello Klaus,
I tried the patch below with a knc1 dvb-c, tt c1500 and tt connect ct-3650 I used a alphacrypt light and I also tried the classic module
always the same behavior - if I zap from encrypted channel to encrypted channel in some situations vdr says "channel not available" if I reset the cam manually it works again immediately I also tried vdr 1.4 with my old tt ff c2300 and I had no problems
maybe its a general vdr 1.7.x cam handling problem
any idea - what I can do or test to identify where the problem is?
thanks
I had assumed this was due to some problem with CAM keys from the provider expiring, or something. I still intermittantly get "channel not available", but haven't found any way to recreate the problem at will.
I have exactly this aswel. It happens from 'surfing channels'. Never happens while watching the same channel continuously. Cannot say for sure it doesn't happen when surfing within the same bouquet.
I have multiple cards, 2x DVB-C+CAM, 2xDVB-S FTA. I sometimes get these messages when watching FTA too, when encrypted channels are recording and changing in the background.
I also occasionally have a CAM crash - where the status in goes from "ALPHACRYPT" to "CAM PRESENT" or "CAM READY". A manual reset (or multiple) fixes this, but I get no decryption during a "crash".
Yep, also this, only for "Conax Conditional Acess". Resetting it works best when using an FTA channel it seems.
...problems I've had to live with for months. Gave up asking and installed an FTA satellite dish for 50% of my mostly watched channels.
I'm looking at an oscam solution right now, but need to get a proper card reader, or try to get my old towitoko chipdrive going.
Don't know anything about oscam...
oscam is a softcam, it requires a smartcard reader and your smartcard, so its nothing illegal, also you can use 1 smartcard on more than 1 dvb card, even CI-less cards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hello, On Thu, Dec 23, 2010 at 09:59:19PM +0100, Oliver Schinagl wrote:
so its nothing illegal, also you can use 1 smartcard on more than 1 dvb card, even CI-less cards.
I don't think that it's legal in germany or in other countries. Please don't spam this thread with such suggestions. The is a problem which can be reproduced by other vdr users as well so that should be fixed in core vdr. Suggesting these plugins will not help everyone. BR. Halim
On 12/25/10 09:48, Halim Sahin wrote:
Hello, On Thu, Dec 23, 2010 at 09:59:19PM +0100, Oliver Schinagl wrote:
so its nothing illegal, also you can use 1 smartcard on more than 1 dvb card, even CI-less cards.
I don't think that it's legal in germany or in other countries.
I don't think softcams are illegal, using cardsharing services is .. legally debatable, but a softcam, in combination with your own smartcard, should be legal.
Please don't spam this thread with such suggestions.
Hardly spam, just a suggestion/workaround to get a workable legal solution. And with all the CI-less hardware out there, from PCI cards to USB cards and even WinTV offering a cardreader only (I belive they might be using a softcam in their win-ware) this may be the only solution to some.
The is a problem which can be reproduced by other vdr users as well so that should be fixed in core vdr.
Is this problem only to VDR? or has anybody noticed this same behaviour with, say Myth or something else. Could it be a kernel bug?
It seems/feels like the cam is crashing and that's why it needs to be reset, as sometimes the cam menu brings a 'CAM: -' message, indicating it isn't initialized any longer. Unrelated btw, I sometimes have a horribly A/V sync issue when changing encrypted channels. E.g. the video runs fine, but the audio is first missing, then slowly starts dripping in, kinda like how a torrents work, until after about 10 seconds all the sound runs smoothly. It only happens occasionally though ... very strange, but could be related.
Suggesting these plugins will not help everyone.
It very well may help people until this bug is solved. :(
Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I belive Halim has it on 1.7? So it has been around for quite a while. I can try patches if needed, as it should be pretty straight forward applying them on Gentoo, but 1.6 would be prefered.
BR. Halim
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Btw, I'm not sure if I mentioned, but this is happening in VDR 1.6, and I belive Halim has it on 1.7? So it has been around for quite a while. I can try patches if needed, as it should be pretty straight forward applying them on Gentoo, but 1.6 would be prefered.
Yip - I've been experiencing this since 1.6, and kernels from 2.6.24 thru 2.6.33.
Have tried manipulating the kernel source (dvb_ca_en50221.c) and adding breaks to extend wait times between READ/WRITE transactions to the CAM (multiple 'msleep(1);' commands). Used to help with earlier kernels, but has no affect for the past 2 years.
As I've mentioned before, I don't know what else to try.
Here's the problems I have with my CAM decryptions
* intermittant CAM crash, going from 'Alphacrypt' to 'CAM Ready' * intermittant CAM lock out. Can't access CAM menu, but CAM still displays 'Alphacrypt'
Both respond to reset (or multiple, up to 10 resets) and CAM comes back.
My system has 2 identical CAMs. Problem only affects one at a time, but does affect both.
Also occurs in CAM versions 3.09 thru 3.16 (tried upgrading/downgrading).
-
Halim Sahin -
Klaus Schmidinger -
Klaus Schmidinger -
Marco Göbenich -
Marco Skambraks -
Oliver Schinagl -
Simon Baxter