[vdr] Patch suggestion: Force CAM reset before upcoming recording

Oliver Schinagl oliver at schinagl.nl
Tue Mar 6 10:34:15 CET 2012



On 29-02-12 17:52, Simon Baxter wrote:
>
>
> On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger 
> <Klaus.Schmidinger at tvdr.de <mailto:Klaus.Schmidinger at 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 at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20120306/83cf45ed/attachment-0001.html>


More information about the vdr mailing list