Mailing List Archive

1 2 3  View All
Re: Events at the beginning of a recording [ In reply to ]
On 05/02/2023 16:38, Klaas de Waal wrote:
> Have you set the value for WakeUpThreshold in the database or are you
> referring to the default value you find in the code that is used when
> there is no setting in the database?

I extracted them from the running backend using the service API (as
described in the forum thread you pointed to earlier).

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
Hi Jan,

Looking at this log, I suspect that you have numeric value 5 for
WakeUpThreshold in the database.
Can you check the values for both WakeUpThreshold and RecordPreRoll in the
database, e.g.
select * from settings where value like "Wake%";
and
select * from settings where value like "Rec%";

Thanks,
Klaas.


On Sun, 5 Feb 2023 at 16:40, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 05/02/2023 16:10, Jan Ceuleers wrote:
> > Anyway, I will do another test run after running mythbackend
> > --setverbose network .
>
> Would you believe it: this test ran correctly.
>
>
> Feb 5 16:30:45 mythtv[2127696]:
> /home/mythtv/system-events/recording-pending called with parameters 32
> 20230205163500 4 by PID 2127696
> Feb 5 16:35:00 mythtv[2135457]:
> /home/mythtv/system-events/recording-started called with parameters 32
> 20230205163500 by PID 2135457
>
> Here is the corresponding mythbackend log:
>
> root@dracor:~# tail -f /var/log/mythtv/mythbackend.log | grep -e
> REC_PENDING -e REC_STARTED
> Feb 5 16:30:45 dracor mythbackend: mythbackend[1125035]: I Scheduler
> mythcorecontext.cpp:1725 (dispatch) MythCoreContext::dispatch():
> MythEvent: SYSTEM_EVENT REC_PENDING SECS 4 CARDID 32 CHANID 2010
> STARTTIME 2023-02-05T15:35:00Z RECSTATUS -1 VIDEODEVICE
> /usr/bin/mythexternrecorder --conf /home/mythtv/mythexternrecorder1.conf
> VBIDEVICE SENDER dracor
> Feb 5 16:30:45 dracor mythbackend: mythbackend[1125035]: I
> MythSocketThread(72) mythsocket.cpp:744 (WriteStringListReal)
> MythSocket(557bd8fa0b30:72): write -> 72 237
> BACKEND_MESSAGE[]:[]SYSTEM_EVENT REC_PENDING SECS 4 CARDID 32 CHANID
> 2010 STARTTIME 2023-02-05T15:35:00Z RE…
> Feb 5 16:30:45 dracor mythbackend: mythbackend[1125035]: I SystemEvent
> mythcorecontext.cpp:1725 (dispatch) MythCoreContext::dispatch():
> MythEvent: SYSTEM_EVENT_RESULT REC_PENDING SENDER dracor RESULT 0
> Feb 5 16:30:45 dracor mythbackend: mythbackend[1125035]: I
> MythSocketThread(72) mythsocket.cpp:744 (WriteStringListReal)
> MythSocket(557bd8fa0b30:72): write -> 72 84
> BACKEND_MESSAGE[]:[]SYSTEM_EVENT_RESULT REC_PENDING SENDER dracor RESULT
> 0[]:[]empty
> Feb 5 16:35:00 dracor mythbackend: mythbackend[1125035]: I Scheduler
> mythcorecontext.cpp:1725 (dispatch) MythCoreContext::dispatch():
> MythEvent: SYSTEM_EVENT REC_STARTED CARDID 32 CHANID 2010 STARTTIME
> 2023-02-05T15:35:00Z RECSTATUS -15 VIDEODEVICE
> /usr/bin/mythexternrecorder --conf /home/mythtv/mythexternrecorder1.conf
> VBIDEVICE SENDER dracor
> Feb 5 16:35:00 dracor mythbackend: mythbackend[1125035]: I
> MythSocketThread(72) mythsocket.cpp:744 (WriteStringListReal)
> MythSocket(557bd8fa0b30:72): write -> 72 231
> BACKEND_MESSAGE[]:[]SYSTEM_EVENT REC_STARTED CARDID 32 CHANID 2010
> STARTTIME 2023-02-05T15:35:00Z RECSTATUS…
> Feb 5 16:35:00 dracor mythbackend: mythbackend[1125035]: I SystemEvent
> mythcorecontext.cpp:1725 (dispatch) MythCoreContext::dispatch():
> MythEvent: SYSTEM_EVENT_RESULT REC_STARTED SENDER dracor RESULT 0
> Feb 5 16:35:00 dracor mythbackend: mythbackend[1125035]: I
> MythSocketThread(72) mythsocket.cpp:744 (WriteStringListReal)
> MythSocket(557bd8fa0b30:72): write -> 72 84
> BACKEND_MESSAGE[]:[]SYSTEM_EVENT_RESULT REC_STARTED SENDER dracor RESULT
> 0[]:[]empty
> Feb 5 16:35:25 dracor mythbackend: mythbackend[1125035]: I ExternSH
> mythcorecontext.cpp:1725 (dispatch) MythCoreContext::dispatch():
> MythEvent: SYSTEM_EVENT REC_STARTED_WRITING CARDID 32 CHANID 2010
> STARTTIME 2023-02-05T15:35:00Z RECSTATUS -2 VIDEODEVICE
> /usr/bin/mythexternrecorder --conf /home/mythtv/mythexternrecorder1.conf
> VBIDEVICE SENDER dracor
> Feb 5 16:35:25 dracor mythbackend: mythbackend[1125035]: I
> MythSocketThread(72) mythsocket.cpp:744 (WriteStringListReal)
> MythSocket(557bd8fa0b30:72): write -> 72 238
> BACKEND_MESSAGE[]:[]SYSTEM_EVENT REC_STARTED_WRITING CARDID 32 CHANID
> 2010 STARTTIME 2023-02-05T15:35:00Z R…
>
> I'll see if the problem reproduces.
>
> Cheers, Jan
> _______________________________________________
> 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: Events at the beginning of a recording [ In reply to ]
On 05/02/2023 17:01, Klaas de Waal wrote:
> Looking at this log, I suspect that you have numeric value 5 for
> WakeUpThreshold in the database.
> Can you check the values for both WakeUpThreshold and RecordPreRoll in
> the database, e.g. 
> select * from settings where value like "Wake%";
> and
> select * from settings where value like "Rec%";

mysql> select * from settings where value like "Wake%";
+------------------+------------------+----------+
| value | data | hostname |
+------------------+------------------+----------+
| WakeUpThreshold | 5 | NULL |
| WakeupTimeFormat | hh:mm yyyy-MM-dd | NULL |
+------------------+------------------+----------+
2 rows in set (0.00 sec)

