Mailing List Archive

getting video decode errors on ATSC subchannels
Not near my main system right now (which runs 27) and decided to
install mythtv 32 on a system I have access to. HDHomerun OTA ATSC
tuner.

I setup two inputs for the two tuners, set max recording to 8 for each
(quite a few subchannels in the area). I'm able to record the .1
channels just fine (say 7.1) but when I go to record 7.2 it says it's
recording but if you try to play the recording it comes back with a
video decode error.

Again, 7.1 records and plays fine. 7.2 says it's recording but won't
play with a video decode error. I've tried multiple channels and their
subs.

Any idea what I should be looking at?
_______________________________________________
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
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com> wrote:

> Any idea what I should be looking at?

WAG's follows:

What does mediainfo indicate about the recording?
There are a few locations where the non-primary
subchannel(s) is in a non-mpeg2 format[0] that one
may need different decoders (or hardware) to
decode.


I also have this vague recollection (I am sure
one of the devs will correct me) that sometime
after 0.27 was released the virtual/multirec
configuration was updated, and it is possible
that you need to delete and add all your tuners
all over again (I think there was automated
conversion, but, sometimes, in special cases,
one is going to hit one of those cases where
that conversion was non-optimal).



[0] Per FCC regs, the primary sub-channel for
ATSC 1.0 transmitters must be mpeg2, but
there are no such requirements on the
additional subchannels.
_______________________________________________
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
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
<gary.buhrmaster@gmail.com> wrote:
>
> On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com> wrote:
>
> > Any idea what I should be looking at?
>
> WAG's follows:

That took me a second. LOL.

>
> What does mediainfo indicate about the recording?
> There are a few locations where the non-primary
> subchannel(s) is in a non-mpeg2 format[0] that one
> may need different decoders (or hardware) to
> decode.

Even though there was a 300 MB .ts file, mediainfo wasn't able to read it.

To clarify, this was just a test on a clean system, so completely new
installation, nothing to upgrade. When I was testing jellyfin, their
DVR was able to record them fine. But wow, did I miss the
functionality of MythTV for TV. So I nuked all that. Looking at the
logs, I do see a ton of lines about "Malformed NAL units" right after
the subchannel recording started:

Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I CoreContext
scheduler.cpp:717 (UpdateRecStatus) Updating status for Posse on
cardid [3] (Tuning => Recording)
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:4146 (TuningNewRecorder) TVRec[3]: rec->GetPathname():
'/media/disk2/15103_20230217032800.ts'
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:4179 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
CreateRecorder()
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[4]: ASK_RECORDING 4 0
0 0
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[1]: ASK_RECORDING 1 0
0 0
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[5]: ASK_RECORDING 5 0
0 0
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[6]: ASK_RECORDING 6 0
0 0
Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:35 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:37 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:43 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:46 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: I ProcessRequest
mainserver.cpp:1811 (HandleAnnounce) MainServer: MainServer::ANN
Monitor
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: I ProcessRequest
mainserver.cpp:1813 (HandleAnnounce) MainServer: adding:
bhmf(55fe0e3eaad0) as a client (events: 0)
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: I ProcessRequest
mainserver.cpp:1811 (HandleAnnounce) MainServer: MainServer::ANN
Monitor
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: I ProcessRequest
mainserver.cpp:1813 (HandleAnnounce) MainServer: adding:
bhmf(55fe0e3df4b0) as a client (events: 1)
Feb 16 22:27:47 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
Feb 16 22:27:53 bhmf mythbackend: mythbackend[19718]: E
HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
AVCParser::addbytes: malformed NAL units
_______________________________________________
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
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Thu, Feb 16, 2023 at 10:57 PM Ian Evans <dheianevans@gmail.com> wrote:
>
> On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
> <gary.buhrmaster@gmail.com> wrote:
> >
> > On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com> wrote:
> >
> > > Any idea what I should be looking at?
> >
> > WAG's follows:
>
> That took me a second. LOL.
>
> >
> > What does mediainfo indicate about the recording?
> > There are a few locations where the non-primary
> > subchannel(s) is in a non-mpeg2 format[0] that one
> > may need different decoders (or hardware) to
> > decode.
>
> Even though there was a 300 MB .ts file, mediainfo wasn't able to read it.
>
> To clarify, this was just a test on a clean system, so completely new
> installation, nothing to upgrade. When I was testing jellyfin, their
> DVR was able to record them fine. But wow, did I miss the
> functionality of MythTV for TV. So I nuked all that. Looking at the
> logs, I do see a ton of lines about "Malformed NAL units" right after
> the subchannel recording started:
>
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I CoreContext
> scheduler.cpp:717 (UpdateRecStatus) Updating status for Posse on
> cardid [3] (Tuning => Recording)
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> tv_rec.cpp:4146 (TuningNewRecorder) TVRec[3]: rec->GetPathname():
> '/media/disk2/15103_20230217032800.ts'
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> tv_rec.cpp:4179 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
> CreateRecorder()
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
> HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
> AVCParser::addbytes: malformed NAL units
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[4]: ASK_RECORDING 4 0
> 0 0
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
> HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
> AVCParser::addbytes: malformed NAL units
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[1]: ASK_RECORDING 1 0
> 0 0
> Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[5]: ASK_RECORDING 5 0
> 0 0

