Mailing List Archive

On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal <klaas.de.waal@gmail.com>
wrote:

> Hi,
>
> Yesterday I updated my backend to the latest master and since then some
> recordings are extended way beyond their scheduled end time, one of them
> extended to 21 hours (115GB). Guide data looks OK so I guess it is the
> recording. Could this be another "std:chrono" induced bug?
>

I recently saw this behavior as well. In my case it seemed to be doubling
the length of the recording. Since this was my production machine, I
reverted to 8e14fe7ceba96f and everything seems okay again. My development
machine is not really usable right now.

John

On Mon, 8 Feb 2021 at 19:27, John P Poet <jppoet@gmail.com> wrote:

> On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
>> Hi,
>>
>> Yesterday I updated my backend to the latest master and since then some
>> recordings are extended way beyond their scheduled end time, one of them
>> extended to 21 hours (115GB). Guide data looks OK so I guess it is the
>> recording. Could this be another "std:chrono" induced bug?
>>
>
> I recently saw this behavior as well. In my case it seemed to be doubling
> the length of the recording. Since this was my production machine, I
> reverted to 8e14fe7ceba96f and everything seems okay again. My development
> machine is not really usable right now.
>
>
> Looks here like recordings now extend until the start of the next
recording on the same tuner. This is with master of Sunday on Fedora 31.

Klaas.

On 08/02/2021 19:21, Klaas de Waal wrote:
>
>
> On Mon, 8 Feb 2021 at 19:27, John P Poet <jppoet@gmail.com
> <mailto:jppoet@gmail.com>> wrote:
>
> On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal
> <klaas.de.waal@gmail.com <mailto:klaas.de.waal@gmail.com>> wrote:
>
> Hi,
>
> Yesterday I updated my backend to the latest master and since
> then some recordings are extended way beyond their scheduled end
> time, one of them extended to 21 hours (115GB). Guide data looks
> OK so I guess it is the recording. Could this be another
> "std:chrono" induced bug?
>
>
> I recently saw this behavior as well. In my case it seemed to be
> doubling the length of the recording. Since this was my production
> machine, I reverted to 8e14fe7ceba96f and everything seems okay
> again. My development machine is not really usable right now.
>
>
> Looks here like recordings now extend until the start of the next
> recording on the same tuner. This is with master of Sunday on Fedora 31.
>
>  Klaas.

Both my boxes are on e3cafbc of Friday 5th and are as normal. F32 and el7.

John P

_______________________________________________
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 Mon, 2021-02-08 at 19:40 +0000, John Pilkington wrote:
> On 08/02/2021 19:21, Klaas de Waal wrote:
> >
> >
> > On Mon, 8 Feb 2021 at 19:27, John P Poet <jppoet@gmail.com 
> > <mailto:jppoet@gmail.com>> wrote:
> >
> >     On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal
> >     <klaas.de.waal@gmail.com <mailto:klaas.de.waal@gmail.com>>
> > wrote:
> >
> >         Hi,
> >
> >         Yesterday I updated my backend to the latest master and
> > since
> >         then some recordings are extended way beyond their
> > scheduled end
> >         time, one of them extended to 21 hours (115GB). Guide data
> > looks
> >         OK so I guess it is the recording. Could this be another
> >         "std:chrono" induced bug?
> >
> >
> >     I recently saw this behavior as well. In my case it seemed to
> > be
> >     doubling the length of the recording. Since this was my
> > production
> >     machine, I reverted to 8e14fe7ceba96f and everything seems okay
> >     again. My development machine is not really usable right now.
> >
> >
> > Looks here like recordings now extend until the start of the next
> > recording on the same tuner. This is with master of Sunday on
> > Fedora 31.
> >
> >   Klaas.
>
> Both my boxes are on e3cafbc of Friday 5th and are as normal.  F32
> and el7.

I must say I'm happy to hear that as it rules out the std::chrono
changes. If that turns out to be wrong and you do think its
std::chrono, let me know and I'll look into it. I have a couple of
overlapping series recordings (every weeknight) on my dev system that
haven't shown any problems with recording times. I record off a
HDHomerun box, but that shouldn't matter if the problem is in the
scheduler.

David


_______________________________________________
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 Mon, 2021-02-08 at 15:46 -0500, David Hampton wrote:
> On Mon, 2021-02-08 at 19:40 +0000, John Pilkington wrote:
> > On 08/02/2021 19:21, Klaas de Waal wrote:
> > >
> > >
> > > On Mon, 8 Feb 2021 at 19:27, John P Poet <jppoet@gmail.com 
> > > <mailto:jppoet@gmail.com>> wrote:
> > >
> > >     On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal
> > >     <klaas.de.waal@gmail.com <mailto:klaas.de.waal@gmail.com>>
> > > wrote:
> > >
> > >         Hi,
> > >
> > >         Yesterday I updated my backend to the latest master and
> > > since
> > >         then some recordings are extended way beyond their
> > > scheduled end
> > >         time, one of them extended to 21 hours (115GB). Guide
> > > data
> > > looks
> > >         OK so I guess it is the recording. Could this be another
> > >         "std:chrono" induced bug?
> > >
> > >
> > >     I recently saw this behavior as well. In my case it seemed to
> > > be
> > >     doubling the length of the recording. Since this was my
> > > production
> > >     machine, I reverted to 8e14fe7ceba96f and everything seems
> > > okay
> > >     again. My development machine is not really usable right now.
> > >
> > >
> > > Looks here like recordings now extend until the start of the next
> > > recording on the same tuner. This is with master of Sunday on
> > > Fedora 31.
> > >
> > >   Klaas.
> >
> > Both my boxes are on e3cafbc of Friday 5th and are as normal.  F32
> > and el7.
>
> I must say I'm happy to hear that as it rules out the std::chrono
> changes.  If that turns out to be wrong and you do think its
> std::chrono, let me know and I'll look into it.  I have a couple of
> overlapping series recordings (every weeknight) on my dev system that
> haven't shown any problems with recording times.  I record off a
> HDHomerun box, but that shouldn't matter if the problem is in the
> scheduler.

I should note that I've been running a copy of master slightly older
than last Friday. I've update to the latest and will see what happens
with tonight's recordings.

David


_______________________________________________
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 Mon, Feb 8, 2021 at 7:41 PM John Pilkington <johnpilk222@gmail.com> wrote:

>
> Both my boxes are on e3cafbc of Friday 5th and are as normal. F32 and el7.
>

Another anecdotal example:

Also on e3cafbc0b8, using a 3rd party external recorder,
and have not seen extended recordings. Doing a BE
--printsched also shows future recording time frames
as expected.
_______________________________________________
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 Mon, Feb 08, 2021 at 08:21:25PM +0100, Klaas de Waal wrote:
> On Mon, 8 Feb 2021 at 19:27, John P Poet <jppoet@gmail.com> wrote:
>
> > On Mon, Feb 8, 2021 at 11:09 AM Klaas de Waal <klaas.de.waal@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Yesterday I updated my backend to the latest master and since then some
> >> recordings are extended way beyond their scheduled end time, one of them
> >> extended to 21 hours (115GB). Guide data looks OK so I guess it is the
> >> recording. Could this be another "std:chrono" induced bug?
> >>
> >
> > I recently saw this behavior as well. In my case it seemed to be doubling
> > the length of the recording. Since this was my production machine, I
> > reverted to 8e14fe7ceba96f and everything seems okay again. My development
> > machine is not really usable right now.
> >
> >
> Looks here like recordings now extend until the start of the next
> recording on the same tuner. This is with master of Sunday on Fedora 31.

That's a neat feature I've been wanting to implement. Thanks, whoever
did it! :)

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

Quoting Gary Buhrmaster <gary.buhrmaster@gmail.com>:

> On Mon, Feb 8, 2021 at 7:41 PM John Pilkington <johnpilk222@gmail.com> wrote:
>
>>
>> Both my boxes are on e3cafbc of Friday 5th and are as normal. F32 and el7.
>>
>
> Another anecdotal example:
>
> Also on e3cafbc0b8, using a 3rd party external recorder,
> and have not seen extended recordings. Doing a BE
> --printsched also shows future recording time frames
> as expected.

I checked out e3cafbc0b828468a65bec8ba43fcc3e589b21648 yesterday
and it's not working here at all. Still have these long recordings
going on forever.

I'm using multiple DVB-T2 usb-tuners here.

Will try going backwards to 8e14fe7ceba96f just to see if it fixes
the current problem. Once I get this back to a working state, I can
possibly try bisecting the versions.

TomiO
_______________________________________________
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 10/02/2021 07:09, Tomi Orava wrote:
> Quoting Gary Buhrmaster <gary.buhrmaster@gmail.com>:
>
>> On Mon, Feb 8, 2021 at 7:41 PM John Pilkington <johnpilk222@gmail.com>
>> wrote:
>>
>>>
>>> Both my boxes are on e3cafbc of Friday 5th and are as normal.  F32
>>> and el7.
>>>
>>
>> Another anecdotal example:
>>
>> Also on e3cafbc0b8, using a 3rd party external recorder,
>> and have not seen extended recordings.  Doing a BE
>> --printsched also shows future recording time frames
>> as expected.
>
> I checked out e3cafbc0b828468a65bec8ba43fcc3e589b21648 yesterday
> and it's not working here at all. Still have these long recordings
> going on forever.
>
> I'm using multiple DVB-T2 usb-tuners here.
>
> Will try going backwards to 8e14fe7ceba96f just to see if it fixes
> the current problem. Once I get this back to a working state, I can
> possibly try bisecting the versions.
>
> TomiO

I have 542e7ce (8 Feb) under F32 and see no problem. But I have very
few permanent 'rules' and schedule most recordings as one-offs from the
EIT programme guide.

Similarly with e3cafbc under el7. I have the later version for that but
it wasn't convenient to install it yesterday.

John P
_______________________________________________
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 Wed, 10 Feb 2021 at 09:50, John Pilkington <johnpilk222@gmail.com> wrote:

> On 10/02/2021 07:09, Tomi Orava wrote:
> > Quoting Gary Buhrmaster <gary.buhrmaster@gmail.com>:
> >
> >> On Mon, Feb 8, 2021 at 7:41 PM John Pilkington <johnpilk222@gmail.com>
> >> wrote:
> >>
> >>>
> >>> Both my boxes are on e3cafbc of Friday 5th and are as normal. F32
> >>> and el7.
> >>>
> >>
> >> Another anecdotal example:
> >>
> >> Also on e3cafbc0b8, using a 3rd party external recorder,
> >> and have not seen extended recordings. Doing a BE
> >> --printsched also shows future recording time frames
> >> as expected.
> >
> > I checked out e3cafbc0b828468a65bec8ba43fcc3e589b21648 yesterday
> > and it's not working here at all. Still have these long recordings
> > going on forever.
> >
> > I'm using multiple DVB-T2 usb-tuners here.
> >
> > Will try going backwards to 8e14fe7ceba96f just to see if it fixes
> > the current problem. Once I get this back to a working state, I can
> > possibly try bisecting the versions.
> >
> > TomiO
>
> I have 542e7ce (8 Feb) under F32 and see no problem. But I have very
> few permanent 'rules' and schedule most recordings as one-offs from the
> EIT programme guide.
>
> Similarly with e3cafbc under el7. I have the later version for that but
> it wasn't convenient to install it yesterday.
>
>
> Some more data points:
- On the "Watch Recordings" screen the still-running recordings are shown
as white, i.e. not recording anymore. Only the continuously increasing file
size does show that the recording is still continuing.
- On the "Scheduled Recordings" screen the still-running recordings are
shown as green, indicating that they are being recorded.
- This all happens on my Fedora 31 backend, Qt version 5.13.2, with 3 DVB-C
tuners (/dev/dvb/adapter*/*) and one four-channel DVB-C HDHomeRun.
- This happens on both the DVB-C tuners and the HDHomeRun.

- My development system, Fedora 33, Qt version 5.15.2, with 1 DVB-C tuner,
does not have the problem.

Something that might help in testing this: when mythbackend is started with
"-v channel" there are lots of messages like this, repeated every 15
seconds:

2021-02-10 09:46:29.817 I DVBChan[1](/dev/dvb/adapter0/frontend0): Found
visible channel ID 10004 for '4'

The message shown here indicates a current recording on tuner with cardid
1, DVB device adapter0/frontend0, and channel id plus channel number 4.
There is one such line for each active recording.
Somewhere on the list is the plan to do something about the amount of these
messages but for now it is quite handy.

Klaas.

> Wiadomo?? napisana przez Klaas de Waal <klaas.de.waal@gmail.com> w dniu 08.02.2021, o godz. 19:08:
>
> Hi,
>
> Yesterday I updated my backend to the latest master and since then some recordings are extended way beyond their scheduled end time, one of them extended to 21 hours (115GB). Guide data looks OK so I guess it is the recording. Could this be another "std:chrono" induced bug?
>
> Klaas.
>

just want to say „me too”...

i updated be to current master and i have totally screwed real recordings durations.
EPG, OSD, etc shows as expected, but real recordings are much longer (i.e. rec. which should be recorded 8PM-9PM in reality was recording 8PM-11:30PM).
Something is definitely wrong here.... (provably by recent st:chrono changes?)

br
_______________________________________________
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 Wed, 2021-02-10 at 11:05 +0100, Piotr Oniszczuk wrote:
>
>
> > Wiadomo?? napisana przez Klaas de Waal <klaas.de.waal@gmail.com> w
> > dniu 08.02.2021, o godz. 19:08:
> >
> > Hi,
> >
> > Yesterday I updated my backend to the latest master and since then
> > some recordings are extended way beyond their scheduled end time,
> > one of them extended to 21 hours (115GB). Guide data looks OK so I
> > guess it is the recording. Could this be another "std:chrono"
> > induced bug?
> >
> > Klaas.
> >
>
> just want to say „me too”...
>
> i updated be to current master and i have totally screwed real
> recordings durations.
> EPG, OSD, etc shows as expected, but real recordings are much longer
> (i.e. rec. which should be recorded 8PM-9PM in reality was recording
> 8PM-11:30PM).
> Something is definitely wrong here.... (provably by recent st:chrono
> changes?)

I agree there is a problem, but I can't replicate it here. I have a
bunch of recording scheduled on my dev system to see if I can find one
that records up until the subsequent scheduled recording.

Summarizing to see if there is a pattern. So far we have reports of:

No problem:

DavidH: HDHomeRun (ATSC, CC), Fedora 33, Qt 5.15.2
Klaas (dev) has DVB-C tuner, Fedora 33, Qt 5.15.2
John P: unknown tuners, Fedora 32, unknown Qt
GaryB: external recorded, unknown OS, unknown Qt

Problems:

Klaas (prod): DVB-C and DVB-C HDHomeRun, Fedora 31 Qt 5.13.2
TomiO: DVB-T2 tuners, unknown OS, unknown Qt
jppoet: unknown
Scott Simpson: HDHomeRun Prime, Unknown OS, Unknown Qt

So far nothing jumps out as being common.

Piotr's bad recording didn't cross midnight local time, and I'm
guessing that it didn't cross midnight UTC.

Has anyone else see a pattern where some recording are correct and some
overlong, or are the overlong recording on the system overlong?

David


_______________________________________________
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 Wed, Feb 10, 2021 at 11:31 AM David Hampton via mythtv-dev <
mythtv-dev@mythtv.org> wrote:

> On Wed, 2021-02-10 at 11:05 +0100, Piotr Oniszczuk wrote:
> >
> >
> > > Wiadomo?? napisana przez Klaas de Waal <klaas.de.waal@gmail.com> w
> > > dniu 08.02.2021, o godz. 19:08:
> > >
> > > Hi,
> > >
> > > Yesterday I updated my backend to the latest master and since then
> > > some recordings are extended way beyond their scheduled end time,
> > > one of them extended to 21 hours (115GB). Guide data looks OK so I
> > > guess it is the recording. Could this be another "std:chrono"
> > > induced bug?
> > >
> > > Klaas.
> > >
> >
> > just want to say „me too”...
> >
> > i updated be to current master and i have totally screwed real
> > recordings durations.
> > EPG, OSD, etc shows as expected, but real recordings are much longer
> > (i.e. rec. which should be recorded 8PM-9PM in reality was recording
> > 8PM-11:30PM).
> > Something is definitely wrong here.... (provably by recent st:chrono
> > changes?)
>
> I agree there is a problem, but I can't replicate it here. I have a
> bunch of recording scheduled on my dev system to see if I can find one
> that records up until the subsequent scheduled recording.
>
> Summarizing to see if there is a pattern. So far we have reports of:
>
> No problem:
>
> DavidH: HDHomeRun (ATSC, CC), Fedora 33, Qt 5.15.2
> Klaas (dev) has DVB-C tuner, Fedora 33, Qt 5.15.2
> John P: unknown tuners, Fedora 32, unknown Qt
> GaryB: external recorded, unknown OS, unknown Qt
>
> Problems:
>
> Klaas (prod): DVB-C and DVB-C HDHomeRun, Fedora 31 Qt 5.13.2
> TomiO: DVB-T2 tuners, unknown OS, unknown Qt
> jppoet: unknown
> Scott Simpson: HDHomeRun Prime, Unknown OS, Unknown Qt
>
> So far nothing jumps out as being common.
>
> Piotr's bad recording didn't cross midnight local time, and I'm
> guessing that it didn't cross midnight UTC.
>
> Has anyone else see a pattern where some recording are correct and some
> overlong, or are the overlong recording on the system overlong?
>
> David
>

Fedora 32
Kernel: 5.9.16
GCC: 10.2.1
Tuners: Hauppauge quadHD (DVB driver) ATSC and mythexternrecorder
(ExternRecorder)

I only had it installed for less than a day. Klass' observation that it
recorded until the next episode on the same input could be correct - In my
case it seems to record double length, but I didn't analyze in any kind of
detail. Once I have my dev machine working again I will see what I can
figure out there.

John

On Wed, Feb 10, 2021 at 12:10:40PM -0700, John P Poet wrote:
> I only had it installed for less than a day. Klass' observation that it
> recorded until the next episode on the same input could be correct - In my
> case it seems to record double length, but I didn't analyze in any kind of
> detail. Once I have my dev machine working again I will see what I can
> figure out there.

The part about running until the next recording on the tuner points to
problem in the recorder. The reason is scheduler doesn't normally
tell recorders to stop. They are expected to stop on their own at the
prescribed time or when told to start recording something else.

Are any of the problem systems running 32-bit code? I didn't see that
break out in the good/bad list.

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

On Wed, 2021-02-10 at 13:28 -0600, David Engel wrote:
> On Wed, Feb 10, 2021 at 12:10:40PM -0700, John P Poet wrote:
> > I only had it installed for less than a day. Klass' observation
> > that it
> > recorded until the next episode on the same input could be correct
> > - In my
> > case it seems to record double length, but I didn't analyze in any
> > kind of
> > detail. Once I have my dev machine working again I will see what I
> > can
> > figure out there.
>
> The part about running until the next recording on the tuner points
> to problem in the recorder.  The reason is scheduler doesn't normally
> tell recorders to stop.  They are expected to stop on their own at
> the prescribed time or when told to start recording something else.

I just received a 'mythbackend --printsched' from someone on the user's
group, and the times on all the recording entries looks correct. He
says his one hour (plus a bit) recording always record for six hours.
There's nothing in his printsched that is always recorded six hours
later. In fact, of his three simultaneous late night recordings that go
long, tuners 2 and 3 often aren't used until late the next night.

> Are any of the problem systems running 32-bit code?  I didn't see
> that break out in the good/bad list.

Good question. Fedora dropped support for 32 bit systems after Fedora
30 and both of Klaas's systems are later versions, so that's probably
not the cause.

David


_______________________________________________
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 Wed, Feb 10, 2021 at 6:31 PM David Hampton via mythtv-dev
<mythtv-dev@mythtv.org> wrote:

> Summarizing to see if there is a pattern. So far we have reports of:
>
> No problem:
....
> GaryB: external recorded, unknown OS, unknown Qt

To add to the info:

No problems seen at:

OS: Fedora 33
Qt: 5.15.2 (compile and runtime)
Kernel: 5.10.13
gcc: 10.2.1
Tuners: (3rd party) external recorder (mythhdhrrecorder) with HDHR Prime
MythTV master tested at both e3cafbc0b8 and 9a790b3e91
_______________________________________________
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

My system is 64 bit:

mythtv@mythtv:~$ uname -a
Linux mythtv 5.4.0-65-generic #73-Ubuntu SMP Mon Jan 18 17:25:17 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux

My HDHomeRun Prime firmware hasn't been updated since last September:

HDHomeRun PRIME
Model: HDHR3-CC
Device ID: 1316B200
Firmware: 20200907
Channel Lineup
CableCARD Menu
Tuning Resolver Menu
Tuner Status
System Status
Installation Instructions
Status
Card Authentication success
Card OOB Lock weak
Card Validation none

(By going to the IP of the HDHomeRun Prime in a browser). I'll try rebooting
it and see if that helps but I doubt it since everyone else is having this
problem at the same time. That would rule out all the devices failing at
once.

-----Original Message-----
From: mythtv-dev <mythtv-dev-bounces@mythtv.org> On Behalf Of David Engel
Sent: Wednesday, February 10, 2021 11:29 AM
To: Development of MythTV <mythtv-dev@mythtv.org>
Subject: Re: [mythtv] Very long recordings

On Wed, Feb 10, 2021 at 12:10:40PM -0700, John P Poet wrote:
> I only had it installed for less than a day. Klass' observation that
> it recorded until the next episode on the same input could be correct
> - In my case it seems to record double length, but I didn't analyze in
> any kind of detail. Once I have my dev machine working again I will
> see what I can figure out there.

The part about running until the next recording on the tuner points to
problem in the recorder. The reason is scheduler doesn't normally tell
recorders to stop. They are expected to stop on their own at the prescribed
time or when told to start recording something else.

Are any of the problem systems running 32-bit code? I didn't see that break
out in the good/bad list.

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

_______________________________________________
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

My MythTV packages are 64 bit also:

mythtv@mythtv:~$ dpkg-query --list |grep mythtv
ii libmythtv-perl
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Perl
library to access some MythTV features
ii mythtv-backend
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (server)
ii mythtv-common
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (common data)
ii mythtv-database
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
video recorder application (database)
ii mythtv-dbg
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Debug
symbols for mythtv packages
ii mythtv-doc
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
video recorder application (documentation)
ii mythtv-frontend
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (client)
ii mythtv-theme-mythbuntu
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all MythTV
Theme used in the Mythbuntu distribution
ii mythtv-transcode-utils
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Utilities
used for transcoding MythTV tasks
ii php-mythtv
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all PHP
Bindings for MythTV
m

-----Original Message-----
From: mythtv-dev <mythtv-dev-bounces@mythtv.org> On Behalf Of Gary
Buhrmaster
Sent: Wednesday, February 10, 2021 12:12 PM
To: Development of MythTV <mythtv-dev@mythtv.org>
Subject: Re: [mythtv] Very long recordings

On Wed, Feb 10, 2021 at 6:31 PM David Hampton via mythtv-dev
<mythtv-dev@mythtv.org> wrote:

> Summarizing to see if there is a pattern. So far we have reports of:
>
> No problem:
....
> GaryB: external recorded, unknown OS, unknown Qt

To add to the info:

No problems seen at:

OS: Fedora 33
Qt: 5.15.2 (compile and runtime)
Kernel: 5.10.13
gcc: 10.2.1
Tuners: (3rd party) external recorder (mythhdhrrecorder) with HDHR Prime
MythTV master tested at both e3cafbc0b8 and 9a790b3e91
_______________________________________________
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

_______________________________________________
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

I have just now found a bit of suspicious code in tv_rec.cpp.
This is the current code is this in tv_rec.cpp:159

m_overRecordSecNrml =
gCoreContext->GetDurSetting<std::chrono::minutes>("RecordOverTime");

My production system has a value in the database of 1200 seconds.
As I understand the code, the seconds value in the database is interpreted
as minutes, which results in 72000 seconds record overtime.
My development system has record overtime 0 so there it does not make
a difference.

This is in commit c2730942e325b393e589bb0b369c8e08bab3ea3c

Have not tested this yet but hope this helps.

Klaas.






On Wed, 10 Feb 2021 at 22:08, Scott Simpson <simpson100@gmail.com> wrote:

> My MythTV packages are 64 bit also:
>
> mythtv@mythtv:~$ dpkg-query --list |grep mythtv
> ii libmythtv-perl
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Perl
> library to access some MythTV features
> ii mythtv-backend
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
> video recorder application (server)
> ii mythtv-common
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
> video recorder application (common data)
> ii mythtv-database
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
> video recorder application (database)
> ii mythtv-dbg
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Debug
> symbols for mythtv packages
> ii mythtv-doc
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
> video recorder application (documentation)
> ii mythtv-frontend
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
> video recorder application (client)
> ii mythtv-theme-mythbuntu
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all MythTV
> Theme used in the Mythbuntu distribution
> ii mythtv-transcode-utils
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Utilities
> used for transcoding MythTV tasks
> ii php-mythtv
> 2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all PHP
> Bindings for MythTV
> m
>
> -----Original Message-----
> From: mythtv-dev <mythtv-dev-bounces@mythtv.org> On Behalf Of Gary
> Buhrmaster
> Sent: Wednesday, February 10, 2021 12:12 PM
> To: Development of MythTV <mythtv-dev@mythtv.org>
> Subject: Re: [mythtv] Very long recordings
>
> On Wed, Feb 10, 2021 at 6:31 PM David Hampton via mythtv-dev
> <mythtv-dev@mythtv.org> wrote:
>
> > Summarizing to see if there is a pattern. So far we have reports of:
> >
> > No problem:
> ....
> > GaryB: external recorded, unknown OS, unknown Qt
>
> To add to the info:
>
> No problems seen at:
>
> OS: Fedora 33
> Qt: 5.15.2 (compile and runtime)
> Kernel: 5.10.13
> gcc: 10.2.1
> Tuners: (3rd party) external recorder (mythhdhrrecorder) with HDHR Prime
> MythTV master tested at both e3cafbc0b8 and 9a790b3e91
> _______________________________________________
> 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
>
> _______________________________________________
> 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 Wed, 2021-02-10 at 22:31 +0100, Klaas de Waal wrote:
> I have just now found a bit of suspicious code in tv_rec.cpp.
> This is the current code is this in tv_rec.cpp:159
>
>     m_overRecordSecNrml = gCoreContext-
> >GetDurSetting<std::chrono::minutes>("RecordOverTime");
>
> My production system has a value in the database of 1200 seconds.
> As I understand the code, the seconds value in the database is
> interpreted as minutes, which results in 72000 seconds record
> overtime.
> My development system has record overtime 0 so there it does not make
> a difference.
>
> This is in commit c2730942e325b393e589bb0b369c8e08bab3ea3c
>
> Have not tested this yet but hope this helps.

That's definitely wrong. Thanks for finding it.

I'll commit a fix ASAP.

David


_______________________________________________
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

Great catch! That explains why I have a problem and others don’t. My RecordOverTime is 5 minutes:




+----------------+------+----------+

| value | data | hostname |

+----------------+------+----------+

| RecordOverTime | 300 | NULL |

+----------------+------+----------+

1 row in set (0.00 sec)



If interpreted as minutes it is 300/60 = 5 hours. That explains why my recordings last 6 hours.



From: mythtv-dev <mythtv-dev-bounces@mythtv.org> On Behalf Of Klaas de Waal
Sent: Wednesday, February 10, 2021 1:31 PM
To: Development of MythTV <mythtv-dev@mythtv.org>
Subject: Re: [mythtv] Very long recordings



I have just now found a bit of suspicious code in tv_rec.cpp.

This is the current code is this in tv_rec.cpp:159



m_overRecordSecNrml = gCoreContext->GetDurSetting<std::chrono::minutes>("RecordOverTime");



My production system has a value in the database of 1200 seconds.

As I understand the code, the seconds value in the database is interpreted as minutes, which results in 72000 seconds record overtime.

My development system has record overtime 0 so there it does not make a difference.



This is in commit c2730942e325b393e589bb0b369c8e08bab3ea3c



Have not tested this yet but hope this helps.



Klaas.













On Wed, 10 Feb 2021 at 22:08, Scott Simpson <simpson100@gmail.com <mailto:simpson100@gmail.com> > wrote:

My MythTV packages are 64 bit also:

mythtv@mythtv:~$ dpkg-query --list |grep mythtv
ii libmythtv-perl
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Perl
library to access some MythTV features
ii mythtv-backend
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (server)
ii mythtv-common
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (common data)
ii mythtv-database
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
video recorder application (database)
ii mythtv-dbg
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Debug
symbols for mythtv packages
ii mythtv-doc
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all Personal
video recorder application (documentation)
ii mythtv-frontend
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Personal
video recorder application (client)
ii mythtv-theme-mythbuntu
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all MythTV
Theme used in the Mythbuntu distribution
ii mythtv-transcode-utils
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 amd64 Utilities
used for transcoding MythTV tasks
ii php-mythtv
2:32.0~master.202102091135.9a790b3e91~ubuntu20.04.1 all PHP
Bindings for MythTV
m

-----Original Message-----
From: mythtv-dev <mythtv-dev-bounces@mythtv.org <mailto:mythtv-dev-bounces@mythtv.org> > On Behalf Of Gary
Buhrmaster
Sent: Wednesday, February 10, 2021 12:12 PM
To: Development of MythTV <mythtv-dev@mythtv.org <mailto:mythtv-dev@mythtv.org> >
Subject: Re: [mythtv] Very long recordings

On Wed, Feb 10, 2021 at 6:31 PM David Hampton via mythtv-dev
<mythtv-dev@mythtv.org <mailto:mythtv-dev@mythtv.org> > wrote:

> Summarizing to see if there is a pattern. So far we have reports of:
>
> No problem:
....
> GaryB: external recorded, unknown OS, unknown Qt

To add to the info:

No problems seen at:

OS: Fedora 33
Qt: 5.15.2 (compile and runtime)
Kernel: 5.10.13
gcc: 10.2.1
Tuners: (3rd party) external recorder (mythhdhrrecorder) with HDHR Prime
MythTV master tested at both e3cafbc0b8 and 9a790b3e91
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org <mailto: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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org <mailto: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 Wed, 2021-02-10 at 16:45 -0500, David Hampton via mythtv-dev wrote:
> On Wed, 2021-02-10 at 22:31 +0100, Klaas de Waal wrote:
> > I have just now found a bit of suspicious code in tv_rec.cpp.
> > This is the current code is this in tv_rec.cpp:159
> >
> >     m_overRecordSecNrml = gCoreContext-
> > > GetDurSetting<std::chrono::minutes>("RecordOverTime");
> >
> > My production system has a value in the database of 1200 seconds.
> > As I understand the code, the seconds value in the database is
> > interpreted as minutes, which results in 72000 seconds record
> > overtime.
> > My development system has record overtime 0 so there it does not
> > make
> > a difference.
> >
> > This is in commit c2730942e325b393e589bb0b369c8e08bab3ea3c
> >
> > Have not tested this yet but hope this helps.
>
> That's definitely wrong.  Thanks for finding it.

Is the line after it wrong too?

m_overRecordSecCat = gCoreContext->GetDurSetting<std::chrono::minutes>("CategoryOverTime");

Ian.

_______________________________________________
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 Thu, 11 Feb 2021 at 11:31, Ian Campbell <ijc@hellion.org.uk> wrote:

> On Wed, 2021-02-10 at 16:45 -0500, David Hampton via mythtv-dev wrote:
> > On Wed, 2021-02-10 at 22:31 +0100, Klaas de Waal wrote:
> > > I have just now found a bit of suspicious code in tv_rec.cpp.
> > > This is the current code is this in tv_rec.cpp:159
> > >
> > > m_overRecordSecNrml = gCoreContext-
> > > > GetDurSetting<std::chrono::minutes>("RecordOverTime");
> > >
> > > My production system has a value in the database of 1200 seconds.
> > > As I understand the code, the seconds value in the database is
> > > interpreted as minutes, which results in 72000 seconds record
> > > overtime.
> > > My development system has record overtime 0 so there it does not
> > > make
> > > a difference.
> > >
> > > This is in commit c2730942e325b393e589bb0b369c8e08bab3ea3c
> > >
> > > Have not tested this yet but hope this helps.
> >
> > That's definitely wrong. Thanks for finding it.
>
> Is the line after it wrong too?
>
> m_overRecordSecCat =
> gCoreContext->GetDurSetting<std::chrono::minutes>("CategoryOverTime");
>
>
> That is the extra recording time that you can define for one category
only, e.g. "Movies" or so, and that one is actually defined in minutes.....
so that is OK.

Klaas.

On Thu, 2021-02-11 at 12:23 +0100, Klaas de Waal wrote:
> > Is the line after it wrong too?
> >
> >  m_overRecordSecCat  = gCoreContext-
> > > GetDurSetting<std::chrono::minutes>("CategoryOverTime");
> >
> >
> >
>
> That is the extra recording time that you can define for one category
> only, e.g. "Movies" or so, and that one is actually defined in
> minutes..... so that is OK.

Ah yes, I see how it works now, thanks!


_______________________________________________
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

> Wiadomo?? napisana przez David Hampton via mythtv-dev <mythtv-dev@mythtv.org> w dniu 10.02.2021, o godz. 22:45:
>
> That's definitely wrong. Thanks for finding it.
>
> I'll commit a fix ASAP.
>
> David

David,

Many thx!
Current master works perfectly now :-)

_______________________________________________
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