mysql> select * from settings where value like "Rec%";
+--------------------+----------------------------------------+----------+
| value | data | hostname |
+--------------------+----------------------------------------+----------+
| RecGroupsFocusable | 0 | bajor |
| RecGroupsFocusable | 0 | dracor |
| RecGroupsFocusable | 0 | fe4 |
| RecGroupsFocusable | 0 | hobbiton |
| RecGroupsFocusable | 0 | mordor |
| recommend_enabled | | NULL |
| recommend_key | REQUIRED | NULL |
| recommend_server | http://myth-recommendations.aws.af.cm/ | NULL |
| RecordFilePrefix | /mnt/disk1/mythtv | dracor |
| RecordOverTime | 1200 | NULL |
| RecordPreRoll | 250 | NULL |
+--------------------+----------------------------------------+----------+
11 rows in set (0.00 sec)


_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
Hi Jan,

Yes, I can reproduce the problem.

When a recording is scheduled *after* the start time of the program,
including the preroll time, then the recording starts immediately.
This is when you get a REC_PENDING with a negative SECS value and also the
REC_PENDING comes after the REC_START.
The correct behaviour here is that the REC_PENDING comes with a SECS value
of 0 (or small positive) followed by the REC_START.
This will be fixed.

About why you see a REC_PENDING with a value of 5 seconds.
The REC_PENDING logic is only activated after the WakeUpThreshold is passed
so if your WakeUpThreshold is 5 seconds then the earliest REC_PENDING that
you can get is 5 seconds before the recording starts.
I think there is some confusion about minutes vs. seconds. The default
value for WakeUpThreshold, when not defined in the database, is 5 minutes.
My understanding is that the value in the database is in seconds.
I recommend removing the value from the database or setting it to 300
seconds.

Hope this helps and thanks for all the testing and reporting!
Klaas.





On Sun, 5 Feb 2023 at 17:24, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 05/02/2023 17:01, Klaas de Waal wrote:
> > Looking at this log, I suspect that you have numeric value 5 for
> > WakeUpThreshold in the database.
> > Can you check the values for both WakeUpThreshold and RecordPreRoll in
> > the database, e.g.
> > select * from settings where value like "Wake%";
> > and
> > select * from settings where value like "Rec%";
>
> mysql> select * from settings where value like "Wake%";
> +------------------+------------------+----------+
> | value | data | hostname |
> +------------------+------------------+----------+
> | WakeUpThreshold | 5 | NULL |
> | WakeupTimeFormat | hh:mm yyyy-MM-dd | NULL |
> +------------------+------------------+----------+
> 2 rows in set (0.00 sec)
>
> mysql> select * from settings where value like "Rec%";
> +--------------------+----------------------------------------+----------+
> | value | data | hostname |
> +--------------------+----------------------------------------+----------+
> | RecGroupsFocusable | 0 | bajor |
> | RecGroupsFocusable | 0 | dracor |
> | RecGroupsFocusable | 0 | fe4 |
> | RecGroupsFocusable | 0 | hobbiton |
> | RecGroupsFocusable | 0 | mordor |
> | recommend_enabled | | NULL |
> | recommend_key | REQUIRED | NULL |
> | recommend_server | http://myth-recommendations.aws.af.cm/ | NULL |
> | RecordFilePrefix | /mnt/disk1/mythtv | dracor |
> | RecordOverTime | 1200 | NULL |
> | RecordPreRoll | 250 | NULL |
> +--------------------+----------------------------------------+----------+
> 11 rows in set (0.00 sec)
>
>
> _______________________________________________
> 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: Events at the beginning of a recording [ In reply to ]
On 05/02/2023 18:27, Klaas de Waal wrote:
> Hi Jan,
>
> Yes, I can reproduce the problem.
>
> When a recording is scheduled *after* the start time of the program,
> including the preroll time, then the recording starts immediately.
> This is when you get a REC_PENDING with a negative SECS value and also
> the REC_PENDING comes after the REC_START.
> The correct behaviour here is that the REC_PENDING comes with a SECS
> value of 0 (or small positive) followed by the REC_START.
> This will be fixed.
>
> About why you see a REC_PENDING with a value of 5 seconds.
> The REC_PENDING logic is only activated after the WakeUpThreshold is
> passed so if your WakeUpThreshold is 5 seconds then the earliest
> REC_PENDING that you can get is 5 seconds before the recording starts.
> I think there is some confusion about minutes vs. seconds. The default
> value for WakeUpThreshold, when not defined in the database, is 5 minutes.
> My understanding is that the value in the database is in seconds.
> I recommend removing the value from the database or setting it to 300
> seconds.

I did as you suggested (set WakeUpThreshold to 300), and after
restarting the backend to make sure that it has seen the updated
parameter the result is as follows:

Feb 5 20:24:50 mythtv[2529215]:
/home/mythtv/system-events/recording-pending called with parameters 10
20230205203000 60 by PID 2529215
Feb 5 20:25:20 mythtv[2530041]:
/home/mythtv/system-events/recording-pending called with parameters 10
20230205203000 29 by PID 2530041
Feb 5 20:25:50 mythtv[2530903]:
/home/mythtv/system-events/recording-started called with parameters 10
20230205202600 by PID 2530903
Feb 5 20:25:50 mythtv[2530907]:
/home/mythtv/system-events/recording-pending called with parameters 10
20230205202600 -241 by PID 2530907

So I am indeed getting recording pending events before the recording
starts. It would be good if they came earlier still (my STB needs around
90s from power-on to start accepting infrared commands so that I can
change channels), but we're getting closer.

I can of course live with the recording pending event that still fires
after the recording has started, with a nonsensical negative value.

> Hope this helps and thanks for all the testing and reporting!

Yes, thank you very much for your help.

Cheers, Jan
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On 05/02/2023 19:30, Jan Ceuleers wrote:

> On 05/02/2023 18:27, Klaas de Waal wrote:
>> Hi Jan,
>>
>> Yes, I can reproduce the problem.
>>
>> When a recording is scheduled *after* the start time of the program,
>> including the preroll time, then the recording starts immediately.
>> This is when you get a REC_PENDING with a negative SECS value and also
>> the REC_PENDING comes after the REC_START.
>> The correct behaviour here is that the REC_PENDING comes with a SECS
>> value of 0 (or small positive) followed by the REC_START.
>> This will be fixed.
>>
>> About why you see a REC_PENDING with a value of 5 seconds.
>> The REC_PENDING logic is only activated after the WakeUpThreshold is
>> passed so if your WakeUpThreshold is 5 seconds then the earliest
>> REC_PENDING that you can get is 5 seconds before the recording starts.
>> I think there is some confusion about minutes vs. seconds. The default
>> value for WakeUpThreshold, when not defined in the database, is 5 minutes.
>> My understanding is that the value in the database is in seconds.
>> I recommend removing the value from the database or setting it to 300
>> seconds.
> I did as you suggested (set WakeUpThreshold to 300), and after
> restarting the backend to make sure that it has seen the updated
> parameter the result is as follows:
>
> Feb 5 20:24:50 mythtv[2529215]:
> /home/mythtv/system-events/recording-pending called with parameters 10
> 20230205203000 60 by PID 2529215
> Feb 5 20:25:20 mythtv[2530041]:
> /home/mythtv/system-events/recording-pending called with parameters 10
> 20230205203000 29 by PID 2530041
> Feb 5 20:25:50 mythtv[2530903]:
> /home/mythtv/system-events/recording-started called with parameters 10
> 20230205202600 by PID 2530903
> Feb 5 20:25:50 mythtv[2530907]:
> /home/mythtv/system-events/recording-pending called with parameters 10
> 20230205202600 -241 by PID 2530907
>
> So I am indeed getting recording pending events before the recording
> starts. It would be good if they came earlier still (my STB needs around
> 90s from power-on to start accepting infrared commands so that I can
> change channels), but we're getting closer.
>
> I can of course live with the recording pending event that still fires
> after the recording has started, with a nonsensical negative value.
>
>> Hope this helps and thanks for all the testing and reporting!
> Yes, thank you very much for your help.
>
> Cheers, Jan


I think ideally you have to have WakeUpThreshold >= global pre-roll +
120. So with your 250 seconds pre-roll I would try something like 370 or
400 for WakeUpThreshold. That should give you about 120 seconds between
events if I understand the problem properly.


Paul H.

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Sun, 5 Feb 2023 at 21:11, Paul Harrison <mythtv@mythqml.net> wrote:

>
> I think ideally you have to have WakeUpThreshold >= global pre-roll +
> 120. So with your 250 seconds pre-roll I would try something like 370 or
> 400 for WakeUpThreshold. That should give you about 120 seconds between
> events if I understand the problem properly.
>
> Yes, I share your understanding of the logic but the HandleWakeSlave is
not called early enough.
My logs show most of the time only two REC_PENDING events, one on 60
seconds and one on 30 seconds.
I think I found where this comes from but I as this is the scheduler I need
to be very careful....

Groetjes,
Klaas.
Re: Events at the beginning of a recording [ In reply to ]
On 05/02/2023 23:13, Klaas de Waal wrote:
> I think ideally you have to have WakeUpThreshold >= global pre-roll +
> 120. So with your 250 seconds pre-roll I would try something like
> 370 or
> 400 for WakeUpThreshold. That should give you about 120 seconds between
> events if I understand the problem properly.
>
> Yes, I share your understanding of the logic but the HandleWakeSlave is
> not called early enough.
> My logs show most of the time only two REC_PENDING events, one on 60
> seconds and one on 30 seconds.
> I think I found where this comes from but I as this is the scheduler I
> need to be very careful....

I have changed the WakeUpThreshold to 600 (just to be on the safe side),
and I still only get two REC_PENDING events (at 60 and 29 seconds), same
as Klaas reports.

Cheers, Jan
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On 06/02/2023 11:17, Jan Ceuleers wrote:

> On 05/02/2023 23:13, Klaas de Waal wrote:
>> I think ideally you have to have WakeUpThreshold >= global pre-roll +
>> 120. So with your 250 seconds pre-roll I would try something like
>> 370 or
>> 400 for WakeUpThreshold. That should give you about 120 seconds between
>> events if I understand the problem properly.
>>
>> Yes, I share your understanding of the logic but the HandleWakeSlave is
>> not called early enough.
>> My logs show most of the time only two REC_PENDING events, one on 60
>> seconds and one on 30 seconds.
>> I think I found where this comes from but I as this is the scheduler I
>> need to be very careful....
> I have changed the WakeUpThreshold to 600 (just to be on the safe side),
> and I still only get two REC_PENDING events (at 60 and 29 seconds), same
> as Klaas reports.
>
> Cheers, Jan


OK thanks for testing.


The problem must be further up the code in the main scheduler loop which
is not calling HandleWakeSlave early or often enough for the code that
sends the REC_PENDING events to work properly. When it's working
properly it should be sending events at approximately 120, 90, 60 and 30
seconds before recording starts.


Klaas I wonder if we should be setting the  default for WakeUpThresold
to pre-roll + 120 instead of 5 minutes if that setting is not present in
the DB?


Paul H.

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Mon, 6 Feb 2023 at 14:08, Paul Harrison <mythtv@mythqml.net> wrote:

> On 06/02/2023 11:17, Jan Ceuleers wrote:
>
> > On 05/02/2023 23:13, Klaas de Waal wrote:
> >> I think ideally you have to have WakeUpThreshold >= global
> pre-roll +
> >> 120. So with your 250 seconds pre-roll I would try something like
> >> 370 or
> >> 400 for WakeUpThreshold. That should give you about 120 seconds
> between
> >> events if I understand the problem properly.
> >>
> >> Yes, I share your understanding of the logic but the HandleWakeSlave is
> >> not called early enough.
> >> My logs show most of the time only two REC_PENDING events, one on 60
> >> seconds and one on 30 seconds.
> >> I think I found where this comes from but I as this is the scheduler I
> >> need to be very careful....
> > I have changed the WakeUpThreshold to 600 (just to be on the safe side),
> > and I still only get two REC_PENDING events (at 60 and 29 seconds), same
> > as Klaas reports.
> >
> > Cheers, Jan
>
>
> OK thanks for testing.
>
>
> The problem must be further up the code in the main scheduler loop which
> is not calling HandleWakeSlave early or often enough for the code that
> sends the REC_PENDING events to work properly. When it's working
> properly it should be sending events at approximately 120, 90, 60 and 30
> seconds before recording starts.
>
> There is the constant kSleepCheck = 300 and this is the maximum number of
seconds to wait between scheduler runs.
See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
where this was changed from a hardcoded 300 to the constant.
When kSleepCheck is changed to 30 seconds then there is always one
REC_PENDING
in the first time window, from 120 to 90 seconds.
Paul, do you think that it is a problem for the scheduler to wake up every
30 seconds?


> Klaas I wonder if we should be setting the default for WakeUpThresold
> to pre-roll + 120 instead of 5 minutes if that setting is not present in
> the DB?
>

I think that this is a good idea because if we do not do this then there is
a constraint
on the RecordPreRoll value that is both unwanted and difficult to explain
to the casual user.
And there is no GUI option to change the WakeUpThreshold as far as I know.
In the slightly longer run we may consider separating WakeUpThreshold and
REC_PENDING events;
the WakeUpThreshold is about starting slave backends and that is not
necessarily related to REC_PENDING events.

