Mailing List Archive

On 27/07/2022 18:15, Scott Theisen wrote:
> On 7/27/22 11:15, John Pilkington wrote:
>> On 27/07/2022 14:20, John Pilkington wrote:
>>
>>> My apologies, but I'm having git problems again and ought to do
>>> something else.  I created a local sub-branch for the earlier work on
>>> frame counting, and it's getting in the way.
>>
>> I think that got fixed by deleting the contents of my repoB folder and
>> recloning from repoA.  Now it would build the real current
>> devel/ffmpeg-resync but git apply --check reports a patching error
>> with what I extracted from your email.  Perhaps an attachment? Thanks.
>>>
>>>  > John
>
> I don't think my original patch would have worked correctly anyways. Try
> the attached instead.
>
> If this correctly demuxes two DSMCC_B streams for your sample I will
> consider this "working" even if you can't test the interactive TV
> behavior versus master.
>
> Could you upload your sample somewhere so I can try to test it myself?
>
> Thanks,
>
> Scott

https://drive.google.com/file/d/1Xm5dSJVRZj3BgGl38xPp6USGuQm2lzq_/view?usp=sharing
_______________________________________________
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

On 7/27/22 14:14, John Pilkington wrote:
> On 27/07/2022 18:15, Scott Theisen wrote:
>> On 7/27/22 11:15, John Pilkington wrote:
>>> On 27/07/2022 14:20, John Pilkington wrote:
>>>
>>>> My apologies, but I'm having git problems again and ought to do
>>>> something else.  I created a local sub-branch for the earlier work
>>>> on frame counting, and it's getting in the way.
>>>
>>> I think that got fixed by deleting the contents of my repoB folder
>>> and recloning from repoA.  Now it would build the real current
>>> devel/ffmpeg-resync but git apply --check reports a patching error
>>> with what I extracted from your email.  Perhaps an attachment? Thanks.
>>>>
>>>>  > John
>>
>> I don't think my original patch would have worked correctly anyways.
>> Try the attached instead.
>>
>> If this correctly demuxes two DSMCC_B streams for your sample I will
>> consider this "working" even if you can't test the interactive TV
>> behavior versus master.
>>
>> Could you upload your sample somewhere so I can try to test it myself?
>>
>> Thanks,
>>
>> Scott
>
> https://drive.google.com/file/d/1Xm5dSJVRZj3BgGl38xPp6USGuQm2lzq_/view?usp=sharing
>

Playback as a video worked fine with my extra commit, but MHEG may be
broken in master.  I would still like a log from mythcommflag though to
confirm it works as expected.

Of note, the DSMCC_B streams are correctly labeled (which they aren't
with the FFmpeg demuxer) but the log lines that should be there are
mysteriously missing.

Thanks,

Scott
_______________________________________________
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

On 27/07/2022 19:14, John Pilkington wrote:
> On 27/07/2022 18:15, Scott Theisen wrote:
>> On 7/27/22 11:15, John Pilkington wrote:
>>> On 27/07/2022 14:20, John Pilkington wrote:
>>>
>>>> My apologies, but I'm having git problems again and ought to do
>>>> something else.  I created a local sub-branch for the earlier work
>>>> on frame counting, and it's getting in the way.
>>>
>>> I think that got fixed by deleting the contents of my repoB folder
>>> and recloning from repoA.  Now it would build the real current
>>> devel/ffmpeg-resync but git apply --check reports a patching error
>>> with what I extracted from your email.  Perhaps an attachment? Thanks.
>>>>
>>>>  > John
>>
>> I don't think my original patch would have worked correctly anyways.
>> Try the attached instead.
>>
>> If this correctly demuxes two DSMCC_B streams for your sample I will
>> consider this "working" even if you can't test the interactive TV
>> behavior versus master.
>>
>> Could you upload your sample somewhere so I can try to test it myself?
>>
>> Thanks,
>>
>> Scott
>
> https://drive.google.com/file/d/1Xm5dSJVRZj3BgGl38xPp6USGuQm2lzq_/view?usp=sharing
>
Attached is mythcommflag --resync log for the same BBC ONE newsclip using

https://github.com/MythTV/mythtv/commit/d16fafb504110d12d55e698e12bf21c5aea7a082

with

0001-libavformat-mpegts-mythtv.c-reuse-existing-DSMCC_B-s.patch

Quitting playback of this clip no longer causes a crash.

Thanks and regards,

John

