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

Sat Dec 25 17:27:53 UTC 2021

 For video, I have a 2012 era AMD processor with integrated graphics.  Ubuntu settings reports it as  Processor: AMD® A10-5800k apu with radeon(tm) hd graphics × 4 Graphics:AMD® Aruba
lspci |grep Radeon00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7660D]
Originally, there was a proprietary Radeon driver I used, but these days I just use the stock Ubuntu drivers.    I updated everything yesterday hoping this would help but it did not.
I did try mythcommflag to rebuild the seek table and got a big surprise.   After running it, the video will not play at all.   When you start it, it simply displays the end of recording prompt right off the bat.   Here is some sample output.
time mythcommflag --rebuild -f 1504_20211225053500.ts2021-12-25 08:14:35.104062 C  mythcommflag version: fixes/31 [v31.0+fixes.202111081900.25f1bb1d12~ubuntu20.04.1] www.mythtv.org2021-12-25 08:14:35.104082 C  Qt version: compile: 5.12.8, runtime: 5.12.8MythTV Commercial Flagger, building seek table for:    The Late Show With Stephen Colbert - Anderson Cooper; Andy CohenRebuild started at Sat Dec 25 08:14:36 2021Rebuild completed at Sat Dec 25 08:15:16 20212021-12-25 08:15:16.744057 E  decoding error End of file (-541478725)
real 0m43.234suser 0m16.925ssys 0m2.887s

    On Friday, December 24, 2021, 08:14:20 PM MST, Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:  

 On Sat, 25 Dec 2021 01:25:59 +0000 (UTC), you 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?

The lockup problem sounds like the video has a bad interaction with
the Nvidia drivers and is triggering a bug.  When I first got my
Nvidia GT1030 cards, I used to get lockups like that, but updated
drivers reduced the frequency of the problem and a further update
stopped it altogether.  So what Nvidia GPU are you using?  What
version of the Nvidia drivers are installed?  These commands should
tell you:

lspci | grep -i nvidia
apt list --installed | grep -i nvidia

The problem with seeking and programme length is something I
occasionally get with a recording, where the seek table is not being
built correctly during the recording process.  But if I use
mythcommflag to rebuild it, the seek table normally then is valid and
works correctly.  I do that by having a user job set up do this:

mythtv-setup > General > Job Queue (Job Commands)

Pick one of the four user jobs that does not have a command set up
already and change the description to "Rebuild seek table" and the
command to "mythcommflag --rebuild -f %FILE%".  Then whenever you have
a recording with a seek table problem, select that recording from the
programmes list and do:

M(enu) > Job options

and select the "Begin Rebuild seek table" option.  That queues the
mythcommflag job to be started, and when the job queue is next
examined by mythbackend (it can take up to 30? seconds), the
mythcommflag job will be started.  If you open a command prompt and
run this:

ps -ef | grep mythcommflag

you can see when the mythcommflag job starts and when it has finished.
Once it has finished, seeking should work properly.  The time taken
for mythcommflag to recreate the seek table depends on how powerful
the PC is, but is generally only a minute or two on a modern PC. Doing
this will lose all the commercial skip information as well, as that is
also stored in the seek table.  If you want to recreate that as well,
you will need to run another mythcommflag job on the recording after
the --rebuild one is finished.  For that job, leave out the
"--rebuild" flag.  Doing commercial skip processing takes a lot longer
than just rebuilding the seek table as the data in each frame of the
video and audio needs to be read and processed.

There are also some commands you can try on the recording files to see
what format they are in: mediainfo and ffprobe.  You may need to
install the appropriate packages to get those commands, or use
mythffprobe which comes as part of the MythTV packages.  To find the
recording file for a recording, use the I key (or Info button on your
remote).  There should be a line displayed that says "Recording File
:" that has the name of the file, usually a .ts file these days.  On a
command line, run this command:

locate <recording file name>

and the file and its thumbnail file(s) should be listed.  If the
locate command is not available, you will need to install it:

sudo apt install mlocate

If the locate command can not find the file (if it was recorded in the
last 24 hours), you will need to update the file location database
first:

sudo updatedb

That takes a while as all the directories on all the disks have to be
scanned.  It is normally done automatically every day by a cron job in
the early morning.
_______________________________________________
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/20211225/5de10724/attachment.htm>