[mythtv-users] Playback Video Stutters & Audio Quits on one Frontend

[Stephen Worthington]

On Tue, 4 Aug 2020 19:09:53 -0500, you wrote:

>I'm stumped and need help.  I've been trying to understand why some video
>files work fine and others give me grief.  If I play a "bad" file on my
>BE/FE, it plays just fine.  If I play the same file on the remote FE, it
>will play ok for a second or two, but then the audio quits and the video
>will stutter like it's in slow motion.  If I play a "good" file, it works
>just fine anywhere.
>
>A "bad" file is one of my older recordings that has a file type description
>of:
>          "MPEG sequence, v2, program multiplex"
>(using the 'file' command in an xterm).
>A "good" file is one of the newer ones with a description of:
>          "MPEG transport stream data".
>
>The BE/FE is based on an ASRock Z77 Extreme4 motherboard with an Intel Core
>i3-3250 CPU @ 3.50GHz, integrated HD Graphics 2500 and 16GB of RAM.  The
>video connection is DVI-D.
>
>The remote FE is based on an ASRock A785GM-LE motherboard with an AMD
>Phenom II X4 965 CPU @3.4GHz, Nvidia GT710 PCI-E 2.0 Graphics adapter, and
>4GB of RAM.  The video connection is HDMI (with 5.1 Audio via the HDMI
>cable).
>
>The ethernet connection is 1GB/second rated, not tested.
>
>I fiddled around with various audio options and the pre-defined VDPAU
>profiles (made things worse! -- audio would drop out faster) vs. the High
>Quality profile.  I tried tweaking processor settings with cpufrequtils and
>only managed to get it running so hot it would freeze up until I forced it
>to shutdown and waited for it to cool off again.
>
>Short of transcoding the problem files to a format that works, or getting
>completely new hardware for the remote FE, I'd appreciate any suggestions
>for what I might have missed to try and get this to work.
>
>I'd also appreciate any advice on how to transcode the files into a format
>that will not cause this problem, preferably using Handbrake, Avidemux,
>and/or ffmpeg.

What MythTV version?  The rendering code was overhauled in v31 and you
may need to change the settings to get it to work well.

An Nvidia GT710 should be fine for all normal video types, except
possibly deinterlacing.  I am never sure without checking whether the
GT710 has the right resources to do the deinterlacing properly - older
Nvidia x10 models did not work properly.  For example, when I bought
my old GT220 card, there were quite a number of people who had bought
GT210 cards and found they did not work well with deinterlacing.  So
try setting the deinterlacing to a lower setting or to be done by the
CPU and see if that helps.

The "file" command is not the best to tell you the contents of a video
file.  Try "mediainfo" or "ffprobe".  From what "file" is reporting, I
think it means the "bad" files are MPEG2 Program Stream files and the
"good" files are MPEG2 Transport Stream files.  Off air recording
files from DVB or ATSC should be transport streams - the data is just
copied from what is received.  If you are having to record using
something that has to convert the video to record it, then the results
are often in program stream format.  Neither of those two container
formats should cause any problems for MythTV - it is what is in the
streams inside the container that matters.

I have had problems with ancient recordings I did using my Hauppauge
PVR-500 card.  These were back in the days of PAL analogue TV, and are
Program Stream files with MPEG2 video.  At some point MythTV changed
the way the recordedseek table works and the data in it for my old
analogue recordings is no longer valid.  This causes some strange
problems, but is easily fixed by telling mythcommflag to rebuild the
seek table on the file.  I have this set up as "User job #1" in my
settings:

MariaDB [mythconverg]> select * from settings where value like
'userjob%1';
+--------------+----------------------------------+----------+
| value        | data                             | hostname |
+--------------+----------------------------------+----------+
| UserJob1     | mythcommflag --rebuild -f %FILE% | NULL     |
| UserJobDesc1 | Rebuild seek table               | NULL     |
+--------------+----------------------------------+----------+
2 rows in set (0.00 sec)

That way on any suspect recording I can just do:

M(enu) > Job Options > Begin Rebuild seek table

and then in a minute or two the new seek table is ready and the file
plays properly.  You just have to wait for the mythcommflag command to
complete - use the command "ps -ef | grep mythcommflag" to see any
running mythcommflag instances.  There may be several if you are
recording at the time, but the one you want will show the --rebuild
option.

You set up the User Jobs in:

mythtv-setup > 1. General > (scroll down) > Job Queue (Job Commands)

You can also do it from the command line using "mythcommflag --rebuild
-f " and give it the basename of the file, such as
"4045_20151130152400.mpg".  The basename can be found in the database,
or by using the I key (Info button) twice on a recording and scrolling
down if necessary.