<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 29 Dec 2021 at 03:17, Vincent Poore via mythtv-users <<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><div></div>
        <div dir="ltr"><div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">I'm replying to myself on this to summarize everything so far and shift the focus of my original query.</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">Thank you to everyone who replied.   I'm grateful for all the input from everyone.</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">In the beginning I was hopeful someone would recognize this and say "have the station engineer change x on the encoding and problem will be resolved."   I've kind of lost hope of having the station fix something on their end and I pretty much have to deal with this in MythTV.</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">At this point, it's not so bad having to use Open GL High Quality to view the recordings.   The inability to skip backwards 10 seconds is what stinks.    At first I was hopeful that mythcommflag --rebuild would at least help out, but that has made things worse.   When I run that, I can't view the recording at all.  It just skips directly to the end on initial playback.    Also this work-around was never going to help out when viewing a slightly delayed live recording like a football game.</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">If we forget about hardware accelerated playback, is there anything I can do to mitigate the skip backwards problem?   I have two other front ends that also playback fine except for the skip backwards issue.</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">I'm going to start looking at and experimenting with the recordedseek table.  Maybe if I remove all seek info for a recording it will behave better than having bad seek info?</div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><br></div><div dir="ltr" style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px">Is there anyone expert at how seek info is populated in order to render a guess as to what is going on?   It seems like the best chance for resolution is to figure out how the recording is throwing off the seek calculations.</div></div></div><div><br></div></div></div></blockquote><div><br></div><div>I think that in the summary you do miss the most important thing and that is that your hardware has issues. It should at the very least be capable of completing the ffmpeg transcode. Other good tests are memcheck68 (can sometimes be selected at boot) and a compilation of MythTV from source using all cores. Or, even better, the Linux kernel.</div><div>It could be a thermal issue as Stephen suggested; to verify that you can run the sensors command repeatedly (e.g. "watch -n1 sensors" ) while the ffmpeg transcode is running. If it is a thermal problem then the temperature will increase to at least 100 degrees before the CPU locks.</div><div>However, my best guess is that your motherboard is faulty and I suggest reproducing the problem on known good hardware. It is not possible to do software problem analysis on faulty hardware.</div><div><br></div><div>About the skipping problem. It could be that there is something in the stream that causes bad data in the recordedseek table and that then causes the skipping issues.</div><div>However, if that is the problem then after a rebuild with "mythcommflag --rebuild" as you have done then skipping should be OK.</div><div><br></div><div>Hope this helps,</div><div>Klaas.</div><div><br></div><div> </div></div></div>