[snip]

UPDATE: Ok, so it's not the subchannel, it's the multirec.

I went into program guide and started recording 7.2. That recorded
fine. A minute later I started recording 7.1. That exhibited the same
issue as before. I have two tuners setup for the homerun and both are
set to eight max recordings. 32 has a different HDHomerun setup than I
had back in .27 so I'm not sure which other settings I need to look
at. Heading to bed, but can answer questions about the config on
Friday. Thanks!
_______________________________________________
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
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, 17 Feb 2023 at 05:31, Ian Evans <dheianevans@gmail.com> wrote:

> On Thu, Feb 16, 2023 at 10:57 PM Ian Evans <dheianevans@gmail.com> wrote:
> >
> > On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
> > <gary.buhrmaster@gmail.com> wrote:
> > >
> > > On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com>
> wrote:
> > >
> > > > Any idea what I should be looking at?
> > >
> > > WAG's follows:
> >
> > That took me a second. LOL.
> >
> > >
> > > What does mediainfo indicate about the recording?
> > > There are a few locations where the non-primary
> > > subchannel(s) is in a non-mpeg2 format[0] that one
> > > may need different decoders (or hardware) to
> > > decode.
> >
> > Even though there was a 300 MB .ts file, mediainfo wasn't able to read
> it.
> >
> > To clarify, this was just a test on a clean system, so completely new
> > installation, nothing to upgrade. When I was testing jellyfin, their
> > DVR was able to record them fine. But wow, did I miss the
> > functionality of MythTV for TV. So I nuked all that. Looking at the
> > logs, I do see a ton of lines about "Malformed NAL units" right after
> > the subchannel recording started:
> >
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I CoreContext
> > scheduler.cpp:717 (UpdateRecStatus) Updating status for Posse on
> > cardid [3] (Tuning => Recording)
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> > tv_rec.cpp:4146 (TuningNewRecorder) TVRec[3]: rec->GetPathname():
> > '/media/disk2/15103_20230217032800.ts'
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> > tv_rec.cpp:4179 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
> > CreateRecorder()
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
> > HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
> > AVCParser::addbytes: malformed NAL units
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[4]: ASK_RECORDING 4 0
> > 0 0
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
> > HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
> > AVCParser::addbytes: malformed NAL units
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[1]: ASK_RECORDING 1 0
> > 0 0
> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[5]: ASK_RECORDING 5 0
> > 0 0
>
> [snip]
>
> UPDATE: Ok, so it's not the subchannel, it's the multirec.
>
> I went into program guide and started recording 7.2. That recorded
> fine. A minute later I started recording 7.1. That exhibited the same
> issue as before. I have two tuners setup for the homerun and both are
> set to eight max recordings. 32 has a different HDHomerun setup than I
> had back in .27 so I'm not sure which other settings I need to look
> at. Heading to bed, but can answer questions about the config on
> Friday. Thanks!
>
> MythTV 27 uses static tuner assignment and that means the HDHR cannot be
shared with other devices.
MythTV 32 (30+ IIRC) uses a dynamic allocation scheme that allows sharing
the HDHR with other devices that have implemented the dynamic allocation
scheme.
So if you want to use the new version 32 system make sure the old version
27 system is disconnected. Note that "not recording" can mean it is still
doing EIT.

You might want to check the software version of the HDHR and possibly do an
update of the software. This can be done with the hdhomerun-config or the
hdhomerun-config-gui app. The source code of this can be downloaded from
the Silicon Dust website.
It could be that the software in the HDHR is too old and that it does not
yet (or does not properly) implement the dynamic allocation.

Everything you always wanted to know about tuner configuration and channel
scanning can be found here https://www.mythtv.org/wiki/Channel_Scanning and
especially for the HDHR there is this paragraph
https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_HDHomeRun_tuners

