<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    On 29-02-12 17:52, Simon Baxter wrote:
    <blockquote
cite="mid:CADt8_dkCNNobw=W+jtMr+M9QFkp3zE8oT9aR-UhD-JFcRGYd7A@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Wed, Feb 29, 2012 at 7:39 AM, Klaus
        Schmidinger <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:Klaus.Schmidinger@tvdr.de">Klaus.Schmidinger@tvdr.de</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="im">On 29.02.2012 12:44, Kende wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">
              On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus
              Schmidinger wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                On 29.02.2012 12:13, Heikki Manninen wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  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.<br>
                  <br>
                  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.<br>
                  <br>
                  Would it be possible to force CAM reset on all CI
                  slots when VDR is trying to start recording non-FTA
                  channel?<br>
                </blockquote>
                <br>
                Wouldn't it be better to fix the actual problem and
                prevent<br>
                the CAM from "disappearing"?<br>
              </blockquote>
              <br>
              Hola,<br>
              <br>
              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:<br>
              <br>
              --- dvbci.c     2007-01-04 14:49:10.000000000 +0200<br>
              +++ ../vdr-1.7.21/dvbci.c       2011-10-12
              10:49:45.689684447 +0300<br>
              @@ -62,8 +62,10 @@<br>
               void cDvbCiAdapter::Write(const uint8_t *Buffer, int
              Length)<br>
               {<br>
            </div>
               if (Buffer&&  Length>  0) {
            <div class="im"><br>
              -     if (safe_write(fd, Buffer, Length) != Length)<br>
              +    if (safe_write(fd, Buffer, Length) != Length) {<br>
                       esyslog("ERROR: can't write to CI adapter on
              device %d: %m", device->De<br>
              viceNumber());<br>
              +       Reset(device->DeviceNumber());<br>
              +    }<br>
                    }<br>
               }<br>
            </div>
          </blockquote>
          <br>
          I tried this, but I'm afraid it doesn't help.<br>
          The Reset() call was never triggered, even though my CAM went
          from normal<br>
          operation to the "CAM ready" state, and not even an explicit
          reset via<br>
          the Setup/CAM menu brought it to life again. Only after
          reloading the<br>
          driver and restarting VDR did it work again.<br>
          <br>
          My theory is that switching channels is what's causing the
          problem.<br>
          When I trigger an EPG scan, the problem typically occurs after
          a while.<br>
          Maybe it's caused by tuning to channels that are no longer
          available,<br>
          so the frontend times out. However, there's no reason why a
          frontend<br>
          timeout should lead to a CAM freeze...<span class="HOEnZb"><font
              color="#888888"><br>
              <br>
            </font></span></blockquote>
      </div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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!!</div>
    </blockquote>
    Heh, I have several CAM problems with my TT-1500-T card using Conax
    cam.<br>
    <br>
    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:<br>
    * Cam needs to be reset a couple of times per week.<br>
    * 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.<br>
    * (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.<br>
    <br>
    Just a 'me too' like post so it's not just you (and me) that have
    this problem with TT 15xx based cards.<br>
    <blockquote
cite="mid:CADt8_dkCNNobw=W+jtMr+M9QFkp3zE8oT9aR-UhD-JFcRGYd7A@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div><br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
vdr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vdr@linuxtv.org">vdr@linuxtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a>
</pre>
    </blockquote>
  </body>
</html>