<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/01/2014 11:59 AM, John P Poet
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACSqvJkShZmZ44z=t-1=a2S0dV0u0Q4pid3U1KP0SsO3-r6A5Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Jun 30, 2014 at 4:22 PM,
            Peter Bennett <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:cats22@comcast.net" target="_blank">cats22@comcast.net</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div
                style="font-family:Arial;font-size:12pt;color:#000000">
                <div>I have struggled with the firewire issue -
                  megabytes of "no input in xxxx msec" in the log and no
                  recording. It seems to be random as to when it
                  happens. I had it consistently for 6 months then it
                  stopped. That was with mythtv 0.24. It stopped for a
                  year or so then started again on mythtv 0.26. At that
                  time somebody on this forum recommended changing to a
                  firewire card with Intel chipset instead of VIA
                  chipset. Evidently there was a bug in the firewire
                  Linux driver for that chipset. Since I changed to a
                  card with Intel it has not happened.</div>
                <div>My fix for when this happens is a script that
                  restarts the backend. If you kill and restart the
                  backend, it picks up the recording again and does not
                  have that error again in that recording. (sudo restart
                  mythtv-backend in Ubuntu).</div>
                <div>My script continuously monitors the log file and
                  kills the backend when those errors happen for a
                  couple of seconds. Very little recording is lost but
                  the recording is split into two files.</div>
                <div>Look here for my scripts</div>
                <div><a moz-do-not-send="true"
                    href="https://code.google.com/p/mythtv-scripts/"
                    target="_blank">https://code.google.com/p/mythtv-scripts/</a></div>
                <div>The monitor script is here</div>
                <div><a moz-do-not-send="true"
href="https://code.google.com/p/mythtv-scripts/source/browse/trunk/install/opt/mythtv/bin/monitor.sh"
                    target="_blank">https://code.google.com/p/mythtv-scripts/source/browse/trunk/install/opt/mythtv/bin/monitor.sh</a></div>
                <span class="HOEnZb"><font color="#888888">
                    <div>&nbsp;</div>
                    <div>Peter</div>
                  </font></span></div>
            </blockquote>
            <div><br>
            </div>
            <div>Hi Peter,</div>
            <div><br>
            </div>
            <div>I don't believe any of the MythTV devs have firewire
              anymore. &nbsp;Most people that did have switched to cable
              card.</div>
            <div><br>
            </div>
            <div>That being said, if you post logs from mythbackend with
              "-v channel,record" I will look and see if I can spot any
              obvious problems. &nbsp;One of my TODO list items is to rewrite
              the firewire code to conform to the multirec method used
              by the other input types -- however I am not looking
              forward to it, since I will have no way to test it...</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>John&nbsp;</div>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    Hi John<br>
    I think the best person to do that is the original poster here,
    DaveD. My firewire has been working perfectly since I switched to
    the Intel chipset Firewire card. <br>
    <br>
    Look at this ticket<br>
    <a class="moz-txt-link-freetext" href="https://code.mythtv.org/trac/ticket/10277">https://code.mythtv.org/trac/ticket/10277</a><br>
    <br>
    I actually created a patch for this in Mythtv 0.24, that solved the
    problem. The patch failed in 0.25 and the problem had gone away for
    me by then. The patch was a kludge work around - i.e. closed and
    opened the firewire port if the error occurred. That action
    recovered and recording could continue.<br>
    There is a comment in the patch from andy that suggests that the
    issue may be related to the VIA chipset.<br>
    When I was having the issue I did look at verbose logs and could not
    find any cause. It seemed that after recording for a few seconds it
    would stop receiving data. One thing - the bus reset that is in the
    code and gets called every few seconds when this error is happening
    - does not fix the problem, but seems it may make it worse. I tried
    with that option both on and off and that did not help.<br>
    <br>
    The general view from most mythtv developers seems to be that
    firewire is dying out. I think the cable companies now have a waiver
    that lets then give a DRM protected ethernet stream instead of
    firewire.<br>
    <br>
    Let me know if you need some help testing firewire changes.<br>
    <br>
    Instead of putting more time into firewire, is anybody investigating
    HDMI capture? There are HDMI capture cards available now and I have
    seen a couple with Linux drivers. They seem to be expensive. I know
    that would not work if the HDMI was encrypted, however Comcast has
    the small "adaptors" with HDMI output and I wonder if they use
    encrypted output. How does one check if the HDMI stream is
    encrypted?<br>
    <br>
    Peter<br>
    <br>
  </body>
</html>