Klaas.
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, Feb 17, 2023 at 2:40 AM Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
>
>
> On Fri, 17 Feb 2023 at 05:31, Ian Evans <dheianevans@gmail.com> wrote:
>>
>> On Thu, Feb 16, 2023 at 10:57 PM Ian Evans <dheianevans@gmail.com> wrote:
>> >
>> > On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
>> > <gary.buhrmaster@gmail.com> wrote:
>> > >
>> > > On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com> wrote:
>> > >
>> > > > Any idea what I should be looking at?
>> > >
>> > > WAG's follows:
>> >
>> > That took me a second. LOL.
>> >
>> > >
>> > > What does mediainfo indicate about the recording?
>> > > There are a few locations where the non-primary
>> > > subchannel(s) is in a non-mpeg2 format[0] that one
>> > > may need different decoders (or hardware) to
>> > > decode.
>> >
>> > Even though there was a 300 MB .ts file, mediainfo wasn't able to read it.
>> >
>> > To clarify, this was just a test on a clean system, so completely new
>> > installation, nothing to upgrade. When I was testing jellyfin, their
>> > DVR was able to record them fine. But wow, did I miss the
>> > functionality of MythTV for TV. So I nuked all that. Looking at the
>> > logs, I do see a ton of lines about "Malformed NAL units" right after
>> > the subchannel recording started:
>> >
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I CoreContext
>> > scheduler.cpp:717 (UpdateRecStatus) Updating status for Posse on
>> > cardid [3] (Tuning => Recording)
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
>> > tv_rec.cpp:4146 (TuningNewRecorder) TVRec[3]: rec->GetPathname():
>> > '/media/disk2/15103_20230217032800.ts'
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
>> > tv_rec.cpp:4179 (TuningNewRecorder) TVRec[3]: TuningNewRecorder -
>> > CreateRecorder()
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
>> > HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
>> > AVCParser::addbytes: malformed NAL units
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
>> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[4]: ASK_RECORDING 4 0
>> > 0 0
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: E
>> > HDHRStreamHandler mpeg/AVCParser.cpp:410 (addBytes)
>> > AVCParser::addbytes: malformed NAL units
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
>> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[1]: ASK_RECORDING 1 0
>> > 0 0
>> > Feb 16 22:27:31 bhmf mythbackend: mythbackend[19718]: I TVRecEvent
>> > tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[5]: ASK_RECORDING 5 0
>> > 0 0
>>
>> [snip]
>>
>> UPDATE: Ok, so it's not the subchannel, it's the multirec.
>>
>> I went into program guide and started recording 7.2. That recorded
>> fine. A minute later I started recording 7.1. That exhibited the same
>> issue as before. I have two tuners setup for the homerun and both are
>> set to eight max recordings. 32 has a different HDHomerun setup than I
>> had back in .27 so I'm not sure which other settings I need to look
>> at. Heading to bed, but can answer questions about the config on
>> Friday. Thanks!
>>
> MythTV 27 uses static tuner assignment and that means the HDHR cannot be shared with other devices.
> MythTV 32 (30+ IIRC) uses a dynamic allocation scheme that allows sharing the HDHR with other devices that have implemented the dynamic allocation scheme.
> So if you want to use the new version 32 system make sure the old version 27 system is disconnected. Note that "not recording" can mean it is still doing EIT.
>
> You might want to check the software version of the HDHR and possibly do an update of the software. This can be done with the hdhomerun-config or the hdhomerun-config-gui app. The source code of this can be downloaded from the Silicon Dust website.
> It could be that the software in the HDHR is too old and that it does not yet (or does not properly) implement the dynamic allocation.
>
> Everything you always wanted to know about tuner configuration and channel scanning can be found here https://www.mythtv.org/wiki/Channel_Scanning and especially for the HDHR there is this paragraph https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_HDHomeRun_tuners
>

Just to further clarify further, this is a brand new install miles
away from my .27 system at home. So there is no conflict there. :-)
Just wanted to mess around with 32 while I was here and before I do it
at home. The hdhomerun firmware is from December 20221205.

I can record on both tuners. I just can't record additional channels
on the same frequencies . That is, I can record 7.1 and 2.1 at the
same time but cannot also record 2.4 and 7.2. Will mess around further
today.
_______________________________________________
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
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, Feb 17, 2023, 7:43 AM Ian Evans, <dheianevans@gmail.com> wrote:

