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

John Pilkington johnpilk222 at gmail.com
Wed Dec 29 10:51:23 UTC 2021

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.



More information about the mythtv-users mailing list