Mailing List Archive: Re: [mythtv-commits] [MythTV/mythtv] cf8015: No discontinuity for first TS packet of PID

Re: [mythtv-commits] [MythTV/mythtv] cf8015: No discontinuity for first TS packet of PID

Aug 29, 2020, 12:42 PM

Post #1 of 3 (640 views)

On Sat, Aug 29, 2020 at 07:36:37AM -0700, kmdewaal wrote:
> Branch: refs/heads/master
> Home: https://github.com/MythTV/mythtv
> Commit: cf8015eaf4a2fde6ece423e7ade99c86f7f9d076
> https://github.com/MythTV/mythtv/commit/cf8015eaf4a2fde6ece423e7ade99c86f7f9d076
> Author: Klaas de Waal <kdewaal@mythtv.org>
> Date: 2020-08-29 (Sat, 29 Aug 2020)
>
> Changed paths:
> M mythtv/libs/libmythtv/recorders/dtvrecorder.cpp
> M mythtv/libs/libmythtv/recorders/dtvrecorder.h
>
> Log Message:
> -----------
> No discontinuity for first TS packet of PID
>
> Do not count the discontinuity from 0 to the continuity counter value of the first transport stream
> packet of a PID as an error and consequently do also not give a "discontinuity detected" error message.
> A perfect recording will now report a continuity_error_count of 0 instead of approximately the number of PIDs in the recording.

By sheer coincidence, I've been debugging an issue with my setup and
have been watching for continuity errors. I was lamenting the fact
that there were often false positives reported every time a recording
starts when I saw you committed this change. I see one problem with
the change, though. 1/16th of the time, the first counter seen will
actually be 0, which is the inital value in m_continuityCounter. When
that happens, reporting of the first, real discontinuity will be
suppressed.

I believe the attached patch fixes that issue by initializing
m_continuityCounter to an impossible value. That will always cause an
initial continuity that can be safely ignored. All continuity errors
after that will be real and can be reported.

David
--
David Engel
david@istwok.net

Re: [mythtv-commits] [MythTV/mythtv] cf8015: No discontinuity for first TS packet of PID [ In reply to ]

klaas.de.waal at gmail

Aug 29, 2020, 1:52 PM

Post #2 of 3 (640 views)

Permalink

On Sat, 29 Aug 2020 at 21:43, David Engel <david@istwok.net> wrote:

> On Sat, Aug 29, 2020 at 07:36:37AM -0700, kmdewaal wrote:
> > Branch: refs/heads/master
> > Home: https://github.com/MythTV/mythtv
> > Commit: cf8015eaf4a2fde6ece423e7ade99c86f7f9d076
> >
> https://github.com/MythTV/mythtv/commit/cf8015eaf4a2fde6ece423e7ade99c86f7f9d076
> > Author: Klaas de Waal <kdewaal@mythtv.org>
> > Date: 2020-08-29 (Sat, 29 Aug 2020)
> >
> > Changed paths:
> > M mythtv/libs/libmythtv/recorders/dtvrecorder.cpp
> > M mythtv/libs/libmythtv/recorders/dtvrecorder.h
> >
> > Log Message:
> > -----------
> > No discontinuity for first TS packet of PID
> >
> > Do not count the discontinuity from 0 to the continuity counter value of
> the first transport stream
> > packet of a PID as an error and consequently do also not give a
> "discontinuity detected" error message.
> > A perfect recording will now report a continuity_error_count of 0
> instead of approximately the number of PIDs in the recording.
>
> By sheer coincidence, I've been debugging an issue with my setup and
> have been watching for continuity errors. I was lamenting the fact
> that there were often false positives reported every time a recording
> starts when I saw you committed this change. I see one problem with
> the change, though. 1/16th of the time, the first counter seen will
> actually be 0, which is the inital value in m_continuityCounter. When
> that happens, reporting of the first, real discontinuity will be
> suppressed.
>
> I believe the attached patch fixes that issue by initializing
> m_continuityCounter to an impossible value. That will always cause an
> initial continuity that can be safely ignored. All continuity errors
> after that will be real and can be reported.
>
>
> Hi David,

Your analysis that 1/16th of the time the first real error is suppressed is
of course correct.
I do appreciate your patch but it does need initialisation of all elements
of m_continuityCounter to 0xff, not only the first element.
This can be done by calling m_continuityCounter.fill(0xff) in the
constructor, I cannot find a way to do this in the header file.
I am testing this now and will commit it later.

Thanks,
Klaas.

Re: [mythtv-commits] [MythTV/mythtv] cf8015: No discontinuity for first TS packet of PID [ In reply to ]

david at istwok

Aug 29, 2020, 2:53 PM

Post #3 of 3 (639 views)

Permalink

On Sat, Aug 29, 2020 at 10:52:16PM +0200, Klaas de Waal wrote:
> Your analysis that 1/16th of the time the first real error is suppressed is
> of course correct.
> I do appreciate your patch but it does need initialisation of all elements
> of m_continuityCounter to 0xff, not only the first element.
> This can be done by calling m_continuityCounter.fill(0xff) in the
> constructor, I cannot find a way to do this in the header file.
> I am testing this now and will commit it later.

Thanks for fixing my fix. I thought maybe the new, fangled
initializers repeated the last value as needed to fill arrays. Using
just a superfluous {0} for an array didn't, and still doesn't, make
sense to me. I searched for confirmation but didn't find what I was
looking for. I searched again just now and did find another syntax
that can initialize all elements to a non-zero value, but it's
apparently a gcc-only extension.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Mailing List Archive

Mailing List Archive

Attached Files: