[mythtv-users] Help with playback issue on recordings from a single channel

Klaas de Waal klaas.de.waal at gmail.com
Wed Dec 29 22:50:57 UTC 2021

On Wed, 29 Dec 2021 at 03:17, Vincent Poore via mythtv-users <
mythtv-users at mythtv.org> wrote:

> I'm replying to myself on this to summarize everything so far and shift
> the focus of my original query.
> Thank you to everyone who replied.   I'm grateful for all the input from
> everyone.
> 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.
> 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.
> 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.
> 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?
> 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.
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.
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.
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.

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.
However, if that is the problem then after a rebuild with "mythcommflag
--rebuild" as you have done then skipping should be OK.

Hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20211229/1e7b4ebe/attachment.htm>

More information about the mythtv-users mailing list