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

[Vincent Poore]

 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.

    On Friday, December 24, 2021, 06:26:43 PM MST, Vincent Poore via mythtv-users <mythtv-users at mythtv.org> wrote:  
 
 I've been living with and frustrated by a problem with recordings from my local CBS broadcast channel.
It all started when my local station added a new digital sub-channel.   I know this because my problem started on March 1st and a call to the station engineer confirmed changes were made to the broadcast signal early that Sunday morning. He says, "Everything in this encoding scheme is industry standard, so I wouldn’t expect there to be any problem decoding it with commercial equipment."  I'm not technical enough to determine what has changed that would give mythtv so much trouble.  Here are the symptoms:
Prior to the change, I used VDPAU High Quality Video Playback Profile.   After the change, this profile on the bad channel will eventually cause my machine to lock up.  It starts with some serious macro blocking and then eventually freezes the display and I have to use power reset to recover my machine.   I discovered I am able to view the programs using Open GL High Quality.   I'm not happy about the higher CPU, but at least I can watch my programs.   However, two other bad symptoms manifest.
After the change, the timing information of the recordings is off.   A 60 minute recording, when paused will report as 75 minutes.
I suspect this is related to the third symptom which is that skip forward or back doesn't work properly.  The first skip forward will actually jump backward some random offset (usually 3 or 4 minutes) and then progress forward from there with repeated commands.   A skip backward does the same thing (first skip offset backwards 3 to 4 minutes).
Note: I don't run any transcoding jobs on my recordings.   I've upgraded to Ubuntu 20.04.3 with latest mythtv patches (31.0+fixes.202111081900.25f1bb1d12~ubuntu20.04.1).
Any suggestions?_______________________________________________
mythtv-users mailing list
mythtv-users at mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20211229/db2c2d59/attachment-0001.htm>