Mailing List Archive

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Tue, Aug 4, 2020, 10:39 PM Stephen Worthington <stephen_agent@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.

>

> On 5 Aug 2020, at 8:09 am, Craig Huff <huffcslists@gmail.com> 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.

I’d be very interested too!
One of my FE is a wireless laptop. Most movies play just fine (including HD), but every now and then is a movie that is always stuttery

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Aug 5, 2020 at 9:05 PM jam <jam@tigger.ws> wrote:

>
>
> > On 5 Aug 2020, at 8:09 am, Craig Huff <huffcslists@gmail.com> 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.
>
> I’d be very interested too!
> One of my FE is a wireless laptop. Most movies play just fine (including
> HD), but every now and then is a movie that is always stuttery
>
> James
>

Sadly, rebuilding seek tables didn't change anything. I believe the
problem is with SD recordings captured using PVR-500 tuners that I'm trying
to play back on an HD TV via HDMI on a remote FE. They play successfully
on the BE/FE connected to a digital monitor via DVI. ffprobe describes the
couple I'm focusing on as:
Video: mpeg2video (Main), yuv420p(tv, top first), 720x480 [SAR 8:9
DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s

I will try to see what I can come up with to transcode them to MP4 or h.264
and see if that helps. Any suggestions from the peanut gallery gratefully
appreciated.

--
Craig.

On 09/08/2020 22:45, Craig Huff wrote:
> On Wed, Aug 5, 2020 at 9:05 PM jam <jam@tigger.ws
> <mailto:jam@tigger.ws>> wrote:
>
>
>
> > On 5 Aug 2020, at 8:09 am, Craig Huff <huffcslists@gmail.com
> <mailto:huffcslists@gmail.com>> 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.
>
> I’d be very interested too!
> One of my FE is a wireless laptop. Most movies play just fine
> (including HD), but every now and then is a movie that is always
> stuttery
>
> James
>
>
> Sadly, rebuilding seek tables didn't change anything.  I believe the
> problem is with SD recordings captured using PVR-500 tuners that I'm
> trying to play back on an HD TV via HDMI on a remote FE.  They play
> successfully on the BE/FE connected to a digital monitor via DVI.
> ffprobe describes the couple I'm focusing on as:
>         Video: mpeg2video (Main), yuv420p(tv, top first), 720x480 [SAR
> 8:9 DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
>         Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
>
> I will try to see what I can come up with to transcode them to MP4 or
> h.264 and see if that helps.  Any suggestions from the peanut gallery
> gratefully appreciated.

That probe result looks like any DVB-T recording of mine, apart from the
30 Hz frame rate, the higher audio sample rate and the lack of subtitle
or alternative audio tracks. My max audio rate is usually 256 kb/s.
It's stereo which you are trying to play as 5.1, and I wonder if that's
the problem.

I would try frontend setup > Setup Wizard > Next > and try options
there. Tests in the Setup > Audio page fail for me. GT 710 / HDMI

John P


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Aug 9, 2020 at 5:47 PM Craig Huff <huffcslists@gmail.com> wrote:

> On Wed, Aug 5, 2020 at 9:05 PM jam <jam@tigger.ws> wrote:
>
>>
>>
>> > On 5 Aug 2020, at 8:09 am, Craig Huff <huffcslists@gmail.com> 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.
>>
>> I’d be very interested too!
>> One of my FE is a wireless laptop. Most movies play just fine (including
>> HD), but every now and then is a movie that is always stuttery
>>
>> James
>>
>
> Sadly, rebuilding seek tables didn't change anything. I believe the
> problem is with SD recordings captured using PVR-500 tuners that I'm trying
> to play back on an HD TV via HDMI on a remote FE. They play successfully
> on the BE/FE connected to a digital monitor via DVI. ffprobe describes the
> couple I'm focusing on as:
> Video: mpeg2video (Main), yuv420p(tv, top first), 720x480 [SAR 8:9
> DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
> Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
>
> I will try to see what I can come up with to transcode them to MP4 or
> h.264 and see if that helps. Any suggestions from the peanut gallery
> gratefully appreciated.
>
>
>
Just a guess, but perhaps the presentation timestamps in these older
recordings are messed up. The audio / video synchronization approach in
v31 was changed to rely on these values from the recording file and perhaps
some decoders are more tolerant than others??

You might look into regenerating timestamps with ffmpeg. I haven't tried
any of this myself as I don't have old recordings with this issue but some
of the discussion in this thread might provide some options:
https://superuser.com/questions/1159056/ffmpeg-recreate-timestamps-without-reencoding/1358974

Tim

On 10/08/2020 02:01, Tim Pletcher wrote:
>
>
> On Sun, Aug 9, 2020 at 5:47 PM Craig Huff <huffcslists@gmail.com
> <mailto:huffcslists@gmail.com>> wrote:
>
> On Wed, Aug 5, 2020 at 9:05 PM jam <jam@tigger.ws
> <mailto:jam@tigger.ws>> wrote:
>
>
>
> > On 5 Aug 2020, at 8:09 am, Craig Huff <huffcslists@gmail.com
> <mailto:huffcslists@gmail.com>> 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.
>
> I’d be very interested too!
> One of my FE is a wireless laptop. Most movies play just fine
> (including HD), but every now and then is a movie that is always
> stuttery
>
> James
>
>
> Sadly, rebuilding seek tables didn't change anything.  I believe the
> problem is with SD recordings captured using PVR-500 tuners that I'm
> trying to play back on an HD TV via HDMI on a remote FE.  They play
> successfully on the BE/FE connected to a digital monitor via DVI.
> ffprobe describes the couple I'm focusing on as:
>         Video: mpeg2video (Main), yuv420p(tv, top first), 720x480
> [SAR 8:9 DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
>         Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
>
> I will try to see what I can come up with to transcode them to MP4
> or h.264 and see if that helps.  Any suggestions from the peanut
> gallery gratefully appreciated.
>
>
>
> Just a guess, but perhaps the presentation timestamps in these older
> recordings are messed up.  The audio / video synchronization approach in
> v31 was changed to rely on these values from the recording file and
> perhaps some decoders are more tolerant than others??
>
> You might look into regenerating timestamps with ffmpeg.  I haven't
> tried any of this myself as I don't have old recordings with this issue
> but some of the discussion in this thread might provide some options:
> https://superuser.com/questions/1159056/ffmpeg-recreate-timestamps-without-reencoding/1358974
>
> Tim

That's an intriguing idea, and as you say it could be decoder-dependent.
But it might be worth looking at the audio readahead setting:

Frontend setup > Video > Playback > Advanced Playback Settings >
Audio read ahead (ms)

"Increase this value if audio cuts out frequently....."

Default is 100 ms. On my GT 710 box it's at 400 ms. I suppose I did that.

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Aug 10, 2020 at 4:39 AM John Pilkington <johnpilk222@gmail.com>
wrote:

>
> That's an intriguing idea, and as you say it could be decoder-dependent.
> But it might be worth looking at the audio readahead setting:
>
> Frontend setup > Video > Playback > Advanced Playback Settings >
> Audio read ahead (ms)
>
> "Increase this value if audio cuts out frequently....."
>
> Default is 100 ms. On my GT 710 box it's at 400 ms. I suppose I did that.
>
> John P
>

Using multiple steps, I tried using HandBrake to transcode the example
video to h.264, swapped the original file with the h.264 version, rebuilt
the seek tables for the h.264 doppelganger, ran a full mythcommflag pass on
it to detect commercial breaks, and changed audio from 5.2 to stereo. None
of these worked, but I did notice that the h.264 file was easily 1/3 the
size of the original. My conclusion is to just watch the troublesome
recordings on the BE/FE and/or re-record them now that I'm using an
(external) infiniTV 6 instead of a pair of PVR-500 cards. Besides, if/when
I break down and upgrade my MythTV version, things may clear up. ????

In any case, a big thank you to all for the many suggestions. They were
all worth a try.

--
Craig.

On Wed, 12 Aug 2020 13:47:04 -0500, you wrote:

>On Mon, Aug 10, 2020 at 4:39 AM John Pilkington <johnpilk222@gmail.com>
>wrote:
>
>>
>> That's an intriguing idea, and as you say it could be decoder-dependent.
>> But it might be worth looking at the audio readahead setting:
>>
>> Frontend setup > Video > Playback > Advanced Playback Settings >
>> Audio read ahead (ms)
>>
>> "Increase this value if audio cuts out frequently....."
>>
>> Default is 100 ms. On my GT 710 box it's at 400 ms. I suppose I did that.
>>
>> John P
>>
>
>Using multiple steps, I tried using HandBrake to transcode the example
>video to h.264, swapped the original file with the h.264 version, rebuilt
>the seek tables for the h.264 doppelganger, ran a full mythcommflag pass on
>it to detect commercial breaks, and changed audio from 5.2 to stereo. None
>of these worked, but I did notice that the h.264 file was easily 1/3 the
>size of the original. My conclusion is to just watch the troublesome
>recordings on the BE/FE and/or re-record them now that I'm using an
>(external) infiniTV 6 instead of a pair of PVR-500 cards. Besides, if/when
>I break down and upgrade my MythTV version, things may clear up. ?
>
>In any case, a big thank you to all for the many suggestions. They were
>all worth a try.

Running mythcommflag to re-do the commercial breaks does not rebuild
the seek table. If you want to rebuild the seek table, which is what
works for me, you need to do "mythcommflag --rebuild", and then after
that if you want the commercial flagging, run mythcommflag again to do
that.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 13/08/2020 04:28, Stephen Worthington wrote:
> On Wed, 12 Aug 2020 13:47:04 -0500, you wrote:
>
>> On Mon, Aug 10, 2020 at 4:39 AM John Pilkington <johnpilk222@gmail.com>
>> wrote:
>>
>>>
>>> That's an intriguing idea, and as you say it could be decoder-dependent.
>>> But it might be worth looking at the audio readahead setting:
>>>
>>> Frontend setup > Video > Playback > Advanced Playback Settings >
>>> Audio read ahead (ms)
>>>
>>> "Increase this value if audio cuts out frequently....."
>>>
>>> Default is 100 ms. On my GT 710 box it's at 400 ms. I suppose I did that.
>>>
>>> John P
>>>
>>
>> Using multiple steps, I tried using HandBrake to transcode the example
>> video to h.264, swapped the original file with the h.264 version, rebuilt
>> the seek tables for the h.264 doppelganger, ran a full mythcommflag pass on
>> it to detect commercial breaks, and changed audio from 5.2 to stereo. None
>> of these worked, but I did notice that the h.264 file was easily 1/3 the
>> size of the original. My conclusion is to just watch the troublesome
>> recordings on the BE/FE and/or re-record them now that I'm using an
>> (external) infiniTV 6 instead of a pair of PVR-500 cards. Besides, if/when
>> I break down and upgrade my MythTV version, things may clear up. ?
>>
>> In any case, a big thank you to all for the many suggestions. They were
>> all worth a try.
>
> Running mythcommflag to re-do the commercial breaks does not rebuild
> the seek table. If you want to rebuild the seek table, which is what
> works for me, you need to do "mythcommflag --rebuild", and then after
> that if you want the commercial flagging, run mythcommflag again to do
> that.

I don't know if after all that action you still have the original file
playable on one of your frontends. If so, you could try a 'lossless'
mythtranscode --mpeg2

Do a mythcommflag --rebuild first. Then you could, if you wish,
establish a cutlist. Or just go ahead and do the cutting later. I
haven't used mythtranscode recently, but it ought to work.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, Aug 13, 2020, 3:11 AM John Pilkington <johnpilk222@gmail.com> wrote:

> On 13/08/2020 04:28, Stephen Worthington wrote:
> > On Wed, 12 Aug 2020 13:47:04 -0500, you wrote:
> >
> >> On Mon, Aug 10, 2020 at 4:39 AM John Pilkington <johnpilk222@gmail.com>
> >> wrote:
> >>
> >>>
> >>> That's an intriguing idea, and as you say it could be
> decoder-dependent.
> >>> But it might be worth looking at the audio readahead setting:
> >>>
> >>> Frontend setup > Video > Playback > Advanced Playback Settings >
> >>> Audio read ahead (ms)
> >>>
> >>> "Increase this value if audio cuts out frequently....."
> >>>
> >>> Default is 100 ms. On my GT 710 box it's at 400 ms. I suppose I did
> that.
> >>>
> >>> John P
> >>>
> >>
> >> Using multiple steps, I tried using HandBrake to transcode the example
> >> video to h.264, swapped the original file with the h.264 version,
> rebuilt
> >> the seek tables for the h.264 doppelganger, ran a full mythcommflag
> pass on
> >> it to detect commercial breaks, and changed audio from 5.2 to stereo.
> None
> >> of these worked, but I did notice that the h.264 file was easily 1/3 the
> >> size of the original. My conclusion is to just watch the troublesome
> >> recordings on the BE/FE and/or re-record them now that I'm using an
> >> (external) infiniTV 6 instead of a pair of PVR-500 cards. Besides,
> if/when
> >> I break down and upgrade my MythTV version, things may clear up. ?
> >>
> >> In any case, a big thank you to all for the many suggestions. They were
> >> all worth a try.
> >
> > Running mythcommflag to re-do the commercial breaks does not rebuild
> > the seek table. If you want to rebuild the seek table, which is what
> > works for me, you need to do "mythcommflag --rebuild", and then after
> > that if you want the commercial flagging, run mythcommflag again to do
> > that.
>
> I don't know if after all that action you still have the original file
> playable on one of your frontends. If so, you could try a 'lossless'
> mythtranscode --mpeg2
>
> Do a mythcommflag --rebuild first. Then you could, if you wish,
> establish a cutlist. Or just go ahead and do the cutting later. I
> haven't used mythtranscode recently, but it ought to work.
>

Other than using a different tool to transcode, I'm not sure why it might
make a difference, but anything is worth a try. Hopefully I can test that
later today. I also need to try the audio readahead adjustment, although,
IIRC, the playback doesn't just drop/lose the audio, it either freezes up
completely or stutters (like going into slow-motion) -- can't recall which
at the moment.

--
Craig.

>

On 16/08/2020 11:15, Craig Huff wrote:
> On Thu, Aug 13, 2020, 3:11 AM John Pilkington <johnpilk222@gmail.com
> <mailto:johnpilk222@gmail.com>> wrote:
>
> On 13/08/2020 04:28, Stephen Worthington wrote:
> > On Wed, 12 Aug 2020 13:47:04 -0500, you wrote:
> >
> >> On Mon, Aug 10, 2020 at 4:39 AM John Pilkington
> <johnpilk222@gmail.com <mailto:johnpilk222@gmail.com>>
> >> wrote:
> >>
> >>>
> >>> That's an intriguing idea, and as you say it could be
> decoder-dependent.
> >>>    But it might be worth looking at the audio readahead setting:
> >>>
> >>> Frontend setup > Video > Playback > Advanced Playback Settings >
> >>>     Audio read ahead (ms)
> >>>
> >>> "Increase this value if audio cuts out frequently....."
> >>>
> >>> Default is 100 ms.  On my GT 710 box it's at 400 ms.  I suppose
> I did that.
> >>>
> >>> John P
> >>>
> >>
> >> Using multiple steps, I tried using HandBrake to transcode the
> example
> >> video to h.264,  swapped the original file with the h.264
> version, rebuilt
> >> the seek tables for the h.264 doppelganger, ran a full
> mythcommflag pass on
> >> it to detect commercial breaks, and changed audio from 5.2 to
> stereo.  None
> >> of these worked, but I did notice that the h.264 file was easily
> 1/3 the
> >> size of the original.  My conclusion is to just watch the
> troublesome
> >> recordings on the BE/FE and/or re-record them now that I'm using an
> >> (external) infiniTV 6 instead of a pair of PVR-500 cards.
> Besides, if/when
> >> I break down and upgrade my MythTV version, things may clear up. ?
> >>
> >> In any case, a big thank you to all for the many suggestions.
> They were
> >> all worth a try.
> >
> > Running mythcommflag to re-do the commercial breaks does not rebuild
> > the seek table.  If you want to rebuild the seek table, which is what
> > works for me, you need to do "mythcommflag --rebuild", and then after
> > that if you want the commercial flagging, run mythcommflag again
> to do
> > that.
>
> I don't know if after all that action you still have the original file
> playable on one of your frontends.  If so, you could try a 'lossless'
> mythtranscode --mpeg2
>
> Do a mythcommflag --rebuild first.  Then you could, if you wish,
> establish a cutlist.  Or just go ahead and do the cutting later.   I
> haven't used mythtranscode recently, but it ought to work.
>
>
> Other than using a different tool to transcode, I'm not sure why it
> might make a difference, but anything is worth a try. Hopefully I can
> test that later today.  I also need to try the audio readahead
> adjustment, although, IIRC, the playback doesn't just drop/lose the
> audio, it either freezes up completely or stutters (like going into
> slow-motion) -- can't recall which at the moment.
>

The audioreadahead setting should be easy to change and test, and would
affect only the one frontend. Setting up 'mythtranscode -m' might need
more work; but it isn't really a transcode, IIRC it just demuxes and
remuxes and might apply a better A/V offset. Another possibility is
dropping the first few MB of the file, perhaps using dd. It all depends
on how much you want to play that file on that frontend...

John
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org