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

[John Pilkington]

On 29/12/2021 02:15, Vincent Poore via mythtv-users 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.
> 
> 
> 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?

My impression at present is that your cpu isn't fast enough for this 
material.  Klaas suggested trying with different deinterlace options.

I can point to https://code.mythtv.org/trac/ticket/12010 , 8 years old, 
about seektable rebuilds - although that was aimed mainly at h264.  The 
main problem there is that only *you* have (or had) the original; 
others will have to use rebuilds, unless you also provide the output 
from mythutil --getmarkup

In response to your other recent post: nvidia and AMD are different. 
Code for AMD is open source, and so often considered ethically purer 
than that for nvidia.  But you said you were using vdpau - which TTBOMK 
is for nvidia.

Maybe you should try the 'lossless' mythtranscode, which may still work 
for mpeg2video, but that wouldn't help for near realtime watching.

Cheers,

John