Klaas.
Re: Events at the beginning of a recording [ In reply to ]
What happened to the threading for this topic, all the messages are separate from the rest of the conversation?

> On Feb 6, 2023, at 4:27 PM, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
>
>
> On Mon, 6 Feb 2023 at 14:08, Paul Harrison <mythtv@mythqml.net <mailto:mythtv@mythqml.net>> wrote:
>> On 06/02/2023 11:17, Jan Ceuleers wrote:
>>
>> > On 05/02/2023 23:13, Klaas de Waal wrote:
>> >> I think ideally you have to have WakeUpThreshold >= global pre-roll +
>> >> 120. So with your 250 seconds pre-roll I would try something like
>> >> 370 or
>> >> 400 for WakeUpThreshold. That should give you about 120 seconds between
>> >> events if I understand the problem properly.
>> >>
>> >> Yes, I share your understanding of the logic but the HandleWakeSlave is
>> >> not called early enough.
>> >> My logs show most of the time only two REC_PENDING events, one on 60
>> >> seconds and one on 30 seconds.
>> >> I think I found where this comes from but I as this is the scheduler I
>> >> need to be very careful....
>> > I have changed the WakeUpThreshold to 600 (just to be on the safe side),
>> > and I still only get two REC_PENDING events (at 60 and 29 seconds), same
>> > as Klaas reports.
>> >
>> > Cheers, Jan
>>
>>
>> OK thanks for testing.
>>
>>
>> The problem must be further up the code in the main scheduler loop which
>> is not calling HandleWakeSlave early or often enough for the code that
>> sends the REC_PENDING events to work properly. When it's working
>> properly it should be sending events at approximately 120, 90, 60 and 30
>> seconds before recording starts.
>>
> There is the constant kSleepCheck = 300 and this is the maximum number of
> seconds to wait between scheduler runs.
> See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
> Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
> where this was changed from a hardcoded 300 to the constant.
> When kSleepCheck is changed to 30 seconds then there is always one REC_PENDING
> in the first time window, from 120 to 90 seconds.
> Paul, do you think that it is a problem for the scheduler to wake up every 30 seconds?
>
>>
>> Klaas I wonder if we should be setting the default for WakeUpThresold
>> to pre-roll + 120 instead of 5 minutes if that setting is not present in
>> the DB?
>
> I think that this is a good idea because if we do not do this then there is a constraint
> on the RecordPreRoll value that is both unwanted and difficult to explain to the casual user.
> And there is no GUI option to change the WakeUpThreshold as far as I know.
> In the slightly longer run we may consider separating WakeUpThreshold and REC_PENDING events;
> the WakeUpThreshold is about starting slave backends and that is not necessarily related to REC_PENDING events.
>
> Klaas.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org <mailto: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 <https://forum.mythtv.org/>
Re: Events at the beginning of a recording [ In reply to ]
On 06/02/2023 21:27, Klaas de Waal wrote:

>
> There is the constant kSleepCheck = 300 and this is the maximum number of
> seconds to wait between scheduler runs.
> See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
> Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
> where this was changed from a hardcoded 300 to the constant.
> When kSleepCheck is changed to 30 seconds then there is always one
> REC_PENDING
> in the first time window, from  120 to 90 seconds.
> Paul, do you think that it is a problem for the scheduler to wake up
> every 30 seconds?
>

I honestly don't know what side effects that would have. I would consult
with David Engel since the scheduler is his baby.


Paul H.
Re: Events at the beginning of a recording [ In reply to ]
On 06/02/2023 21:38, Jay Harbeston wrote:

> What happened to the threading for this topic, all the messages are
> separate from the rest of the conversation?
>

I'm not seeing any problems with the threading using Thunderbird?


Paul H.

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
> On 06/02/2023 21:27, Klaas de Waal wrote:
>
> >
> > There is the constant kSleepCheck = 300 and this is the maximum number of
> > seconds to wait between scheduler runs.
> > See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
> > Lawrence Rust?authored and Paul Harrison?committed on Jul 15, 2014
> > where this was changed from a hardcoded 300 to the constant.
> > When kSleepCheck is changed to 30 seconds then there is always one
> > REC_PENDING
> > in the first time window, from? 120 to 90 seconds.
> > Paul, do you think that it is a problem for the scheduler to wake up
> > every 30 seconds?
> >
>
> I honestly don't know what side effects that would have. I would consult
> with David Engel since the scheduler is his baby.

Please send me any patches you want considered. However, sleeping
backends is something I've never done nor intend to do. That is all
Chris Murdoch's logic and I usually try to avoid it. IOW, you all are
now probably more versed in it than me.

FWIW, I'd very much like the sleep and wake logic to be moved
completely or mostly out of the scheduler proper and into some other
component which observes the schedule and acts accordingly.

David
--
David Engel
david@istwok.net
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
Apologies for the noise, I had expanded the listing inadvertently. Collapsing it put it back right.

Regards!


> On Feb 6, 2023, at 9:37 PM, David Engel <david@istwok.net> wrote:
>
> On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
>> On 06/02/2023 21:27, Klaas de Waal wrote:
>>
>>>
>>> There is the constant kSleepCheck = 300 and this is the maximum number of
>>> seconds to wait between scheduler runs.
>>> See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
>>> Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
>>> where this was changed from a hardcoded 300 to the constant.
>>> When kSleepCheck is changed to 30 seconds then there is always one
>>> REC_PENDING
>>> in the first time window, from 120 to 90 seconds.
>>> Paul, do you think that it is a problem for the scheduler to wake up
>>> every 30 seconds?
>>>
>>
>> I honestly don't know what side effects that would have. I would consult
>> with David Engel since the scheduler is his baby.
>
> Please send me any patches you want considered. However, sleeping
> backends is something I've never done nor intend to do. That is all
> Chris Murdoch's logic and I usually try to avoid it. IOW, you all are
> now probably more versed in it than me.
>
> FWIW, I'd very much like the sleep and wake logic to be moved
> completely or mostly out of the scheduler proper and into some other
> component which observes the schedule and acts accordingly.
>
> David
> --
> David Engel
> david@istwok.net <mailto:david@istwok.net>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org <mailto: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 <https://forum.mythtv.org/>
Re: Events at the beginning of a recording [ In reply to ]
Apologies for the noise, I had expanded the listing inadvertently. Collapsing it put it back right.

Regards!


