<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 31/01/2019 14:47, Tim Pletcher
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABBGYbHKmoKJTXSFUXAYvm891GGeYgxD+ZrQ0CZTRUEUA3AWvg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Tue, Jan 29, 2019 at 2:11 PM Tim Pletcher <<a
            href="mailto:pletchtd@gmail.com" target="_blank"
            moz-do-not-send="true">pletchtd@gmail.com</a>> wrote:<br>
        </div>
        <div dir="ltr">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">
                <div dir="ltr">On Tue, Jan 29, 2019 at 10:28 AM John
                  <<a href="mailto:jksjdevelop@gmail.com"
                    target="_blank" moz-do-not-send="true">jksjdevelop@gmail.com</a>>
                  wrote:<br>
                </div>
                <div class="gmail_quote">
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px 0.8ex;border-left:1px solid
                    rgb(204,204,204);padding-left:1ex">
                    <div bgcolor="#FFFFFF">
                      <p>I also get this error on a remote frontend with
                        version 30. Some timeout must need a tweak. Note
                        the issue has been there for several weeks it is
                        not due to a very recent change. I don't use
                        live tv enough to make it a major issue for me.<br>
                      </p>
                    </div>
                    <br>
                  </blockquote>
                  <div><br>
                  </div>
                  <div>Good to know that the problem is not unique to
                    me.  I only updated to v30 on Sunday the day prior
                    so it is likely that I simply didn't stumble upon it
                    in the limited use of the system since then.  </div>
                  <div><br>
                  </div>
                  <div>According to this in the log:</div>
                  <div>
                    <pre style="color:rgb(0,0,0);white-space:pre-wrap">Jan 28 19:28:13 k-mint mythfrontend.real: mythfrontend[1273]: I CoreContext avformatdecoder.cpp:2772 (OpenAVCodec) AFD: Opened codec 0x55a532b95180, id(AC3) type(Audio)
Jan 28 19:28:13 k-mint mythfrontend.real: mythfrontend[1273]: E CoreContext avformatdecoder.cpp:2635 (ScanStreams) AFD: Unknown video codec - defaulting to MPEG2</pre>
                    <pre style="color:rgb(0,0,0);white-space:pre-wrap"><font face="arial, helvetica, sans-serif">It appears that this is related to fallback to software based decoding rather than GPU Hardware based decoding.  Since this is occurring intermittently, you are probably right that it is a timing issue.  </font></pre>
                    <pre style="color:rgb(0,0,0);white-space:pre-wrap"><font face="arial, helvetica, sans-serif">Looking at avformatdecoder.cpp and totally speculating because i have no experience with C++, I wonder if is related to </font><span style="font-family:Arial,Helvetica,sans-serif">SEQ_PKT_ERR_MAX</span><span style="font-size:12px;color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace"> 10 </span><font face="arial, helvetica, sans-serif"><span style="color:rgb(36,41,46);font-size:12px">(line 108) which</span> is a criterion used to apply logic to fall back to software decoding?  Is 10 packets perhaps sometimes too sensitive when changing channels via LiveTV?</font></pre>
                  </div>
                </div>
              </div>
            </blockquote>
            <div>I pulled down the source, increased the SEQ_PKT_ERR_MAX
              value to 15 in avformatdecoder.cpp, and recompiled the
              frontend.  Since doing that, I have not experienced the
              'Could not open decoder' error for the last three days now
              when using LiveTV.  I have not noticed any other
              deleterious effects though I will continue to monitor for
              any.</div>
            <div><br>
            </div>
            <div>On a separate topic, when I recompile the frontend from
              source, the mythfrontend binary I generate is an order of
              magnitude larger than the one in the mythbuntu repo and I
              can't seem to figure out why.  Looking and comparing the
              ./configure options from the mythbuntu build package with
              the ones I am using, the only tangible difference i see is
              that my system is using NASM rather than YASM for the
              compilation.  Can anyone educate me on what is causing
              this difference?</div>
            <div><br>
            </div>
            <div>-Tim<br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <br>
    </blockquote>
    <p><br>
    </p>
    <p>Tim,</p>
    <p>I tried your change to  SEQ_PKT_ERR_MAX on current mythtv master
      and it did not resolve the problem. I also tried other values of
      50 and 1000, again no resolution. <br>
    </p>
    <p>For reference my system is Xubuntu 18.04 with Hauppauge QuadHD
      DVB-T/T2  using current Hauppauge kernel from the ppa.</p>
    <p>My workround is attached, it disables error checking in
      avformatdecoder.cpp, and only affects LiveTV.<br>
    </p>
    <p><br>
    </p>
    <p>Mike<br>
    </p>
  </body>
</html>