On 7/27/22 17:20, John Pilkington wrote:
> On 27/07/2022 19:14, John Pilkington wrote:
>> On 27/07/2022 18:15, Scott Theisen wrote:
>>> On 7/27/22 11:15, John Pilkington wrote:
>>>> On 27/07/2022 14:20, John Pilkington wrote:
>>>>
>>>>> My apologies, but I'm having git problems again and ought to do
>>>>> something else.  I created a local sub-branch for the earlier work
>>>>> on frame counting, and it's getting in the way.
>>>>
>>>> I think that got fixed by deleting the contents of my repoB folder
>>>> and recloning from repoA.  Now it would build the real current
>>>> devel/ffmpeg-resync but git apply --check reports a patching error
>>>> with what I extracted from your email.  Perhaps an attachment? Thanks.
>>>>>
>>>>>  > John
>>>
>>> I don't think my original patch would have worked correctly anyways.
>>> Try the attached instead.
>>>
>>> If this correctly demuxes two DSMCC_B streams for your sample I will
>>> consider this "working" even if you can't test the interactive TV
>>> behavior versus master.
>>>
>>> Could you upload your sample somewhere so I can try to test it myself?
>>>
>>> Thanks,
>>>
>>> Scott
>>
>> https://drive.google.com/file/d/1Xm5dSJVRZj3BgGl38xPp6USGuQm2lzq_/view?usp=sharing
>>
> Attached is mythcommflag --resync log for the same BBC ONE newsclip using
>
> https://github.com/MythTV/mythtv/commit/d16fafb504110d12d55e698e12bf21c5aea7a082
>
>
> with
>
> 0001-libavformat-mpegts-mythtv.c-reuse-existing-DSMCC_B-s.patch
>
> Quitting playback of this clip no longer causes a crash.
>
> Thanks and regards,
>
> John

Thanks for testing and the sample.  Unfortunately, I appear to have
broken MHEG, so I'll need to fix that with the help of your sample.

Regards,

Scott

_______________________________________________
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

This is the commit that causes a failure on BBC streams with
the devel/ffmpeg-resync branch:

1bba2b59941d575ade7206d0ba52a556f5d3e672 is the first bad commit
commit 1bba2b59941d575ade7206d0ba52a556f5d3e672
Author: Scott Theisen <scott.the.elm@gmail.com>
Date: Fri Mar 18 00:34:50 2022 -0400

The problem is not in the MHEG processing but in the presence of the
streams that contain the additional MHEG information.
With MHEG processing disabled it crashes in the same way.

Details:
- BBC streams received from Astra-2 satellite (a.k.a. Freesat).
- When playing a recording, the failure is on stopping playback.
- When using Live TV the failure is immediate, probably because Live TV
does a start / stop / start sequence when starting playback.

Could just be that your new reference counting code is not very good at
counting....

Hope this helps,
Klaas.








On Thu, 28 Jul 2022 at 01:45, Scott Theisen <scott.the.elm@gmail.com> wrote:

> On 7/27/22 17:20, John Pilkington wrote:
> > On 27/07/2022 19:14, John Pilkington wrote:
> >> On 27/07/2022 18:15, Scott Theisen wrote:
> >>> On 7/27/22 11:15, John Pilkington wrote:
> >>>> On 27/07/2022 14:20, John Pilkington wrote:
> >>>>
> >>>>> My apologies, but I'm having git problems again and ought to do
> >>>>> something else. I created a local sub-branch for the earlier work
> >>>>> on frame counting, and it's getting in the way.
> >>>>
> >>>> I think that got fixed by deleting the contents of my repoB folder
> >>>> and recloning from repoA. Now it would build the real current
> >>>> devel/ffmpeg-resync but git apply --check reports a patching error
> >>>> with what I extracted from your email. Perhaps an attachment? Thanks.
> >>>>>
> >>>>> > John
> >>>
> >>> I don't think my original patch would have worked correctly anyways.
> >>> Try the attached instead.
> >>>
> >>> If this correctly demuxes two DSMCC_B streams for your sample I will
> >>> consider this "working" even if you can't test the interactive TV
> >>> behavior versus master.
> >>>
> >>> Could you upload your sample somewhere so I can try to test it myself?
> >>>
> >>> Thanks,
> >>>
> >>> Scott
> >>
> >>
> https://drive.google.com/file/d/1Xm5dSJVRZj3BgGl38xPp6USGuQm2lzq_/view?usp=sharing
> >>
> > Attached is mythcommflag --resync log for the same BBC ONE newsclip using
> >
> >
> https://github.com/MythTV/mythtv/commit/d16fafb504110d12d55e698e12bf21c5aea7a082
> >
> >
> > with
> >
> > 0001-libavformat-mpegts-mythtv.c-reuse-existing-DSMCC_B-s.patch
> >
> > Quitting playback of this clip no longer causes a crash.
> >
> > Thanks and regards,
> >
> > John
>
> Thanks for testing and the sample. Unfortunately, I appear to have
> broken MHEG, so I'll need to fix that with the help of your sample.
>
> Regards,
>
> Scott
>
> _______________________________________________
> 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
>

