I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Greetings Klaus
On 29.2.2012, at 13.18, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Of course as always. But we don't live in a perfect world ;)
I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible.
On 29.02.2012 12:22, Heikki Manninen wrote:
On 29.2.2012, at 13.18, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Of course as always. But we don't live in a perfect world ;)
I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible.
I wasn't suggesting that you get some new hardware. What I meant was to fix the driver, which I would assume is causing the problems.
Of course, there might as well be a problem in VDR's own CAM handling code. However, I've looked through that several times and didn't find anything that looks fishy. But if somebody can point out a bug in there, I'd be happy to accept a fix.
Klaus
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer && Length > 0) { - if (safe_write(fd, Buffer, Length) != Length) + if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De viceNumber()); + Reset(device->DeviceNumber()); + } } }
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer&& Length> 0) {
if (safe_write(fd, Buffer, Length) != Length)
- if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De
viceNumber());
Reset(device->DeviceNumber());- } } }
I tried this, but I'm afraid it doesn't help. The Reset() call was never triggered, even though my CAM went from normal operation to the "CAM ready" state, and not even an explicit reset via the Setup/CAM menu brought it to life again. Only after reloading the driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem. When I trigger an EPG scan, the problem typically occurs after a while. Maybe it's caused by tuning to channels that are no longer available, so the frontend times out. However, there's no reason why a frontend timeout should lead to a CAM freeze...
Klaus
On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger < Klaus.Schmidinger@tvdr.de> wrote:
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer&& Length> 0) {
if (safe_write(fd, Buffer, Length) != Length)
- if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m",
device->De viceNumber());
Reset(device->DeviceNumber());- } }
}
I tried this, but I'm afraid it doesn't help. The Reset() call was never triggered, even though my CAM went from normal operation to the "CAM ready" state, and not even an explicit reset via the Setup/CAM menu brought it to life again. Only after reloading the driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem. When I trigger an EPG scan, the problem typically occurs after a while. Maybe it's caused by tuning to channels that are no longer available, so the frontend times out. However, there's no reason why a frontend timeout should lead to a CAM freeze...
I've had this problem for years on my TT-2300-C-FF and TT-1501-C cards with Alphacrypt Multicam. Updating the CAM has no effect, same experience with multiple versions of VDR. Most of the time the CAM can be brought back to "Ready" by doing a CAM Reset from the VDR menus multiple times. On rare occasions the CAM will still be "Ready" but I still get "Channel not available", until I do a CAM reset a few times.
I have a crude script which looks for "ERROR: can't write to CI adapter on device" in the syslog which notifies me so I can do the "CAM reset" (often multiple times) from the VDR menus.
This appears to be either a bug in the dvb code - which has never been fixed. To be honest - it's nice to hear other people have had the problem!!
On 29-02-12 17:52, Simon Baxter wrote:
On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger <Klaus.Schmidinger@tvdr.de mailto:Klaus.Schmidinger@tvdr.de> wrote:
On 29.02.2012 12:44, Kende wrote: On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote: On 29.02.2012 12:13, Heikki Manninen wrote: I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"? Hola, For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case: --- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer&& Length> 0) { - if (safe_write(fd, Buffer, Length) != Length) + if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De viceNumber()); + Reset(device->DeviceNumber()); + } } } I tried this, but I'm afraid it doesn't help. The Reset() call was never triggered, even though my CAM went from normal operation to the "CAM ready" state, and not even an explicit reset via the Setup/CAM menu brought it to life again. Only after reloading the driver and restarting VDR did it work again. My theory is that switching channels is what's causing the problem. When I trigger an EPG scan, the problem typically occurs after a while. Maybe it's caused by tuning to channels that are no longer available, so the frontend times out. However, there's no reason why a frontend timeout should lead to a CAM freeze...I've had this problem for years on my TT-2300-C-FF and TT-1501-C cards with Alphacrypt Multicam. Updating the CAM has no effect, same experience with multiple versions of VDR. Most of the time the CAM can be brought back to "Ready" by doing a CAM Reset from the VDR menus multiple times. On rare occasions the CAM will still be "Ready" but I still get "Channel not available", until I do a CAM reset a few times.
I have a crude script which looks for "ERROR: can't write to CI adapter on device" in the syslog which notifies me so I can do the "CAM reset" (often multiple times) from the VDR menus.
This appears to be either a bug in the dvb code - which has never been fixed. To be honest - it's nice to hear other people have had the problem!!
Heh, I have several CAM problems with my TT-1500-T card using Conax cam.
A little over a year ago, I needed to reset the cam a few times per hour! A kernel updated fixed that. So now, I still have: * Cam needs to be reset a couple of times per week. * When changing channels, sometimes an entire bouquet is 'CHannel not available', while other encrypted bouquet's work fine. Changing channels a few times remedies this, very annoying. * (This may not be cam related at all) sound quite often stutters (or silent at first, then slowly stutters right) when arriving at a channel. Takes a few seconds to get proper sound. Image tends to be fine. This however also happens on FTA channels, so may be not cam related.
Just a 'me too' like post so it's not just you (and me) that have this problem with TT 15xx based cards.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 29-02-12 16:39, Klaus Schmidinger wrote:
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer&& Length> 0) {
if (safe_write(fd, Buffer, Length) != Length)
- if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d:
%m", device->De viceNumber());
Reset(device->DeviceNumber());- } } }
I tried this, but I'm afraid it doesn't help. The Reset() call was never triggered, even though my CAM went from normal operation to the "CAM ready" state, and not even an explicit reset via the Setup/CAM menu brought it to life again. Only after reloading the driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem.
YES! I have so far only experienced this issue when switching channels. Staying on the same channel hasn't ever caused any problems. Changing channels causes various things, one being the cam needing to be reset.
When I trigger an EPG scan, the problem typically occurs after a while. Maybe it's caused by tuning to channels that are no longer available, so the frontend times out. However, there's no reason why a frontend timeout should lead to a CAM freeze...
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 29-02-12 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case:
Just a 'me too', My TT DVB-T 1500 with CI and conax cam also occasionally crashes. FTA remain working and a reset in the cam menu brings back the cam to life. Happens maybe once every few days, but my tv-box doesn't stay on for days, 3-8 hours a day max.
--- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer&& Length> 0) {
if (safe_write(fd, Buffer, Length) != Length)
- if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De
viceNumber());
Reset(device->DeviceNumber());- } } }
Hi list,
my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like
"dvb_ca adapter 0: DVB CAM link initialisation failed :("
also makes its way into syslog that way (because rsyslog retrieves messages from /dev/kmsg).
I wrote a simple Python program that monitors a given logfile for the appearance of this message, and then tries to trigger the appropriate SVDRP HITK sequence via a plain and simple socket connection. So far, it works quite well (no manual CAM resets had to be performed by my parents for the last four weeks this way). If anyone happens to know a more reliable way to externally trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything depends on the unchanged ordering of main menu entries, which is kind of annoying.
@OP: If your drivers produce a similar message to mine when your CAM flakes out, I could provide my (inelegant, but tiny and apparently working) script to you. Let me know if you want to try it :)
On 29.02.2012 12:29, Johannes Truschnigg wrote:
Hi list,
my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like
"dvb_ca adapter 0: DVB CAM link initialisation failed :("
also makes its way into syslog that way (because rsyslog retrieves messages from /dev/kmsg).
I wrote a simple Python program that monitors a given logfile for the appearance of this message, and then tries to trigger the appropriate SVDRP HITK sequence via a plain and simple socket connection. So far, it works quite well (no manual CAM resets had to be performed by my parents for the last four weeks this way). If anyone happens to know a more reliable way to externally trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything depends on the unchanged ordering of main menu entries, which is kind of annoying.
I also see this message in my log file from time to time. So this means that the driver apparently recognizes a CAM failure. Now the question is: why doesn't the driver report this fact to the application (VDR)? If VDR would receive this information, it could automatically do a reset.
Klaus
On 29.2.2012, at 13.29, Johannes Truschnigg wrote:
Hi list,
my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like
"dvb_ca adapter 0: DVB CAM link initialisation failed :("
Ok, that seems to be case for me as well:
[ 28.712154] dvb_ca adapter 0: DVB CAM detected and initialised successfully [229405.488050] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [229405.488063] dvb_ca adapter 0: DVB CAM link initialisation failed :( [344470.637483] budget_av: cam inserted A [344471.426622] dvb_ca adapter 0: DVB CAM detected and initialised successfully [352268.360055] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [352268.360068] dvb_ca adapter 0: DVB CAM link initialisation failed :(
Some scripting to try then..
-
Heikki Manninen -
Johannes Truschnigg -
Kende -
Klaus Schmidinger -
Oliver Schinagl -
Simon Baxter