On 29-02-12 17:52, Simon Baxter wrote:
On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger
<klaus.schmidin...@tvdr.de <mailto:klaus.schmidin...@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
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