On 7/29/22 09:35, Klaas de Waal wrote:
> This is the commit that causes a failure on BBC streams with
> the devel/ffmpeg-resync branch:
>
> 1bba2b59941d575ade7206d0ba52a556f5d3e672 is the first bad commit
> commit 1bba2b59941d575ade7206d0ba52a556f5d3e672
> Author: Scott Theisen <scott.the.elm@gmail.com>
> Date:   Fri Mar 18 00:34:50 2022 -0400
>
> The problem is not in the MHEG processing but in the presence of the
> streams that contain the additional MHEG information.
> With MHEG processing disabled it crashes in the same way.
>
> Details:
> - BBC streams received from Astra-2 satellite (a.k.a. Freesat).
> - When playing a recording, the failure is on stopping playback.
> - When using Live TV the failure is immediate, probably because Live
> TV does a start / stop / start sequence when starting playback.
>
> Could just be that your new reference counting code is not very good
> at counting....
>
>

I think that is the problem John was having.  add_section_stream()
reuses the SectionContext if it already exists, but this causes the same
pointer to be added to multiple streams' `priv_data`, causing crashes
when it is then double freed.  My patch prevented this double freeing,
but the DSMCC_B code is never executed, so it doesn't work.

However, with my new MHEG sample from John, I can't bring up the menu
for the interactive TV after only 6 commits, so I am working through
that commit splitting it into smaller pieces to find what broke MHEG.

Regards,

Scott
_______________________________________________
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

On 29/07/2022 18:17, Scott Theisen wrote:
> On 7/29/22 09:35, Klaas de Waal wrote:
>> This is the commit that causes a failure on BBC streams with
>> the devel/ffmpeg-resync branch:
>>
>> 1bba2b59941d575ade7206d0ba52a556f5d3e672 is the first bad commit
>> commit 1bba2b59941d575ade7206d0ba52a556f5d3e672
>> Author: Scott Theisen <scott.the.elm@gmail.com>
>> Date:   Fri Mar 18 00:34:50 2022 -0400
>>
>> The problem is not in the MHEG processing but in the presence of the
>> streams that contain the additional MHEG information.
>> With MHEG processing disabled it crashes in the same way.
>>
>> Details:
>> - BBC streams received from Astra-2 satellite (a.k.a. Freesat).
>> - When playing a recording, the failure is on stopping playback.
>> - When using Live TV the failure is immediate, probably because Live
>> TV does a start / stop / start sequence when starting playback.
>>
>> Could just be that your new reference counting code is not very good
>> at counting....
>>
>>
>
> I think that is the problem John was having.  add_section_stream()
> reuses the SectionContext if it already exists, but this causes the same
> pointer to be added to multiple streams' `priv_data`, causing crashes
> when it is then double freed.  My patch prevented this double freeing,
> but the DSMCC_B code is never executed, so it doesn't work.
>
> However, with my new MHEG sample from John, I can't bring up the menu
> for the interactive TV after only 6 commits, so I am working through
> that commit splitting it into smaller pieces to find what broke MHEG.
>
> Regards,
>
> Scott

Largely as an excercise-for-the-student, I now have a build from Scott's
pull request, labelled 32Pre4276, git f27fd9c, installed and running.
The MHEG menu works on the recent clip, and also on an HD clip from last
year where the cutting had retained the full set of streams. Both show
today's date...

Cheers,

John
_______________________________________________
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