> On Feb 6, 2023, at 9:37 PM, David Engel <david@istwok.net> wrote:
>
> On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
>> On 06/02/2023 21:27, Klaas de Waal wrote:
>>
>>>
>>> There is the constant kSleepCheck = 300 and this is the maximum number of
>>> seconds to wait between scheduler runs.
>>> See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
>>> Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
>>> where this was changed from a hardcoded 300 to the constant.
>>> When kSleepCheck is changed to 30 seconds then there is always one
>>> REC_PENDING
>>> in the first time window, from 120 to 90 seconds.
>>> Paul, do you think that it is a problem for the scheduler to wake up
>>> every 30 seconds?
>>>
>>
>> I honestly don't know what side effects that would have. I would consult
>> with David Engel since the scheduler is his baby.
>
> Please send me any patches you want considered. However, sleeping
> backends is something I've never done nor intend to do. That is all
> Chris Murdoch's logic and I usually try to avoid it. IOW, you all are
> now probably more versed in it than me.
>
> FWIW, I'd very much like the sleep and wake logic to be moved
> completely or mostly out of the scheduler proper and into some other
> component which observes the schedule and acts accordingly.
>
> David
> --
> David Engel
> david@istwok.net <mailto:david@istwok.net>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org <mailto: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 <https://forum.mythtv.org/>
Re: Events at the beginning of a recording [ In reply to ]
On 07/02/2023 02:37, David Engel wrote:

> On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
>> On 06/02/2023 21:27, Klaas de Waal wrote:
>>
>>> There is the constant kSleepCheck = 300 and this is the maximum number of
>>> seconds to wait between scheduler runs.
>>> See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
>>> Lawrence Rust authored and Paul Harrison committed on Jul 15, 2014
>>> where this was changed from a hardcoded 300 to the constant.
>>> When kSleepCheck is changed to 30 seconds then there is always one
>>> REC_PENDING
>>> in the first time window, from  120 to 90 seconds.
>>> Paul, do you think that it is a problem for the scheduler to wake up
>>> every 30 seconds?
>>>
>> I honestly don't know what side effects that would have. I would consult
>> with David Engel since the scheduler is his baby.
> Please send me any patches you want considered. However, sleeping
> backends is something I've never done nor intend to do. That is all
> Chris Murdoch's logic and I usually try to avoid it. IOW, you all are
> now probably more versed in it than me.
>
> FWIW, I'd very much like the sleep and wake logic to be moved
> completely or mostly out of the scheduler proper and into some other
> component which observes the schedule and acts accordingly.
>
> David


While it might look like this is related to sleeping backends it's not
really. It all started on the forum where a user was asking why the
REC_PENDING and REC_STARTED events were being sent out of order or too
close together. Whoever wrote the code shoehorned it into the same code
used to wake slave backends and I agree ideally it should be separated
out. I wont speak for Klaas but for me that's a little more involved
than I want to get into right now.  We just want the scheduler to send
out the events in the correct order and at the right times.  The correct
behavior appears to be to sent out REC_PENDING events at 120, 90, 60 and
30 seconds before a recording starts, taking any pre-roll into account,
and then send a REC_STARTED event when the recording actually starts
recording. Any thoughts and how to fix the scheduler to do that correctly?


Paul H.

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Tue, Feb 07, 2023 at 02:05:35PM +0000, Paul Harrison wrote:
> On 07/02/2023 02:37, David Engel wrote:
>
> > On Mon, Feb 06, 2023 at 10:04:04PM +0000, Paul Harrison wrote:
> > > On 06/02/2023 21:27, Klaas de Waal wrote:
> > >
> > > > There is the constant kSleepCheck = 300 and this is the maximum number of
> > > > seconds to wait between scheduler runs.
> > > > See commit 81dffd5ab6becb75f9e004ffe771519d23a58d87
> > > > Lawrence Rust?authored and Paul Harrison?committed on Jul 15, 2014
> > > > where this was changed from a hardcoded 300 to the constant.
> > > > When kSleepCheck is changed to 30 seconds then there is always one
> > > > REC_PENDING
> > > > in the first time window, from? 120 to 90 seconds.
> > > > Paul, do you think that it is a problem for the scheduler to wake up
> > > > every 30 seconds?
> > > >
> > > I honestly don't know what side effects that would have. I would consult
> > > with David Engel since the scheduler is his baby.
> > Please send me any patches you want considered. However, sleeping
> > backends is something I've never done nor intend to do. That is all
> > Chris Murdoch's logic and I usually try to avoid it. IOW, you all are
> > now probably more versed in it than me.
> >
> > FWIW, I'd very much like the sleep and wake logic to be moved
> > completely or mostly out of the scheduler proper and into some other
> > component which observes the schedule and acts accordingly.
> >
> > David
>
>
> While it might look like this is related to sleeping backends it's not
> really. It all started on the forum where a user was asking why the
> REC_PENDING and REC_STARTED events were being sent out of order or too close

Okay. My skimming picked up on the sleeping slave bit as the part
that was new and causing the issue.

> together. Whoever wrote the code shoehorned it into the same code used to
> wake slave backends and I agree ideally it should be separated out. I wont

I don't remember who add the event code.

> speak for Klaas but for me that's a little more involved than I want to get
> into right now.? We just want the scheduler to send out the events in the
> correct order and at the right times.? The correct behavior appears to be to
> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a recording
> starts, taking any pre-roll into account, and then send a REC_STARTED event
> when the recording actually starts recording. Any thoughts and how to fix
> the scheduler to do that correctly?

I see. Sounds like one more reason, IMO, to kill user-configurable
pre- and post-roll. Maybe you all (that's not specifically directed
at any single person) can appreciate the extra, unnecessary complexity
that adds. I'd much rather fix it at 30 seconds or so and add a new
feature to allow starting some recordings up to so many minutes late.
Yes, I know that horse has been dead for a long time but I still enjoy
beating it. It makes me feel better.

Anyway, it sounds like one or both of you have something in mind.
Again, please send me the patch when you have one.

What happens, though, if the schedule changes after a REC_PENDING
event is sent? You're saying to start sending 2 minutes before
pre-roll might start. With a pre-roll of up to 10 minutes, that means
events could start up to 12 minutes before the actual recording.
That's a lot of time in which things could change.

I ask because I've never paid attention to these events before and
want to better understand their intent and use cases, especially the
pending one. The schduler has its own pending state that I beleve
starts about 30 seconds but it might be less before the recording.
That is when the schduler commits to using a specific input and that
decision isn't changed except in a couple of very specific cases.

