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

[Craig Huff]

On Tue, Aug 4, 2020, 10:39 PM Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> 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.
>

Stephen,

Thanks for the advice!

Yes, the "bad" ones are almost certainly PVR-500 recordings from NTSC
OTA/analog cable sources.

I will give your suggestions a try.

I'm guilty of update fatigue -- I started with MythTV on Fedora 6(!!!) and
the current instance is MythBuntu (based on Ubuntu 14.04?). I'm a fan of
the "ain't broke, don't fix it" theory - besides, I've got plenty if other
"opportunities" to address.😏

-- 
Craig.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200805/a4cb552f/attachment.htm>