> On Fri, Feb 17, 2023 at 2:40 AM Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
> >
> >
> >
> > On Fri, 17 Feb 2023 at 05:31, Ian Evans <dheianevans@gmail.com> wrote:
> >>
> >> On Thu, Feb 16, 2023 at 10:57 PM Ian Evans <dheianevans@gmail.com>
> wrote:
> >> >
> >> > On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
> >> > <gary.buhrmaster@gmail.com> wrote:
> >> > >
> >> > > On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com>
> wrote:
> >> > >
> >> > > > Any idea what I should be looking at?
> >> > >
> >> > > WAG's follows:
> >> >
> >> > That took me a second. LOL.
> >> >
> >> > >
> >> > > What does mediainfo indicate about the recording?
> >> > > There are a few locations where the non-primary
> >> > > subchannel(s) is in a non-mpeg2 format[0] that one
> >> > > may need different decoders (or hardware) to
> >> > > decode.
> >> >
> >> > Even though there was a 300 MB .ts file, mediainfo wasn't able to
> read it.
> >> >
> >> > To clarify, this was just a test on a clean system, so completely new
> >> > installation, nothing to upgrade. When I was testing jellyfin, their
> >> > DVR was able to record them fine. But wow, did I miss the
> >> > functionality of MythTV for TV. So I nuked all that. Looking at the
> >> > logs, I do see a ton of lines about "Malformed NAL units" right after
> >> > the subchannel recording started:
> >> >
> >> [snip]
> >>
> >> UPDATE: Ok, so it's not the subchannel, it's the multirec.
> >>
> >> I went into program guide and started recording 7.2. That recorded
> >> fine. A minute later I started recording 7.1. That exhibited the same
> >> issue as before. I have two tuners setup for the homerun and both are
> >> set to eight max recordings. 32 has a different HDHomerun setup than I
> >> had back in .27 so I'm not sure which other settings I need to look
> >> at. Heading to bed, but can answer questions about the config on
> >> Friday. Thanks!
> >>
> > MythTV 27 uses static tuner assignment and that means the HDHR cannot be
> shared with other devices.
> > MythTV 32 (30+ IIRC) uses a dynamic allocation scheme that allows
> sharing the HDHR with other devices that have implemented the dynamic
> allocation scheme.
> > So if you want to use the new version 32 system make sure the old
> version 27 system is disconnected. Note that "not recording" can mean it is
> still doing EIT.
> >
> > You might want to check the software version of the HDHR and possibly do
> an update of the software. This can be done with the hdhomerun-config or
> the hdhomerun-config-gui app. The source code of this can be downloaded
> from the Silicon Dust website.
> > It could be that the software in the HDHR is too old and that it does
> not yet (or does not properly) implement the dynamic allocation.
> >
> > Everything you always wanted to know about tuner configuration and
> channel scanning can be found here
> https://www.mythtv.org/wiki/Channel_Scanning and especially for the HDHR
> there is this paragraph
> https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_HDHomeRun_tuners
> >
>
> Just to further clarify further, this is a brand new install miles
> away from my .27 system at home. So there is no conflict there. :-)
> Just wanted to mess around with 32 while I was here and before I do it
> at home. The hdhomerun firmware is from December 20221205.
>
> I can record on both tuners. I just can't record additional channels
> on the same frequencies . That is, I can record 7.1 and 2.1 at the
> same time but cannot also record 2.4 and 7.2. Will mess around further
> today.
>

Just realized what the issue probably is. The homerun here is the Extend
model. Just checked and transcoding is on. Will turn that off and will try
MythTV later.

>
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, Feb 17, 2023, 8:10 AM Ian Evans, <dheianevans@gmail.com> wrote:

> On Fri, Feb 17, 2023, 7:43 AM Ian Evans, <dheianevans@gmail.com> wrote:
>
>> On Fri, Feb 17, 2023 at 2:40 AM Klaas de Waal <klaas.de.waal@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Fri, 17 Feb 2023 at 05:31, Ian Evans <dheianevans@gmail.com> wrote:
>> >>
>> >> On Thu, Feb 16, 2023 at 10:57 PM Ian Evans <dheianevans@gmail.com>
>> wrote:
>> >> >
>> >> > On Thu, Feb 16, 2023 at 10:16 PM Gary Buhrmaster
>> >> > <gary.buhrmaster@gmail.com> wrote:
>> >> > >
>> >> > > On Fri, Feb 17, 2023 at 1:10 AM Ian Evans <dheianevans@gmail.com>
>> wrote:
>> >> > >
>> >> > > > Any idea what I should be looking at?
>> >> > >
>> >> > > WAG's follows:
>> >> >
>> >> > That took me a second. LOL.
>> >> >
>> >> > >
>> >> > > What does mediainfo indicate about the recording?
>> >> > > There are a few locations where the non-primary
>> >> > > subchannel(s) is in a non-mpeg2 format[0] that one
>> >> > > may need different decoders (or hardware) to
>> >> > > decode.
>> >> >
>> >> > Even though there was a 300 MB .ts file, mediainfo wasn't able to
>> read it.
>> >> >
>> >> > To clarify, this was just a test on a clean system, so completely new
>> >> > installation, nothing to upgrade. When I was testing jellyfin, their
>> >> > DVR was able to record them fine. But wow, did I miss the
>> >> > functionality of MythTV for TV. So I nuked all that. Looking at the
>> >> > logs, I do see a ton of lines about "Malformed NAL units" right after
>> >> > the subchannel recording started:
>> >> >
>> >> [snip]
>> >>
>> >> UPDATE: Ok, so it's not the subchannel, it's the multirec.
>> >>
>> >> I went into program guide and started recording 7.2. That recorded
>> >> fine. A minute later I started recording 7.1. That exhibited the same
>> >> issue as before. I have two tuners setup for the homerun and both are
>> >> set to eight max recordings. 32 has a different HDHomerun setup than I
>> >> had back in .27 so I'm not sure which other settings I need to look
>> >> at. Heading to bed, but can answer questions about the config on
>> >> Friday. Thanks!
>> >>
>> > MythTV 27 uses static tuner assignment and that means the HDHR cannot
>> be shared with other devices.
>> > MythTV 32 (30+ IIRC) uses a dynamic allocation scheme that allows
>> sharing the HDHR with other devices that have implemented the dynamic
>> allocation scheme.
>> > So if you want to use the new version 32 system make sure the old
>> version 27 system is disconnected. Note that "not recording" can mean it is
>> still doing EIT.
>> >
>> > You might want to check the software version of the HDHR and possibly
>> do an update of the software. This can be done with the hdhomerun-config or
>> the hdhomerun-config-gui app. The source code of this can be downloaded
>> from the Silicon Dust website.
>> > It could be that the software in the HDHR is too old and that it does
>> not yet (or does not properly) implement the dynamic allocation.
>> >
>> > Everything you always wanted to know about tuner configuration and
>> channel scanning can be found here
>> https://www.mythtv.org/wiki/Channel_Scanning and especially for the HDHR
>> there is this paragraph
>> https://www.mythtv.org/wiki/Channel_Scanning#Scanning_with_HDHomeRun_tuners
>> >
>>
>> Just to further clarify further, this is a brand new install miles
>> away from my .27 system at home. So there is no conflict there. :-)
>> Just wanted to mess around with 32 while I was here and before I do it
>> at home. The hdhomerun firmware is from December 20221205.
>>
>> I can record on both tuners. I just can't record additional channels
>> on the same frequencies . That is, I can record 7.1 and 2.1 at the
>> same time but cannot also record 2.4 and 7.2. Will mess around further
>> today.
>>
>
> Just realized what the issue probably is. The homerun here is the Extend
> model. Just checked and transcoding is on. Will turn that off and will try
> MythTV later.
>

As per my realization this morning, the errors were due to the Extend's
transcode being on. Working now.

Thanks.

>
Re: getting video decode errors on ATSC subchannels [ In reply to ]
On Fri, Feb 17, 2023 at 1:12 PM Ian Evans <dheianevans@gmail.com> wrote:

>
> Just realized what the issue probably is. The homerun here is the Extend model. Just checked and transcoding is on. Will turn that off and will try MythTV later.
>

As I recall, the transcoding engine is documented
to be intended to be used only with the HTTP
streaming transport API[0], and not the legacy
transport. Since (without using a 3rd party
external recorder) MythTV uses the legacy (UDP)
transport with HDHR tuners one likely hit one of
the unsupported use cases of trying to deal
with multiple programs (via multirec) when
transcoding was enabled[1].


[0] The transcoding engine supports transcoding
only a single program stream per tuner.

[1] In theory either the HDHR or MythTV should
deal with those cases better than the errors you
received. You would likely need to spend some
time obtaining raw transport streams to determine
what is actually happening, and what needs to
be enhanced. I suspect the easier answer is
"don't do that", which is what you eventually
determined was a solution, and did.
_______________________________________________
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