On 8/1/22 10:47, John Pilkington wrote:
> On 29/07/2022 18:17, Scott Theisen wrote:
>> On 7/29/22 09:35, Klaas de Waal wrote:
>>> This is the commit that causes a failure on BBC streams with
>>> the devel/ffmpeg-resync branch:
>>>
>>> 1bba2b59941d575ade7206d0ba52a556f5d3e672 is the first bad commit
>>> commit 1bba2b59941d575ade7206d0ba52a556f5d3e672
>>> Author: Scott Theisen <scott.the.elm@gmail.com>
>>> Date:   Fri Mar 18 00:34:50 2022 -0400
>>>
>>> The problem is not in the MHEG processing but in the presence of the
>>> streams that contain the additional MHEG information.
>>> With MHEG processing disabled it crashes in the same way.
>>>
>>> Details:
>>> - BBC streams received from Astra-2 satellite (a.k.a. Freesat).
>>> - When playing a recording, the failure is on stopping playback.
>>> - When using Live TV the failure is immediate, probably because Live
>>> TV does a start / stop / start sequence when starting playback.
>>>
>>> Could just be that your new reference counting code is not very good
>>> at counting....
>>>
>>>
>>
>> I think that is the problem John was having. add_section_stream()
>> reuses the SectionContext if it already exists, but this causes the
>> same pointer to be added to multiple streams' `priv_data`, causing
>> crashes when it is then double freed.  My patch prevented this double
>> freeing, but the DSMCC_B code is never executed, so it doesn't work.
>>
>> However, with my new MHEG sample from John, I can't bring up the menu
>> for the interactive TV after only 6 commits, so I am working through
>> that commit splitting it into smaller pieces to find what broke MHEG.
>>
>> Regards,
>>
>> Scott
>
> Largely as an excercise-for-the-student, I now have a build from
> Scott's pull request, labelled 32Pre4276, git f27fd9c, installed and
> running. The MHEG menu works on the recent clip, and also on an HD
> clip from last year where the cutting had retained the full set of
> streams.

Good to hear that my new version works correctly.

> Both show today's date...
>

This is probably intentional since it is intended to be used with live
TV.  What I think is happening is the MHEG program is calling
GetCurrentDate() and then FormatDate() instead of hard coding into the
stream what date (and time) it wants formatted.

Regards,

Scott

_______________________________________________
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

On 02/08/2022 19:44, Scott Theisen wrote:
> On 8/1/22 10:47, John Pilkington wrote:

>> Largely as an excercise-for-the-student, I now have a build from
>> Scott's pull request, labelled 32Pre4276, git f27fd9c, installed and
>> running. The MHEG menu works on the recent clip, and also on an HD
>> clip from last year where the cutting had retained the full set of
>> streams.
>
> Good to hear that my new version works correctly.
>
>> Both show today's date...
>>
>
> This is probably intentional since it is intended to be used with live
> TV.  What I think is happening is the MHEG program is calling
> GetCurrentDate() and then FormatDate() instead of hard coding into the
> stream what date (and time) it wants formatted.
>
> Regards,
>
> Scott

Hmm. I now have fixes/32 and devel/ffmpeg-resync both playing the same
recording-in-progress.

fixes/32 says it's
06:10 on Thursday 20 Jan

while the newer version shows
10:46 on Thursday 11 Aug

John
_______________________________________________
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

On 8/11/22 05:47, John Pilkington wrote:
> On 02/08/2022 19:44, Scott Theisen wrote:
>> On 8/1/22 10:47, John Pilkington wrote:
>
>>> Largely as an excercise-for-the-student, I now have a build from
>>> Scott's pull request, labelled 32Pre4276, git f27fd9c, installed and
>>> running. The MHEG menu works on the recent clip, and also on an HD
>>> clip from last year where the cutting had retained the full set of
>>> streams.
>>
>> Good to hear that my new version works correctly.
>>
>>> Both show today's date...
>>>
>>
>> This is probably intentional since it is intended to be used with
>> live TV.  What I think is happening is the MHEG program is calling
>> GetCurrentDate() and then FormatDate() instead of hard coding into
>> the stream what date (and time) it wants formatted.
>>
>> Regards,
>>
>> Scott
>
> Hmm.  I now have fixes/32 and devel/ffmpeg-resync both playing the
> same recording-in-progress.
>
> fixes/32 says it's
> 06:10 on Thursday 20 Jan
>
> while the newer version shows
> 10:46 on Thursday 11 Aug
>
> John

That is a bug I fixed in
https://github.com/MythTV/mythtv/commit/b987f5bbaff2d820bd1967348a5abb98bcb82dd2
as part of https://github.com/MythTV/mythtv/pull/564 .  I'll see about
backporting it to fixes/32.

The day of the week is from GetDayOfWeek which is for the current time. 
However, FormatDate incorrectly used QDateTime::fromMSecsSinceEpoch()
instead of QDateTime::fromSecsSinceEpoch() (note: MS instead of S, so
off by a factor of 1000).

https://www.wolframalpha.com/input?i=1660214760+unix+time is 10:46:00 am
UTC | Thursday, August 11, 2022
https://www.wolframalpha.com/input?i=1660214+unix+time is 5:10:14 am UTC
| Tuesday, January 20, 1970

There should be a daylight saving time offset of an hour to one of
those, so it is as I expect the bug to manifest.

Scott


_______________________________________________
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