David
--
David Engel
david@istwok.net
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On 08/02/2023 00:44, David Engel wrote:
>> speak for Klaas but for me that's a little more involved than I want to get
>> into right now.  We just want the scheduler to send out the events in the
>> correct order and at the right times.  The correct behavior appears to be to
>> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a recording
>> starts, taking any pre-roll into account, and then send a REC_STARTED event
>> when the recording actually starts recording. Any thoughts and how to fix
>> the scheduler to do that correctly?
>
> I see. Sounds like one more reason, IMO, to kill user-configurable
> pre- and post-roll. Maybe you all (that's not specifically directed
> at any single person) can appreciate the extra, unnecessary complexity
> that adds. I'd much rather fix it at 30 seconds or so and add a new
> feature to allow starting some recordings up to so many minutes late.
> Yes, I know that horse has been dead for a long time but I still enjoy
> beating it. It makes me feel better.

Please don't. The reason why I use pre-roll (and quite a long-one at
that) is that in this part of the world the guide data is quite
unreliable (meaning that channels see them more as guidelines than as a
commitment to viewers).

I also can't use EIT, for the following reasons:

- EIT data would come from my cable provider, and so it would be in
Dutch, even for foreign channels. I'm in Belgium but my household's
language is English. So I obtain guide data in English (e.g. from
Schedules Direct, but also from other sources).

- I believe that it's either one or the other (i.e. that I should either
use EIT, and possibly benefit from its ability to signal schedule
changes, or other sources). That is: it is not possible to get MythTV to
use EIT data only for the purpose of detecting schedule changes while
still keeping the better-quality guide data I obtain elsewhere.

- Besides, I have little confidence that any late schedule change
decisions made by the broadcasters would make it into EIT data here anyway.

> What happens, though, if the schedule changes after a REC_PENDING
> event is sent? You're saying to start sending 2 minutes before
> pre-roll might start. With a pre-roll of up to 10 minutes, that means
> events could start up to 12 minutes before the actual recording.
> That's a lot of time in which things could change.
>
> I ask because I've never paid attention to these events before and
> want to better understand their intent and use cases, especially the
> pending one. The schduler has its own pending state that I beleve
> starts about 30 seconds but it might be less before the recording.
> That is when the schduler commits to using a specific input and that
> decision isn't changed except in a couple of very specific cases.

My opinion (as a grateful user of 15+ years):

- Clearly the scheduler has to commit to using a certain input prior to
the pre-roll, and not merely prior to the scheduled start of the
recording. It has to, because once the pre-roll period begins the
recording is in progress.

The length of the pre-roll period therefore merely constrains MythTV's
flexibility in acting on late schedule changes, which is a trade-off the
user has to accept in configuring a long pre-roll period.

- My use case for the REC_PENDING event is to physically turn on the
hardware that will be needed to carry out the recording (in my case it
includes a cable STB and an HDMI capture device). The HDMI capture
device is up and running fairly quickly, but the STB needs to boot and
sync with the cable signal before it starts accepting infrared signals
(e.g. for changing channels). That takes around 90 seconds from power-on.

I have three of these video capture pipelines, so I want to save some
energy by powering them down when not in use (using a USB-controlled
power strip). Although the STBs can be configured to go into a deep
sleep mode based on an infrared signal the HDMI capture devices can't
(so they need to be fully powered down), and waking the STBs up from
deep sleep isn't measurably faster than powering them up, so that
wouldn't reduce my need for more notice (than the current 60s) of
impending recordings.

Without more notice I'd need to do the following:

- Power up the pipeline from the first of the REC_PENDING event triggers
(i.e. around 60s before the beginning of the recording), and start a
90-second timer.
- The recording will begin on time, so still 30-or-so seconds before the
STB is ready. At least though the STB will already be emitting a video
signal, so that also the HDMI capture device will emit a stream
(showing the STB's boot screen), so that at least the recording won't be
marked as failed or damaged. But I will need to delay the channel change
command until the above-mentioned 90-second timer expires. So the
channel change will occur 30 seconds into the recording, which is OK-ish.

Feasible but messy.

I believe my use case to align with (but be a complex case of) the
example listed on the wiki (see the "Defining event handlers" section):

https://www.mythtv.org/wiki/MythTV_System_Events

Many thanks, Jan

_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Wed, 8 Feb 2023 at 11:37, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 08/02/2023 00:44, David Engel wrote:
> >> speak for Klaas but for me that's a little more involved than I want to
> get
> >> into right now. We just want the scheduler to send out the events in
> the
> >> correct order and at the right times. The correct behavior appears to
> be to
> >> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a
> recording
> >> starts, taking any pre-roll into account, and then send a REC_STARTED
> event
> >> when the recording actually starts recording. Any thoughts and how to
> fix
> >> the scheduler to do that correctly?
> >
> > I see. Sounds like one more reason, IMO, to kill user-configurable
> > pre- and post-roll. Maybe you all (that's not specifically directed
> > at any single person) can appreciate the extra, unnecessary complexity
> > that adds. I'd much rather fix it at 30 seconds or so and add a new
> > feature to allow starting some recordings up to so many minutes late.
> > Yes, I know that horse has been dead for a long time but I still enjoy
> > beating it. It makes me feel better.
>
> Please don't. The reason why I use pre-roll (and quite a long-one at
> that) is that in this part of the world the guide data is quite
> unreliable (meaning that channels see them more as guidelines than as a
> commitment to viewers).
>

I thought the same when I read this. Isn't it the case that a lot of
MythTV users will be making use of the user-configurable pre and post roll
times? I know I do. While UK programming doesn't usually tend to start
early, it can do occasionally, so I use a 2 minute pre roll. A 4 minute
post roll in the UK seems to be enough to catch a very high percentage of
any late running programmes other than those delayed by sporting events
that overrun. I don't use EIT, so I don't know if that would get updated
quickly enough here to adjust recording times for overrunning sports events
in any case.

Cheers, Ian
Re: Events at the beginning of a recording [ In reply to ]
On Wed, 8 Feb 2023 at 13:55, Ian Cameron <mkbloke@gmail.com> wrote:

> On Wed, 8 Feb 2023 at 11:37, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
>
>> On 08/02/2023 00:44, David Engel wrote:
>> >> speak for Klaas but for me that's a little more involved than I want
>> to get
>> >> into right now. We just want the scheduler to send out the events in
>> the
>> >> correct order and at the right times. The correct behavior appears to
>> be to
>> >> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a
>> recording
>> >> starts, taking any pre-roll into account, and then send a REC_STARTED
>> event
>> >> when the recording actually starts recording. Any thoughts and how to
>> fix
>> >> the scheduler to do that correctly?
>> >
>> > I see. Sounds like one more reason, IMO, to kill user-configurable
>> > pre- and post-roll. Maybe you all (that's not specifically directed
>> > at any single person) can appreciate the extra, unnecessary complexity
>> > that adds. I'd much rather fix it at 30 seconds or so and add a new
>> > feature to allow starting some recordings up to so many minutes late.
>> > Yes, I know that horse has been dead for a long time but I still enjoy
>> > beating it. It makes me feel better.
>>
>> Please don't. The reason why I use pre-roll (and quite a long-one at
>> that) is that in this part of the world the guide data is quite
>> unreliable (meaning that channels see them more as guidelines than as a
>> commitment to viewers).
>>
>
> I thought the same when I read this. Isn't it the case that a lot of
> MythTV users will be making use of the user-configurable pre and post roll
> times? I know I do. While UK programming doesn't usually tend to start
> early, it can do occasionally, so I use a 2 minute pre roll. A 4 minute
> post roll in the UK seems to be enough to catch a very high percentage of
> any late running programmes other than those delayed by sporting events
> that overrun. I don't use EIT, so I don't know if that would get updated
> quickly enough here to adjust recording times for overrunning sports events
> in any case.
>

I do not intend to remove the RecordPreRoll, one good reason being that I
use it myself. Even with EIT it is useful and MythTV is clever enough to
put the start point at the scheduled program start time so it is always
automatically skipped over and I can skip back when it is needed.

To summarize, I understand that this are the requirements:
- REC_PENDING always before the REC_STARTED
- REC_PENDING at 120, 90, 60 and 30 before the start of the recording
- Start of the recording is the scheduled program start time plus the
preroll
- When a recording is immediately started after scheduling then there is
one REC_PENDING event with 0 seconds immediately before the REC_STARTED

I do have a slightly hacky implementation that does all this, it needs a
bit of cleaning up and more testing.
This is just a fix, not a rewrite/refactoring. That is something we leave
for another day.
I might however make a Github issue for this so that we capture the
knowledge and not forget.....

Klaas.
Re: Events at the beginning of a recording [ In reply to ]
On Wed, 8 Feb 2023 at 17:19, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> On Wed, 8 Feb 2023 at 13:55, Ian Cameron <mkbloke@gmail.com> wrote:
>
>> I thought the same when I read this. Isn't it the case that a lot of
>> MythTV users will be making use of the user-configurable pre and post roll
>> times? I know I do. While UK programming doesn't usually tend to start
>> early, it can do occasionally, so I use a 2 minute pre roll. A 4 minute
>> post roll in the UK seems to be enough to catch a very high percentage of
>> any late running programmes other than those delayed by sporting events
>> that overrun. I don't use EIT, so I don't know if that would get updated
>> quickly enough here to adjust recording times for overrunning sports events
>> in any case.
>>
>
> I do not intend to remove the RecordPreRoll, one good reason being that I
> use it myself. Even with EIT it is useful and MythTV is clever enough to
> put the start point at the scheduled program start time so it is always
> automatically skipped over and I can skip back when it is needed.
>

Phew! Thanks.

To summarize, I understand that this are the requirements:
> - REC_PENDING always before the REC_STARTED
> - REC_PENDING at 120, 90, 60 and 30 before the start of the recording
> - Start of the recording is the scheduled program start time plus the
> preroll
> - When a recording is immediately started after scheduling then there is
> one REC_PENDING event with 0 seconds immediately before the REC_STARTED
>
> I do have a slightly hacky implementation that does all this, it needs a
> bit of cleaning up and more testing.
> This is just a fix, not a rewrite/refactoring. That is something we leave
> for another day.
> I might however make a Github issue for this so that we capture the
> knowledge and not forget.....
>

If you have the beginnings of a fix, I guess that might be the most
time-efficient way to do things. What you have listed is pretty much how
things operated in the past I think (I detailed what I see in 0.28
previously in this thread). I assume then that somewhere there is a commit
that has broken this, which could in theory be identified with a git
bisect, but perhaps that's not worthwhile now.

Thanks for your ongoing work, on behalf of us users.

Cheers, Ian
Re: Events at the beginning of a recording [ In reply to ]
On Wed, Feb 08, 2023 at 05:49:34PM +0000, Ian Cameron wrote:
> On Wed, 8 Feb 2023 at 17:19, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>
> > On Wed, 8 Feb 2023 at 13:55, Ian Cameron <mkbloke@gmail.com> wrote:
> >
> >> I thought the same when I read this. Isn't it the case that a lot of
> >> MythTV users will be making use of the user-configurable pre and post roll
> >> times? I know I do. While UK programming doesn't usually tend to start
> >> early, it can do occasionally, so I use a 2 minute pre roll. A 4 minute
> >> post roll in the UK seems to be enough to catch a very high percentage of
> >> any late running programmes other than those delayed by sporting events
> >> that overrun. I don't use EIT, so I don't know if that would get updated
> >> quickly enough here to adjust recording times for overrunning sports events
> >> in any case.
> >>
> >
> > I do not intend to remove the RecordPreRoll, one good reason being that I
> > use it myself. Even with EIT it is useful and MythTV is clever enough to
> > put the start point at the scheduled program start time so it is always
> > automatically skipped over and I can skip back when it is needed.
> >
>
> Phew! Thanks.

But I still might! Someday. When I have a better solution to the
misuse. I've never bought the "my guide data is bad" argument and I
still don't. In the immortal words of Steve Jobs, "You're doing it
wrong?" :)

Either you care about catching the beginning or ends or your
recordings or you don't.

If you do care, you should use the start early/end late options.
That's what they are for(*). If there is a conflict, wouldn't you
really rather have the scheduler choose a later showing that woh't get
chopped off? IMO, that's much better hoping that the tetris blocks
just happen to fall in perfect way by accident. If there is a
conflict, the scheduler will tell you so that YOU can make the best,
informed decision on what to do.

If you don't care about your recordings getting chopped off, then
what's the beef? Okay, so you really do care, at least some and want
oportunistic lengthening of recordings. I think that's the wrong
approach. I think it would be better to apply oportunistic
shortening, mainly at the beginning, where the recording rule
explicitly specifies how much shortening is acceptable.

David

(*)FWIW, the scheduler already has the ability increase the likelyhood
that recordings on the same channel/multiplex that can safely overlap
will overlap. More people should take advantage of that

> To summarize, I understand that this are the requirements:
> > - REC_PENDING always before the REC_STARTED
> > - REC_PENDING at 120, 90, 60 and 30 before the start of the recording
> > - Start of the recording is the scheduled program start time plus the
> > preroll
> > - When a recording is immediately started after scheduling then there is
> > one REC_PENDING event with 0 seconds immediately before the REC_STARTED
> >
> > I do have a slightly hacky implementation that does all this, it needs a
> > bit of cleaning up and more testing.
> > This is just a fix, not a rewrite/refactoring. That is something we leave
> > for another day.
> > I might however make a Github issue for this so that we capture the
> > knowledge and not forget.....
> >
>
> If you have the beginnings of a fix, I guess that might be the most
> time-efficient way to do things. What you have listed is pretty much how
> things operated in the past I think (I detailed what I see in 0.28
> previously in this thread). I assume then that somewhere there is a commit
> that has broken this, which could in theory be identified with a git
> bisect, but perhaps that's not worthwhile now.
>
> Thanks for your ongoing work, on behalf of us users.
>
> Cheers, Ian

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


--
David Engel
david@istwok.net
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On Wed, Feb 08, 2023 at 09:09:07PM -0600, David Engel wrote:
> On Wed, Feb 08, 2023 at 05:49:34PM +0000, Ian Cameron wrote:
> > On Wed, 8 Feb 2023 at 17:19, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> >
> > > On Wed, 8 Feb 2023 at 13:55, Ian Cameron <mkbloke@gmail.com> wrote:
> > >
> > >> I thought the same when I read this. Isn't it the case that a lot of
> > >> MythTV users will be making use of the user-configurable pre and post roll
> > >> times? I know I do. While UK programming doesn't usually tend to start
> > >> early, it can do occasionally, so I use a 2 minute pre roll. A 4 minute
> > >> post roll in the UK seems to be enough to catch a very high percentage of
> > >> any late running programmes other than those delayed by sporting events
> > >> that overrun. I don't use EIT, so I don't know if that would get updated
> > >> quickly enough here to adjust recording times for overrunning sports events
> > >> in any case.
> > >>
> > >
> > > I do not intend to remove the RecordPreRoll, one good reason being that I
> > > use it myself. Even with EIT it is useful and MythTV is clever enough to
> > > put the start point at the scheduled program start time so it is always
> > > automatically skipped over and I can skip back when it is needed.
> > >
> >
> > Phew! Thanks.
>
> But I still might! Someday. When I have a better solution to the
> misuse. I've never bought the "my guide data is bad" argument and I
> still don't. In the immortal words of Steve Jobs, "You're doing it
> wrong?" :)
>
> Either you care about catching the beginning or ends or your
> recordings or you don't.

Also, how many of you that claim you must have long pre- and
post-rolls have actually tried using start early/end late instead? I
suspect most of you would get by just fine.

David

> If you do care, you should use the start early/end late options.
> That's what they are for(*). If there is a conflict, wouldn't you
> really rather have the scheduler choose a later showing that woh't get
> chopped off? IMO, that's much better hoping that the tetris blocks
> just happen to fall in perfect way by accident. If there is a
> conflict, the scheduler will tell you so that YOU can make the best,
> informed decision on what to do.
>
> If you don't care about your recordings getting chopped off, then
> what's the beef? Okay, so you really do care, at least some and want
> oportunistic lengthening of recordings. I think that's the wrong
> approach. I think it would be better to apply oportunistic
> shortening, mainly at the beginning, where the recording rule
> explicitly specifies how much shortening is acceptable.
>
> David
>
> (*)FWIW, the scheduler already has the ability increase the likelyhood
> that recordings on the same channel/multiplex that can safely overlap
> will overlap. More people should take advantage of that
>
> > To summarize, I understand that this are the requirements:
> > > - REC_PENDING always before the REC_STARTED
> > > - REC_PENDING at 120, 90, 60 and 30 before the start of the recording
> > > - Start of the recording is the scheduled program start time plus the
> > > preroll
> > > - When a recording is immediately started after scheduling then there is
> > > one REC_PENDING event with 0 seconds immediately before the REC_STARTED
> > >
> > > I do have a slightly hacky implementation that does all this, it needs a
> > > bit of cleaning up and more testing.
> > > This is just a fix, not a rewrite/refactoring. That is something we leave
> > > for another day.
> > > I might however make a Github issue for this so that we capture the
> > > knowledge and not forget.....
> > >
> >
> > If you have the beginnings of a fix, I guess that might be the most
> > time-efficient way to do things. What you have listed is pretty much how
> > things operated in the past I think (I detailed what I see in 0.28
> > previously in this thread). I assume then that somewhere there is a commit
> > that has broken this, which could in theory be identified with a git
> > bisect, but perhaps that's not worthwhile now.
> >
> > Thanks for your ongoing work, on behalf of us users.
> >
> > Cheers, Ian
>
> > _______________________________________________
> > 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
>
>
> --
> David Engel
> david@istwok.net

--
David Engel
david@istwok.net
_______________________________________________
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: Events at the beginning of a recording [ In reply to ]
On 09/02/2023 04:36, David Engel wrote:
>> But I still might! Someday. When I have a better solution to the
>> misuse. I've never bought the "my guide data is bad" argument and I
>> still don't. In the immortal words of Steve Jobs, "You're doing it
>> wrong?" :)
>>
>> Either you care about catching the beginning or ends or your
>> recordings or you don't.
>
> Also, how many of you that claim you must have long pre- and
> post-rolls have actually tried using start early/end late instead? I
> suspect most of you would get by just fine.

Just to state my understanding of your point: I believe you refer to
specifying pre and post-roll in recording rules, is that right? (Perhaps
I'm not using the correct terminology here; apologies if so).

If so, the reason why I am now using the global pre-roll feature is
that, in my understanding, it enables back-to-back recordings on the
same capture card, whereas with recording rule-specified pre/post-rolls
two capture cards are needed to record back-to-back programs.

The other reason is one of convenience: it is easier to specify
pre/post-roll periods in only one place rather than having to do so in
each recording rule. Particularly if a bad experience shows that the
pre/post-roll periods need to be extended. Please keep in mind that the
guide data unreliability we face here is universal and unpredictable, so
the pre/post-roll periods need to be applied to all recordings.

I used to use recording rule-specified pre/post-rolls but switched to
the global approach for these reasons.

BTW (and I don't mean to annoy you), a dream feature sidestepping the
first reason above would be to add "multirec" capabilities to all
capture cards, by regarding a regular (currently non-multirec capable)
tuner as one that has as many "multiplexes" as it has channels it can
tune to (i.e. 1 channel = 1 multiplex), such that a channel can be
recorded from multiple times at once. This would enable recording
back-to-back shows, with each recording containing its own pre/post-roll.

>> If you do care, you should use the start early/end late options.
>> That's what they are for(*). If there is a conflict, wouldn't you
>> really rather have the scheduler choose a later showing that woh't get
>> chopped off? IMO, that's much better hoping that the tetris blocks
>> just happen to fall in perfect way by accident. If there is a
>> conflict, the scheduler will tell you so that YOU can make the best,
>> informed decision on what to do.

I'm afraid I don't understand this point. The scheduler cannot know
whether a show is going to be chopped off because it can only base its
decisions on the guide data it has at its disposal. If that guide data
is unreliable all bets are off.

HTH, Jan
_______________________________________________
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

1 2 3  View All