Mailing List Archive

On Tue, 2023-01-24 at 18:59 +0100, Jan Ceuleers wrote:
> Hi.
>
> I was wondering whether there is any more documentation about the
> recording pending and recording started events than is available on
> the
> wiki (which isn't very much).
>
> I have read that the one envisaged uses of the recording pending
> event
> is for it to trigger e.g. a set-top box being woken up, but for that
> to
> be possible it would have to be triggered before the recording
> actually
> begins, and the beginning of the recording should also wait until the
> recording pending script returns.
>
> On my backend I'm seeing the opposite: the recording started event
> occurs before the recording pending event, and it obviously doesn't
> wait
> for one event to be handled before the next-one begins.
>
> So how is this actually meant to work?
>
> 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
I use both, pending gets called initially 1 minute BEFORE the show
starts and started gets call at start time.
Attached are my 2 scripts, since I have 2 different set-top boxes and
inputs it has to handle both.
mythtv_recording_pending.sh and mythtv_recording_started.sh

Don't know if attachments actually make to the mailing list and thru...

Jim

On Tue, 24 Jan 2023 at 18:02, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> I was wondering whether there is any more documentation about the
> recording pending and recording started events than is available on the
> wiki (which isn't very much).
>

I'm not sure there is, so you'll have to rely on the wisdom of folks on
this list, I think.

I have read that the one envisaged uses of the recording pending event
> is for it to trigger e.g. a set-top box being woken up, but for that to
> be possible it would have to be triggered before the recording actually
> begins, and the beginning of the recording should also wait until the
> recording pending script returns.
>

As far as I know, the recording pending events are fired asynchronously.
There is no waiting for them to finish, rather, they are expected to have
successfully done their job before MythTV starts recording (including the
pre-roll). On my system I consistently see recording pending events
triggered at 94, 60 and 29 seconds before the pre-roll is due to start.

If you're only powering on a set-top box and changing its channel, then I
would have thought 29s would be enough time to successfully complete that.
You can pass %SECS% to the script in mythtv-setup for the recording_pending
system event script configuration.

If you're passing %SECS% as the first parameter to your script, then in the
script you can do something like:

ME="$(/usr/bin/basename ${0})"
TIME_SECS=${1}
if [ ${TIME_SECS} -gt 35 ]
then
echo "${ME}: time to programme start ${TIME_SECS}; exiting" \
>> /some/path/recording_pending.log
exit
fi
# put channel change stuff here

If you needed more time, then you could change '-gt 35' to '-gt 65',
above. If you do that though the pending script is still called again and
if you don't want it to execute again then in that case, you'd need to
create a semaphore file during the ~60s event, that is then checked for by
the ~30s event and then deleted within that event before exiting having
done nothing more.

On my backend I'm seeing the opposite: the recording started event
> occurs before the recording pending event, and it obviously doesn't wait
> for one event to be handled before the next-one begins.
>

I haven't tried using recording_started, but it seems like it should come
after pending to me, so that's a bit odd.

Cheers, Ian

On Tue, 24 Jan 2023 at 19:46, Ian Cameron <mkbloke@gmail.com> wrote:

> ME="$(/usr/bin/basename ${0})"
> TIME_SECS=${1}
> if [ ${TIME_SECS} -gt 35 ]
> then
> echo "${ME}: time to programme start ${TIME_SECS}; exiting" \
> >> /some/path/recording_pending.log
> exit
> fi
> # put channel change stuff here
>

Oops, it should be "if [ $TIME_SECS -lt 35 ]", above for what I described.
Also, for using the ~60s event, rather than a semaphore file, you could use:

if [ $TIME_SECS -gt 35 -a $TIME_SECS -lt 65 ]

Cheers, Ian

On 24/01/2023 20:46, Ian Cameron wrote:
> As far as I know, the recording pending events are fired
> asynchronously.  There is no waiting for them to finish, rather, they
> are expected to have successfully done their job before MythTV starts
> recording (including the pre-roll).  On my system I consistently see
> recording pending events triggered at 94, 60 and 29 seconds before the
> pre-roll is due to start.

I don't see that. What I see is as follows:

Only one recording-pending event is triggered, not three as you observe
on your system.

The order I see is as follows:

1. The recording-started event is triggered first, almost simultaneously
with the mythexternalrecorder's tuner command (at "second 0").

2. The recording-pending event is triggered next, at "second 5". So 5
seconds after the recording has already started.

Do you know whether these timings are parameters that I may have
misconfigured in the database? My database is quite old and has been
upgraded many times over the 15+ years that it has been in use.

Also, assuming I can get these events into the correct order, my
situation is that I need to power up the set-top box, and it takes quite
some time to boot to a condition in which it is able to accept infrared
commands (i.e. able to change channels).

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

Hoi Jan,

Wednesday, January 25, 2023, 5:31:36 PM, you wrote:

> On 24/01/2023 20:46, Ian Cameron wrote:
>> As far as I know, the recording pending events are fired
>> asynchronously.  There is no waiting for them to finish, rather, they
>> are expected to have successfully done their job before MythTV starts
>> recording (including the pre-roll).  On my system I consistently see
>> recording pending events triggered at 94, 60 and 29 seconds before the
>> pre-roll is due to start.

> I don't see that. What I see is as follows:

> Only one recording-pending event is triggered, not three as you observe
> on your system.

> The order I see is as follows:

> 1. The recording-started event is triggered first, almost simultaneously
> with the mythexternalrecorder's tuner command (at "second 0").

> 2. The recording-pending event is triggered next, at "second 5". So 5
> seconds after the recording has already started.

> Do you know whether these timings are parameters that I may have
> misconfigured in the database? My database is quite old and has been
> upgraded many times over the 15+ years that it has been in use.

> Also, assuming I can get these events into the correct order, my
> situation is that I need to power up the set-top box, and it takes quite
> some time to boot to a condition in which it is able to accept infrared
> commands (i.e. able to change channels).

> Cheers, Jan

Am I correct that you are working on conserving electricity by only
powering up devices when needed?
I am currently working on a network management tool to achieve just
that and am now implementing a eg-pms2-lan with switchable power
sockets to among others manage my hdhomrun.
I use the mythtv api to extract a recording schedule for those tuners
to determine when to switch on or off.
Use "Dvr/GetUpcomingList" and "Dvr/GetEncoderList" to get the upcoming
and pending recordings.

I can give you the Mythtv API python module based on Stephen
Worthington's gaps program.

I'm afraid it will take some more time before I can publish the entire
package.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
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

On 25/01/2023 18:29, Hika van den Hoven wrote:
> Am I correct that you are working on conserving electricity by only
> powering up devices when needed?

Yes, that's what I'm trying to achieve. I have three HDMI video capture
pipelines (STB, HDMI encoder and another device which shall remain
unnamed), and I am powering all three with a single 12VDC power supply
(and a 12V to 5V buck converter for the devices that require 5VDC),
which is plugged into an old 4-socket Gembird USB-controlled power strip
I had from an era long past.

Ideally I would like the sockets to be controlled by scripts ultimately
invoked from the MythTV backend, so that (among other things) they are
also powered down when the backend service is stopped, e.g. as part of
the whole server being shut down.

> I am currently working on a network management tool to achieve just
> that and am now implementing a eg-pms2-lan with switchable power
> sockets to among others manage my hdhomrun.
> I use the mythtv api to extract a recording schedule for those tuners
> to determine when to switch on or off.

I can see that working for scheduled recordings, but live TV (which I
occasionally use for testing) wouldn't work as it's of course unscheduled.

But I am indeed interested, since live TV is very much a corner case.
I'd also still want to work on powering stuff down while MythTV is down,
but that can probably be done independently of your scheme.

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

On Wed, 25 Jan 2023 at 16:34, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> The order I see is as follows:
>
> 1. The recording-started event is triggered first, almost simultaneously
> with the mythexternalrecorder's tuner command (at "second 0").
>
> 2. The recording-pending event is triggered next, at "second 5". So 5
> seconds after the recording has already started.
>

How are you observing this?

I'd be tempted to set up a script for the recording_pending event that
simply runs:

date >> /tmp/pending.log

to see when and how many times it's called.

I don't know if it's your use of mythexternalrecorder that makes any
difference - I'm using IPTV. I'm also running 0.28 at the moment.

Do you know whether these timings are parameters that I may have
> misconfigured in the database? My database is quite old and has been
> upgraded many times over the 15+ years that it has been in use.
>

Not that I'm aware of.

Cheers, Ian

On 25/01/2023 20:11, Ian Cameron wrote:
> On Wed, 25 Jan 2023 at 16:34, Jan Ceuleers <jan.ceuleers@gmail.com
> <mailto:jan.ceuleers@gmail.com>> wrote:
>
> The order I see is as follows:
>
> 1. The recording-started event is triggered first, almost simultaneously
> with the mythexternalrecorder's tuner command (at "second 0").
>
> 2. The recording-pending event is triggered next, at "second 5". So 5
> seconds after the recording has already started.
>
>
> How are you observing this?
>
> I'd be tempted to set up a script for the recording_pending event that
> simply runs:
>
> date >> /tmp/pending.log
>
> to see when and how many times it's called.

That's more or less what I'm doing, except that I'm having these scripts
send emails to myself that include the time stamp with second
resolution. I'm also having them create syslog entries.

For example, here is the recording-pending script (with the actual email
address redacted):

#!/bin/bash
(
echo "$0: called with parameters $*"
/bin/date
) | /usr/bin/mail -a From: jan.ceuleers@example.com -s "MythTV system
event $0" jan.ceuleers@example.com
logger "$0 called with parameters $*"

_______________________________________________
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

Hoi Jan,

Wednesday, January 25, 2023, 7:29:35 PM, you wrote:

> On 25/01/2023 18:29, Hika van den Hoven wrote:
>> Am I correct that you are working on conserving electricity by only
>> powering up devices when needed?

> Yes, that's what I'm trying to achieve. I have three HDMI video capture
> pipelines (STB, HDMI encoder and another device which shall remain
> unnamed), and I am powering all three with a single 12VDC power supply
> (and a 12V to 5V buck converter for the devices that require 5VDC),
> which is plugged into an old 4-socket Gembird USB-controlled power strip
> I had from an era long past.

> Ideally I would like the sockets to be controlled by scripts ultimately
> invoked from the MythTV backend, so that (among other things) they are
> also powered down when the backend service is stopped, e.g. as part of
> the whole server being shut down.

>> I am currently working on a network management tool to achieve just
>> that and am now implementing a eg-pms2-lan with switchable power
>> sockets to among others manage my hdhomrun.
>> I use the mythtv api to extract a recording schedule for those tuners
>> to determine when to switch on or off.

> I can see that working for scheduled recordings, but live TV (which I
> occasionally use for testing) wouldn't work as it's of course unscheduled.

> But I am indeed interested, since live TV is very much a corner case.
> I'd also still want to work on powering stuff down while MythTV is down,
> but that can probably be done independently of your scheme.

> Thanks, Jan
> _______________________________________________

If you wait a few months, I'll publish my management application. It
at present basically consists of a daemon running on my backend and on
a rPi that coordinates it all. All machines are interlinked in
dependencies. So if my workstation or frontend is waken, the backend
is waken too. If a frontend is still awake, sleep will be halted. You
can register the pid of a script and while it's running sleep is
halted. Etc...
Except for a small core around the rPi, this way everything can be
shut down and will wake at need.
Is tricky to get it all to work dependably.

Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
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

On Wed, 25 Jan 2023 at 19:21, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> That's more or less what I'm doing, except that I'm having these scripts
> send emails to myself that include the time stamp with second
> resolution. I'm also having them create syslog entries.
>

I can only think that this is specific to mythexternalrecorder then.

Cheers, Ian

On Wed, 25 Jan 2023 17:31:36 +0100, you wrote:

>On 24/01/2023 20:46, Ian Cameron wrote:
>> As far as I know, the recording pending events are fired
>> asynchronously.? There is no waiting for them to finish, rather, they
>> are expected to have successfully done their job before MythTV starts
>> recording (including the pre-roll).? On my system I consistently see
>> recording pending events triggered at 94, 60 and 29 seconds before the
>> pre-roll is due to start.
>
>I don't see that. What I see is as follows:
>
>Only one recording-pending event is triggered, not three as you observe
>on your system.
>
>The order I see is as follows:
>
>1. The recording-started event is triggered first, almost simultaneously
>with the mythexternalrecorder's tuner command (at "second 0").
>
>2. The recording-pending event is triggered next, at "second 5". So 5
>seconds after the recording has already started.
>
>Do you know whether these timings are parameters that I may have
>misconfigured in the database? My database is quite old and has been
>upgraded many times over the 15+ years that it has been in use.
>
>Also, assuming I can get these events into the correct order, my
>situation is that I need to power up the set-top box, and it takes quite
>some time to boot to a condition in which it is able to accept infrared
>commands (i.e. able to change channels).

What is supposed to happen is that the recording-pending event happens
first, typically about 60 seconds before the start of the recording.
From that event, you are supposed to start anything that needs
starting, and tune your set top box (or whatever is providing the
signal) to the correct channel.

Then at the exact time the recording starts, the recording-started
event happens. When this happens depends on the settings for
pre-roll, including the global one (typically 60 seconds) and the one
on the recording rule, which in my case is set according to the
channel and may be 1, 2 or 3 minutes.

On my mother's MythTV box where I used to do FM radio recordings using
these events, that was how it worked, but that was many years ago. On
the box I still have a script "event_test.sh" that is run by a number
of events (including the "ANY" event) and logs when it happens:

#!/bin/bash

me=$(/usr/bin/basename "${0}")
log=/var/log/mythtv/event_test.log
echo `date` "$me $@" >>$log
exit 0

I also have "event-start-recording.sh" and
"event-finished-recording.sh" scripts on the appropriate events.

The logging shows that the first recording-pending event is happening
well before the recording-started event, but there are multiple
recording-pending events happening. Here is an example of the
logging:

Wed 25 Jan 2023 19:26:00 NZDT event_test.sh Any REC_PENDING %SENDER%
90 10073 2023-01-25T05:30:00Z 2023-01-25T06:30:00Z
2023-01-25T05:30:00Z 2023-01-25T06:30:00Z 120 0 Default
Wed 25 Jan 2023 19:26:00 NZDT event_test.sh RecordingPending %SENDER%
90 10073 2023-01-25T05:30:00Z 2023-01-25T06:30:00Z
2023-01-25T05:30:00Z 2023-01-25T06:30:00Z 120 0 Default
Wed 25 Jan 2023 19:26:00 NZDT event_test.sh Any SCHEDULER_RAN crw-pvr
%HOSTNAME% %CARDID% 0 %DIR% %FILE% %PROGSTARTISOUTC% %PROGENDISOUTC%
%STARTTIMEISOUTC% %ENDTIMEISOUTC% %SECS% %REACTIVATE% %RECGROUP%
Wed 25 Jan 2023 19:26:00 NZDT event_test.sh SchedulerRan crw-pvr
%HOSTNAME% %CARDID% 0 %DIR% %FILE% %PROGSTARTISOUTC% %PROGENDISOUTC%
%STARTTIMEISOUTC% %ENDTIMEISOUTC% %SECS% %REACTIVATE% %RECGROUP%
Wed 25 Jan 2023 19:26:31 NZDT event_test.sh Any REC_PENDING %SENDER%
90 10073 2023-01-25T05:30:00Z 2023-01-25T06:30:00Z
2023-01-25T05:30:00Z 2023-01-25T06:30:00Z 88 0 Default
Wed 25 Jan 2023 19:26:31 NZDT event_test.sh RecordingPending %SENDER%
90 10073 2023-01-25T05:30:00Z 2023-01-25T06:30:00Z
2023-01-25T05:30:00Z 2023-01-25T06:30:00Z 88 0 Default
Wed 25 Jan 2023 19:27:00 NZDT event_test.sh Any REC_STARTED %SENDER%
crw-pvr 90 10073 GetPlaybackURL/UNABLE/TO/FIND/LOCAL/FILE/ON/crw-pvr
10073_20230125062700.ts 2023-01-25T06:30:00Z 2023-01-25T07:30:00Z
2023-01-25T06:27:00Z 2023-01-25T07:34:00Z %SECS% 0 Default
Wed 25 Jan 2023 19:27:00 NZDT event-start-recording.sh %SENDER%
crw-pvr 90 10073 GetPlaybackURL/UNABLE/TO/FIND/LOCAL/FILE/ON/crw-pvr
10073_20230125062700.ts
Wed 25 Jan 2023 19:27:00 NZDT event-start-recording.sh Exiting now
Wed 25 Jan 2023 19:27:00 NZDT event_test.sh Any REC_PENDING %SENDER%
crw-pvr 90 10073 GetPlaybackURL/UNABLE/TO/FIND/LOCAL/FILE/ON/crw-pvr
10073_20230125062700.ts 2023-01-25T06:30:00Z 2023-01-25T07:30:00Z
2023-01-25T06:27:00Z 2023-01-25T07:34:00Z 0 0 Default
Wed 25 Jan 2023 19:27:00 NZDT event_test.sh RecordingPending %SENDER%
crw-pvr 90 10073 GetPlaybackURL/UNABLE/TO/FIND/LOCAL/FILE/ON/crw-pvr
10073_20230125062700.ts 2023-01-25T06:30:00Z 2023-01-25T07:30:00Z
2023-01-25T06:27:00Z 2023-01-25T07:34:00Z 0 0 Default
Wed 25 Jan 2023 19:27:04 NZDT event_test.sh Any REC_STARTED_WRITING
%SENDER% crw-pvr 90 10073 /mnt/rec3/recordings 10073_20230125062700.ts
2023-01-25T06:30:00Z 2023-01-25T07:30:00Z 2023-01-25T06:27:00Z
2023-01-25T07:34:00Z %SECS% 0 Default
Wed 25 Jan 2023 20:38:00 NZDT event_test.sh Any REC_FINISHED %SENDER%
crw-pvr 90 10073 /mnt/rec3/recordings 10073_20230125062700.ts
2023-01-25T06:30:00Z 2023-01-25T07:30:00Z 2023-01-25T06:27:00Z
2023-01-25T07:38:00Z %SECS% 0 Default
Wed 25 Jan 2023 20:38:00 NZDT event-finished-recording.sh %SENDER%
crw-pvr 90 10073 /mnt/rec3/recordings 10073_20230125062700.ts
Wed 25 Jan 2023 20:38:00 NZDT event_test.sh Any SCHEDULER_RAN crw-pvr
%HOSTNAME% %CARDID% 0 %DIR% %FILE% %PROGSTARTISOUTC% %PROGENDISOUTC%
%STARTTIMEISOUTC% %ENDTIMEISOUTC% %SECS% %REACTIVATE% %RECGROUP%
Wed 25 Jan 2023 20:38:00 NZDT event_test.sh SchedulerRan crw-pvr
%HOSTNAME% %CARDID% 0 %DIR% %FILE% %PROGSTARTISOUTC% %PROGENDISOUTC%
%STARTTIMEISOUTC% %ENDTIMEISOUTC% %SECS% %REACTIVATE% %RECGROUP%

Sorry about all the long lines being wrapped - my email client does
that and it does not have an option to not do it. I would suggest
copying those lines to an editor and unwrapping them to be able to
read them properly - Each line starts with "Wed 25 Jan".

As well as just the recording-pending and recording-started events,
there are now also events added in more recent versions of MythTV than
when I was using these scripts, which includes a "recording-writing"
event that happens when the recording file is actually being written
to.

If you want to see all the event activity, try adding a script like
mine to the EventCmdAll event:

MariaDB [mythconverg]> select * from settings where value like
'EventCmdAll';
+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
| value | data | hostname |
+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
| EventCmdAll | /usr/local/bin/event_test.sh Any %EVENTNAME% %SENDER% %HOSTNAME% %CARDID% %CHANID% %DIR% %FILE% %PROGSTARTISOUTC% %PROGENDISOUTC% %STARTTIMEISOUTC% %ENDTIMEISOUTC% %SECS% %REACTIVATE% %RECGROUP% | crw-pvr |
+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+

The %EVENTNAME% parameter will allow the script to log the name of the
event.
_______________________________________________
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

Shoot me for top posting again.

I use both of these "pending" and "started" events with my
FREEBOX tuner, which is really just
STB -> IPTV_Encoder -> NETWORK-CONNECTION-> Mythtv (FREEBOX)

I control the STB tuning this way, and my actual channel chager scripts
check if the STB is on FIRST, if it is not they turn it on.


I log everything.

I get a "recording-pending" event 60 seconds BEFORE the recording is
due to start (which my scripts, attached in my first reply on this)
ignore. I get a second "recording-pending" event ~30 seconds BEFORE the
recording is due to start (which my scripts play a countdown on and
actually call the channel-changer script (to power on the box and set
the channel).
Then right at the tim the recording starts I get a single "recording-
started" event...

This has been this way for a few years, from v29 -> v30 -> v31 (which
is what I am currently running).

Jim

On Wed, 2023-01-25 at 17:31 +0100, Jan Ceuleers wrote:
> On 24/01/2023 20:46, Ian Cameron wrote:
> > As far as I know, the recording pending events are fired
> > asynchronously. There is no waiting for them to finish, rather,
> > they
> > are expected to have successfully done their job before MythTV
> > starts
> > recording (including the pre-roll). On my system I consistently
> > see
> > recording pending events triggered at 94, 60 and 29 seconds before
> > the
> > pre-roll is due to start.
>
> I don't see that. What I see is as follows:
>
> Only one recording-pending event is triggered, not three as you
> observe
> on your system.
>
> The order I see is as follows:
>
> 1. The recording-started event is triggered first, almost
> simultaneously
> with the mythexternalrecorder's tuner command (at "second 0").
>
> 2. The recording-pending event is triggered next, at "second 5". So 5
> seconds after the recording has already started.
>
> Do you know whether these timings are parameters that I may have
> misconfigured in the database? My database is quite old and has been
> upgraded many times over the 15+ years that it has been in use.
>
> Also, assuming I can get these events into the correct order, my
> situation is that I need to power up the set-top box, and it takes
> quite
> some time to boot to a condition in which it is able to accept
> infrared
> commands (i.e. able to change channels).
>
> 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

_______________________________________________
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

On 25/01/2023 21:22, Ian Cameron wrote:
> I can only think that this is specific to mythexternalrecorder then.

I also have an HDHR, and the out-of-order events also affect those
recordings, so no, it is not specific to mythexternalrecorder.

I'll do some code-reading.
_______________________________________________
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

On 26/01/2023 09:12, Jan Ceuleers wrote:
> On 25/01/2023 21:22, Ian Cameron wrote:
>> I can only think that this is specific to mythexternalrecorder then.
>
> I also have an HDHR, and the out-of-order events also affect those
> recordings, so no, it is not specific to mythexternalrecorder.
>
> I'll do some code-reading.

Done some code-reading, but there's just too much code and logging for
me to be able to understand what's going on (and wrong).

But it is clear that the recording pending event is being sent after
recording has started. I know this because the SECS parameter is
negative (-24 in a recent run).

Open to advice on how to make progress.

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

The REC_PENDING event is now coming before the REC_STARTED event, as
committed to master and fixes/33.
See Forum discussion https://forum.mythtv.org/viewtopic.php?f=9&t=5263
I think this was the same problem as what is discussed in this thread.

Klaas.

On 03/02/2023 21:24, Klaas de Waal wrote:
> The REC_PENDING event is now coming before the REC_STARTED event, as
> committed to master and fixes/33.
> See Forum discussion https://forum.mythtv.org/viewtopic.php?f=9&t=5263
> <https://forum.mythtv.org/viewtopic.php?f=9&t=5263>
> I think this was the same problem as what is discussed in this thread.

I'm on fixes/32 so will have to upgrade, but thank you very much for
tracking this down.

_______________________________________________
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

On 04/02/2023 07:27, Jan Ceuleers wrote:
> On 03/02/2023 21:24, Klaas de Waal wrote:
>> The REC_PENDING event is now coming before the REC_STARTED event, as
>> committed to master and fixes/33.
>> See Forum discussion https://forum.mythtv.org/viewtopic.php?f=9&t=5263
>> <https://forum.mythtv.org/viewtopic.php?f=9&t=5263>
>> I think this was the same problem as what is discussed in this thread.
>
> I'm on fixes/32 so will have to upgrade, but thank you very much for
> tracking this down.
>

I upgraded to fixes/33, but I still see the incorrect ordering.

<190>Feb 4 07:50:50 mythtv[2909935]:
/home/mythtv/system-events/recording-started called with parameters 32
20230204075100 by PID 2909935
/home/mythtv/tuner_command[2909943] hdmicap1.xperim.be 121
<190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
with parameters hdmicap1.xperim.be 121 by PID 2909938
/home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
<190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
with parameters hdmicap1.xperim.be 121 by PID 2909938
/home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
<190>Feb 4 07:50:50 mythtv[2909951]:
/home/mythtv/system-events/recording-pending called with parameters 32
20230204075100 -241 by PID 2909951
/home/mythtv/have_video_lock: hdmicap1.xperim.be returns 0
/home/mythtv/start_streaming hdmicap1.xperim.be
/home/mythtv/start_streaming: URL
http://192.168.1.69/dev/info.cgi?action=streaminfo&rtp=on&multicast=on&mcastaddr=192.168.1.60

/home/mythtv/blast_arduino.sh: 1 121
/home/mythtv/tuner_command[2909946]: exit 0

This log is produced by my own scripts, including the recording-pending
and recording-started scripts, as well as various scripts invoked
through mythexternrecorder configuration.

As you can see the recording pending event is fired during the same
second as the recording started event, but later, and with a negative
SECS parameter (-241 in the above example). This log is for a recording
that was due to start (according to the schedule data) at 7:55am, with
zero preroll in the recording rule itself, with RecordPreRoll set to
250, and with WakeUpThreshold set to 5.

Perhaps the fix hasn't made it into the mythbuntu ppa yet; will test
again tomorrow.

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

On 04/02/2023 08:04, Jan Ceuleers wrote:
> I upgraded to fixes/33, but I still see the incorrect ordering.
>
> <190>Feb 4 07:50:50 mythtv[2909935]:
> /home/mythtv/system-events/recording-started called with parameters 32
> 20230204075100 by PID 2909935
> /home/mythtv/tuner_command[2909943] hdmicap1.xperim.be 121
> <190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
> with parameters hdmicap1.xperim.be 121 by PID 2909938
> /home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
> <190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
> with parameters hdmicap1.xperim.be 121 by PID 2909938
> /home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
> <190>Feb 4 07:50:50 mythtv[2909951]:
> /home/mythtv/system-events/recording-pending called with parameters 32
> 20230204075100 -241 by PID 2909951
> /home/mythtv/have_video_lock: hdmicap1.xperim.be returns 0
> /home/mythtv/start_streaming hdmicap1.xperim.be
> /home/mythtv/start_streaming: URL
> http://192.168.1.69/dev/info.cgi?action=streaminfo&rtp=on&multicast=on&mcastaddr=192.168.1.60
>
> /home/mythtv/blast_arduino.sh: 1 121
> /home/mythtv/tuner_command[2909946]: exit 0
>
> This log is produced by my own scripts, including the recording-pending
> and recording-started scripts, as well as various scripts invoked
> through mythexternrecorder configuration.
>
> As you can see the recording pending event is fired during the same
> second as the recording started event, but later, and with a negative
> SECS parameter (-241 in the above example). This log is for a recording
> that was due to start (according to the schedule data) at 7:55am, with
> zero preroll in the recording rule itself, with RecordPreRoll set to
> 250, and with WakeUpThreshold set to 5.
>
> Perhaps the fix hasn't made it into the mythbuntu ppa yet; will test
> again tomorrow.

Klaas,

This problem is not resolved for me. Based on the name of the package
that I now have installed (which includes a git hash) I believe that I
am running with your patch, but I still see out-of-order events very
much like the log I posted yesterday.

Should I open an issue?

root@dracor:~# dpkg -l | grep myth
ii libmyth
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64 Common
library code for MythTV and add-on modules (runtime)
ii libmyth-python
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Python
library to access some MythTV features
ii libmythes-1.2-0:amd64
2:1.2.4-3build1 amd64 simple
thesaurus library
ii libmythtv-perl
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Perl
library to access some MythTV features
rc mythbuntu-bare-client 2.7.2
all Mythbuntu Bare
Client
rc mythbuntu-common 0.78.2
all Mythbuntu
application support functions
rc mythbuntu-control-centre 0.64.1
all Mythbuntu
Configuration Application
ii mythes-en-us
1:6.4.3-1 all English
(USA) Thesaurus for LibreOffice
ii mythtv
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
Personal video recorder application (client and server)
ii mythtv-backend
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
Personal video recorder application (server)
ii mythtv-backend-master
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
Metapackage to setup and configure a "Master Backend" profile of MythTV
ii mythtv-common
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
Personal video recorder application (common data)
ii mythtv-database
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
Personal video recorder application (database)
ii mythtv-frontend
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
Personal video recorder application (client)
ii mythtv-transcode-utils
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
Utilities used for transcoding MythTV tasks
ii mythweb
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Web
interface add-on module for MythTV
ii php-mythtv
2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all PHP
Bindings for MythTV

Note that 761e7b05f7 is the current head in fixes/33.


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

On 05/02/2023 09:25, Jan Ceuleers wrote:

> On 04/02/2023 08:04, Jan Ceuleers wrote:
>> I upgraded to fixes/33, but I still see the incorrect ordering.
>>
>> <190>Feb 4 07:50:50 mythtv[2909935]:
>> /home/mythtv/system-events/recording-started called with parameters 32
>> 20230204075100 by PID 2909935
>> /home/mythtv/tuner_command[2909943] hdmicap1.xperim.be 121
>> <190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
>> with parameters hdmicap1.xperim.be 121 by PID 2909938
>> /home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
>> <190>Feb 4 07:50:50 mythtv[2909938]: /home/mythtv/tuner_command called
>> with parameters hdmicap1.xperim.be 121 by PID 2909938
>> /home/mythtv/tuner_command[2909946] hdmicap1.xperim.be 121
>> <190>Feb 4 07:50:50 mythtv[2909951]:
>> /home/mythtv/system-events/recording-pending called with parameters 32
>> 20230204075100 -241 by PID 2909951
>> /home/mythtv/have_video_lock: hdmicap1.xperim.be returns 0
>> /home/mythtv/start_streaming hdmicap1.xperim.be
>> /home/mythtv/start_streaming: URL
>> http://192.168.1.69/dev/info.cgi?action=streaminfo&rtp=on&multicast=on&mcastaddr=192.168.1.60
>>
>> /home/mythtv/blast_arduino.sh: 1 121
>> /home/mythtv/tuner_command[2909946]: exit 0
>>
>> This log is produced by my own scripts, including the recording-pending
>> and recording-started scripts, as well as various scripts invoked
>> through mythexternrecorder configuration.
>>
>> As you can see the recording pending event is fired during the same
>> second as the recording started event, but later, and with a negative
>> SECS parameter (-241 in the above example). This log is for a recording
>> that was due to start (according to the schedule data) at 7:55am, with
>> zero preroll in the recording rule itself, with RecordPreRoll set to
>> 250, and with WakeUpThreshold set to 5.
>>
>> Perhaps the fix hasn't made it into the mythbuntu ppa yet; will test
>> again tomorrow.
> Klaas,
>
> This problem is not resolved for me. Based on the name of the package
> that I now have installed (which includes a git hash) I believe that I
> am running with your patch, but I still see out-of-order events very
> much like the log I posted yesterday.
>
> Should I open an issue?
>
> root@dracor:~# dpkg -l | grep myth
> ii libmyth
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64 Common
> library code for MythTV and add-on modules (runtime)
> ii libmyth-python
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Python
> library to access some MythTV features
> ii libmythes-1.2-0:amd64
> 2:1.2.4-3build1 amd64 simple
> thesaurus library
> ii libmythtv-perl
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Perl
> library to access some MythTV features
> rc mythbuntu-bare-client 2.7.2
> all Mythbuntu Bare
> Client
> rc mythbuntu-common 0.78.2
> all Mythbuntu
> application support functions
> rc mythbuntu-control-centre 0.64.1
> all Mythbuntu
> Configuration Application
> ii mythes-en-us
> 1:6.4.3-1 all English
> (USA) Thesaurus for LibreOffice
> ii mythtv
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
> Personal video recorder application (client and server)
> ii mythtv-backend
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
> Personal video recorder application (server)
> ii mythtv-backend-master
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
> Metapackage to setup and configure a "Master Backend" profile of MythTV
> ii mythtv-common
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
> Personal video recorder application (common data)
> ii mythtv-database
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all
> Personal video recorder application (database)
> ii mythtv-frontend
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
> Personal video recorder application (client)
> ii mythtv-transcode-utils
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 amd64
> Utilities used for transcoding MythTV tasks
> ii mythweb
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all Web
> interface add-on module for MythTV
> ii php-mythtv
> 2:33.0+fixes.202302042148.761e7b05f7~ubuntu20.04.1 all PHP
> Bindings for MythTV
>
> Note that 761e7b05f7 is the current head in fixes/33.
>
>
> Thanks, Jan


Can you please show us what events you get and in what order without any
other logging so we can see what you mean?


It's possible the mythexternrecorder does things differently and messes
with the timings?


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

On 05/02/2023 12:27, Paul Harrison wrote:
> Can you please show us what events you get and in what order without any
> other logging so we can see what you mean?
>
>
> It's possible the mythexternrecorder does things differently and messes
> with the timings?

Here's an example from earlier today. As you requested I removed all
logging other than the events:

Feb 5 07:55:50 mythtv[1161172]:
/home/mythtv/system-events/recording-started called with parameters 32
20230205075600 by PID 1161172
Feb 5 07:55:55 mythtv[1161379]:
/home/mythtv/system-events/recording-pending called with parameters 32
20230205075600 -246 by PID 1161379

In this instance the recording pending event arrived 5 seconds after the
recording started event, but earlier examples (if you ignore all of the
non-event logging) showed that sometimes the recording pending event
arrives within a second of the recording started event.

In order to test your theory that mythexternrecorder might have
something to do with this I also ran a test recording with an HDHR (i.e.
not using mythexternrecorder). Here are the events:

Feb 5 13:07:50 mythtv[1740022]:
/home/mythtv/system-events/recording-started called with parameters 10
20230205130800 by PID 1740022
Feb 5 13:07:50 mythtv[1740026]:
/home/mythtv/system-events/recording-pending called with parameters 10
20230205130800 -241 by PID 1740026

So the order is the same in this case, although as described earlier the
events are less than a second apart.

Here's how the events have been set up:

mysql> select * from settings where value like "Event%"\G
*************************** 1. row ***************************
value: EventCmdLivetvStarted
data:
hostname: dracor
*************************** 2. row ***************************
value: EventCmdPlayChanged
data:
hostname: dracor
*************************** 3. row ***************************
value: EventCmdRecFinished
data: /home/mythtv/system-events/recording-finished %DIR% %FILE%
%CARDID% %CHANID% %STARTTIMEUTC"
hostname: dracor
*************************** 4. row ***************************
value: EventCmdRecPending
data: /home/mythtv/system-events/recording-pending %CARDID%
%STARTTIME% %SECS%
hostname: dracor
*************************** 5. row ***************************
value: EventCmdRecStarted
data: /home/mythtv/system-events/recording-started %CARDID% %STARTTIME%
hostname: dracor
5 rows in set (0.00 sec)

So as you can see, the "-246" or "-241" passed to recording-pending is
the SECS parameter.

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

Hi Jan,

What are your values for the settings RecordPreRoll and WakeUpThreshold?

The RecordPreRoll is configured in mythfrontend with Setup / Video /
General / General (Advanced) / Time to record before start of show (secs).
In my system the RecordPreRoll is 180 seconds.

I am not aware of a GUI option to configure the value of WakeUpThreshold.
If it is not defined then a default value of 5 minutes is used.
If it is defined directly in the database then I think that the value
should be in seconds.
In my system the WakeUpThreshold is not defined so the default is used.

To show the events you can add the "-v network" option for mythbackend.
Then use "grep -e REC_PENDING -e REC_STARTED" to filter the log.

Thanks,
Klaas.


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

> On 05/02/2023 12:27, Paul Harrison wrote:
> > Can you please show us what events you get and in what order without any
> > other logging so we can see what you mean?
> >
> >
> > It's possible the mythexternrecorder does things differently and messes
> > with the timings?
>
> Here's an example from earlier today. As you requested I removed all
> logging other than the events:
>
> Feb 5 07:55:50 mythtv[1161172]:
> /home/mythtv/system-events/recording-started called with parameters 32
> 20230205075600 by PID 1161172
> Feb 5 07:55:55 mythtv[1161379]:
> /home/mythtv/system-events/recording-pending called with parameters 32
> 20230205075600 -246 by PID 1161379
>
> In this instance the recording pending event arrived 5 seconds after the
> recording started event, but earlier examples (if you ignore all of the
> non-event logging) showed that sometimes the recording pending event
> arrives within a second of the recording started event.
>
> In order to test your theory that mythexternrecorder might have
> something to do with this I also ran a test recording with an HDHR (i.e.
> not using mythexternrecorder). Here are the events:
>
> Feb 5 13:07:50 mythtv[1740022]:
> /home/mythtv/system-events/recording-started called with parameters 10
> 20230205130800 by PID 1740022
> Feb 5 13:07:50 mythtv[1740026]:
> /home/mythtv/system-events/recording-pending called with parameters 10
> 20230205130800 -241 by PID 1740026
>
> So the order is the same in this case, although as described earlier the
> events are less than a second apart.
>
> Here's how the events have been set up:
>
> mysql> select * from settings where value like "Event%"\G
> *************************** 1. row ***************************
> value: EventCmdLivetvStarted
> data:
> hostname: dracor
> *************************** 2. row ***************************
> value: EventCmdPlayChanged
> data:
> hostname: dracor
> *************************** 3. row ***************************
> value: EventCmdRecFinished
> data: /home/mythtv/system-events/recording-finished %DIR% %FILE%
> %CARDID% %CHANID% %STARTTIMEUTC"
> hostname: dracor
> *************************** 4. row ***************************
> value: EventCmdRecPending
> data: /home/mythtv/system-events/recording-pending %CARDID%
> %STARTTIME% %SECS%
> hostname: dracor
> *************************** 5. row ***************************
> value: EventCmdRecStarted
> data: /home/mythtv/system-events/recording-started %CARDID% %STARTTIME%
> hostname: dracor
> 5 rows in set (0.00 sec)
>
> So as you can see, the "-246" or "-241" passed to recording-pending is
> the SECS parameter.
>
> 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
>

On 05/02/2023 14:23, Klaas de Waal wrote:
> Hi Jan,
>
> What are your values for the settings RecordPreRoll andWakeUpThreshold?

From one of my earlier messages today:

"...zero preroll in the recording rule itself, with RecordPreRoll set to
250, and with WakeUpThreshold set to 5."

> To show the events you can add the "-v network" option for mythbackend.
> Then use "grep -e REC_PENDING -e REC_STARTED" to filter the log.

I can do that, but is it needed given the logging I already showed? The
logs I showed are produced by the recording-pending and
recording-started scripts doing the following (and nothing else):

logger --id=$PPID -p local7.info "$0 called with parameters $* by PID
$PPID" -s 2>> /home/mythtv/hdmicap.log

Both scripts are identical and contain only the following line (apart
from the shebang).


ALSO: it occurred to me that perhaps my tests were invalid, in that I
was scheduling "record once" recording rules using mythweb that are due
to start later than the preroll, and I was afraid that perhaps doing so
did not trigger a reschedule or something. So I just did another test,
scheduling the recording 20mins ahead of time and then running mythutil
--resched, but the same still happened:

Feb 5 16:00:50 mythtv[2071521]:
/home/mythtv/system-events/recording-started called with parameters 10
20230205160100 by PID 2071521
Feb 5 16:00:50 mythtv[2071532]:
/home/mythtv/system-events/recording-pending called with parameters 10
20230205160100 -241 by PID 2071532


Anyway, I will do another test run after running mythbackend
--setverbose network .

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

Hi Jan,

About

zero preroll in the recording rule itself, with RecordPreRoll set to
250, and with WakeUpThreshold set to 5.

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?

Thanks,
Klaas.


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

> On 05/02/2023 14:23, Klaas de Waal wrote:
> > Hi Jan,
> >
> > What are your values for the settings RecordPreRoll andWakeUpThreshold?
>
> From one of my earlier messages today:
>
> "...zero preroll in the recording rule itself, with RecordPreRoll set to
> 250, and with WakeUpThreshold set to 5."
>
> > To show the events you can add the "-v network" option for mythbackend.
> > Then use "grep -e REC_PENDING -e REC_STARTED" to filter the log.
>
> I can do that, but is it needed given the logging I already showed? The
> logs I showed are produced by the recording-pending and
> recording-started scripts doing the following (and nothing else):
>
> logger --id=$PPID -p local7.info "$0 called with parameters $* by PID
> $PPID" -s 2>> /home/mythtv/hdmicap.log
>
> Both scripts are identical and contain only the following line (apart
> from the shebang).
>
>
> ALSO: it occurred to me that perhaps my tests were invalid, in that I
> was scheduling "record once" recording rules using mythweb that are due
> to start later than the preroll, and I was afraid that perhaps doing so
> did not trigger a reschedule or something. So I just did another test,
> scheduling the recording 20mins ahead of time and then running mythutil
> --resched, but the same still happened:
>
> Feb 5 16:00:50 mythtv[2071521]:
> /home/mythtv/system-events/recording-started called with parameters 10
> 20230205160100 by PID 2071521
> Feb 5 16:00:50 mythtv[2071532]:
> /home/mythtv/system-events/recording-pending called with parameters 10
> 20230205160100 -241 by PID 2071532
>
>
> Anyway, I will do another test run after running mythbackend
> --setverbose network .
>
> 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
>

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

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

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
>

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

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
>

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

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

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.

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

On 09/02/2023 09:58, Jan Ceuleers wrote:
> 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.
>
Maybe your more complex system has this problem, but I have no such
difficulty with my DVB-T/T2 tuners when using a default recording rule,
2m early 4m late, with EIT data. Most of my recordings are
single-record only, aand back-to-back happens often.

John P

> 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

_______________________________________________
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

On 09/02/2023 12:33, John Pilkington wrote:
>> 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.
>>
> Maybe your more complex system has this problem, but I have no such
> difficulty with my DVB-T/T2 tuners when using a default recording rule,
> 2m early 4m late, with EIT data.  Most of my recordings are
> single-record only, aand back-to-back happens often.

Yes, a multirec-capable tuner (which most DVB-x tuners are) does not
have this problem to the same extent, because they natively support the
concept of multiplexes which MythTV's multirec capability was designed
for. My HDHR DVB-C tuner, for example, also does not, in that it has
multiple virtual tuners available that can be swung into service for the
purpose of back-to-back recordings (or indeed for parallel recordings of
any combination of channels on the same multiplex).

But the encrypted channels my cable company provides need to be accessed
by means of a set-top box, and there is presently no "multirec"
capability for one-channel-at-a-time capture cards.

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

On Thu, 9 Feb 2023 at 13:15, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 09/02/2023 12:33, John Pilkington wrote:
> >> 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.
> >>
> > Maybe your more complex system has this problem, but I have no such
> > difficulty with my DVB-T/T2 tuners when using a default recording rule,
> > 2m early 4m late, with EIT data. Most of my recordings are
> > single-record only, aand back-to-back happens often.
>
> Yes, a multirec-capable tuner (which most DVB-x tuners are) does not
> have this problem to the same extent, because they natively support the
> concept of multiplexes which MythTV's multirec capability was designed
> for. My HDHR DVB-C tuner, for example, also does not, in that it has
> multiple virtual tuners available that can be swung into service for the
> purpose of back-to-back recordings (or indeed for parallel recordings of
> any combination of channels on the same multiplex).
>
> But the encrypted channels my cable company provides need to be accessed
> by means of a set-top box, and there is presently no "multirec"
> capability for one-channel-at-a-time capture cards.
>
> Cheers, Jan
>
> I have just now created a pull request #716 (
https://github.com/MythTV/mythtv/pull/716) with a fix that does solve the
REC_PENDING event issue in my testing.

Klaas.

On Thu, Feb 09, 2023 at 10:58:28AM +0100, Jan Ceuleers wrote:
> 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).

We settled on the following terminolgoy long ago, to avoid this
confusion.

Start early and end late are options in every recording rule. They
are specified in minutes and are intended for cases where the probram
is expceted to or might begin early or run long. The scheduler will
attempt work around these constrains by moving recordings to later of
lower priority tuners to honor the full recording time. In cases
where the full recording time can't be honored, the scheduler will
report a conflict so the user can make the best informed decision on
what to do.

Pre foll and post roll, are global options. They are specified in
seconds and are intended to setup and tead down tuners if the tuner is
not already busy. They are entirely optional and are not guaranteed
to be used. This is what I contend is misused by many people as a
scheduling feature.

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

This is what doesn't compute for me. Users say they absolutely have
to have this feature because their guide data is inaccurate and
without it, they'll miss the beginnings or ends of their shows. Yet,
there's no guarantee this feature will kick in so they still miss
parts of their shows. Then they go one step further and say without
it being optional , they can't schedule show back to back which,
again, will miss parts of their shows.

Why not use the necessary padding in the first place? In the case
where there is a conflict, then you can make the choice of which part
of which show to miss that best fits your needs. Admittedly, MythTV
doesn't do as good of a job of notifying about conflicts as it should.
I've got an incomplete patch that remedies that.

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

Recording, rule templates already make it easy to apply custom,
defaults to all new rules. It wouldn't be hard to add the ability to
optionally apply template changes to all rules.

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

I don't fully understand your point here. However, I have two
comments that might address it.

First, a former developer added a hack long, long ago (yes, this same
discussion has benn going on nearyly 20 years) to quell the masses.
It intentionally avoids putting incompatible recordings back to back
except when it has to be done to avoid conflicts.

Second, MythTV has had the ability for a couple of years now to create
virtual tuners as needed to support overlapping recordings on the same
channel or multiplex. It currently only kicks in for hard overlaps
but would be trivial to extend for back to back recordings too.

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

That's exactly my point from a above about not making sense. Only you
can make the best decision for your cases. Why do you want to let
MythTV essentially make a random decision?

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

On Fri, 10 Feb 2023 17:50:40 -0600, you wrote:

>On Thu, Feb 09, 2023 at 10:58:28AM +0100, Jan Ceuleers wrote:
>> 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).
>
>We settled on the following terminolgoy long ago, to avoid this
>confusion.
>
>Start early and end late are options in every recording rule. They
>are specified in minutes and are intended for cases where the probram
>is expceted to or might begin early or run long. The scheduler will
>attempt work around these constrains by moving recordings to later of
>lower priority tuners to honor the full recording time. In cases
>where the full recording time can't be honored, the scheduler will
>report a conflict so the user can make the best informed decision on
>what to do.
>
>Pre foll and post roll, are global options. They are specified in
>seconds and are intended to setup and tead down tuners if the tuner is
>not already busy. They are entirely optional and are not guaranteed
>to be used. This is what I contend is misused by many people as a
>scheduling feature.
>
>> 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.
>
>This is what doesn't compute for me. Users say they absolutely have
>to have this feature because their guide data is inaccurate and
>without it, they'll miss the beginnings or ends of their shows. Yet,
>there's no guarantee this feature will kick in so they still miss
>parts of their shows. Then they go one step further and say without
>it being optional , they can't schedule show back to back which,
>again, will miss parts of their shows.
>
>Why not use the necessary padding in the first place? In the case
>where there is a conflict, then you can make the choice of which part
>of which show to miss that best fits your needs. Admittedly, MythTV
>doesn't do as good of a job of notifying about conflicts as it should.
>I've got an incomplete patch that remedies that.
>
>> 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.
>
>Recording, rule templates already make it easy to apply custom,
>defaults to all new rules. It wouldn't be hard to add the ability to
>optionally apply template changes to all rules.
>
>> 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.
>
>I don't fully understand your point here. However, I have two
>comments that might address it.
>
>First, a former developer added a hack long, long ago (yes, this same
>discussion has benn going on nearyly 20 years) to quell the masses.
>It intentionally avoids putting incompatible recordings back to back
>except when it has to be done to avoid conflicts.
>
>Second, MythTV has had the ability for a couple of years now to create
>virtual tuners as needed to support overlapping recordings on the same
>channel or multiplex. It currently only kicks in for hard overlaps
>but would be trivial to extend for back to back recordings too.
>
>> >> 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.
>
>That's exactly my point from a above about not making sense. Only you
>can make the best decision for your cases. Why do you want to let
>MythTV essentially make a random decision?
>
>David

When you are using tuners that do multirec and automatically overlap
back-to-back recordings, then using the start early and end late
options in the recording rule works well. That is what I do. But
back when I had to record from a set top box using a single analogue
tuner, that would not work because the tuner could not do multirec at
all. So in that case, the fact that the global pre- and post-roll
settings are not used for back-to-back recordings was the thing that
made it possible to record that way. You did run into the situation
where the beginning of one program was recorded on the end of the
previous program, but you just learned to live with that and
remembered to not delete the previous program until you had watched
the bit on the end of it. So my guess is that Jan is in the same
situation now, and what he really needs is the ability to set the
number of virtual tuners to 2 and have his single tuners do overlapped
recordings when they are back-to-back. If he had that, then he could
then just use the normal start early and end late settings. I do not
know what sort of tuners Jan is using, and it is actually possible
that they do now support that limited multirec mode. It was added to
a number of tuners a long time ago and it is what I have been using
with my IPTV tuners for a long time now.
_______________________________________________
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

On 11/02/2023 04:03, Stephen Worthington wrote:
> When you are using tuners that do multirec and automatically overlap
> back-to-back recordings, then using the start early and end late
> options in the recording rule works well. That is what I do. But
> back when I had to record from a set top box using a single analogue
> tuner, that would not work because the tuner could not do multirec at
> all. So in that case, the fact that the global pre- and post-roll
> settings are not used for back-to-back recordings was the thing that
> made it possible to record that way. You did run into the situation
> where the beginning of one program was recorded on the end of the
> previous program, but you just learned to live with that and
> remembered to not delete the previous program until you had watched
> the bit on the end of it. So my guess is that Jan is in the same
> situation now, and what he really needs is the ability to set the
> number of virtual tuners to 2 and have his single tuners do overlapped
> recordings when they are back-to-back. If he had that, then he could
> then just use the normal start early and end late settings. I do not
> know what sort of tuners Jan is using, and it is actually possible
> that they do now support that limited multirec mode. It was added to
> a number of tuners a long time ago and it is what I have been using
> with my IPTV tuners for a long time now.

Stephen's interpretation of what I was saying was right.

But David was also right in that I wasn't aware that the new
mythexternrecorder-based capture cards I am now using are in fact
capable of multirec. So the "dream feature" I described in my previous
post is in fact already available, and I hadn't noticed. Thank you!!

So I will pivot back to using start early/end late.

Thanks to all, particularly to Klaas for fixing the problem I reported.

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

On Thu, Feb 9, 2023 at 3:10 AM David Engel <david@istwok.net> 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?" :)


I thought that was "Just avoid holding it in that way",
commonly reported as "You're holding it wrong".



However, more to the point, I am going to add something
that may be somewhat controversial, but I do believe
that you should over-provision the number of tuners so
that conflicts are minimal and the scheduler does not
need to make hard (or impossible) decisions.

To paraphrase Ms. Simpson: "You can never be too rich, or too thin, or
have too many tuners"

Yes, I do understand there are sometimes other
constraints (tuners cost money, slots may be
limited), but sooner or later you are going to find
that if you run too hot (using all tuners almost all
the time) something will not be able to be
recorded (the scheduler is very good, but it
cannot create time[0]). Some networks and
stations intentionally shift the show time by a few
minutes to discourage channel surfing. Some
seem to do it because they are unable to set their
clocks accurately (maybe they should hire
a few train conductors?). But no matter the
cause, overlaps happen that can require more
tuners than one might otherwise wish to own,
but your wishes are not relevant to the stations.

In my location, at the beginning of the new
TV season, I often schedule recordings of
a lot of the new series that seem like they might
have promise. And while I typically decide
most of those shows are not worth continuing
to watch, and cancel the recordings, during
those first few weeks I can easily find I need at
least five physical tuners (even with virtual and
sub-channel tuning capability), although I would
otherwise rarely be using more than three
(and usually just one or two). For the record,
I have six tuners.

So, to Steve Jobs it, "Just buy more tuners!"





[0] I have no doubt creating (free) time is on
the wish list of many.
_______________________________________________
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

On 09/02/2023 22:26, Klaas de Waal wrote:
> I have just now created a pull request #716
> (https://github.com/MythTV/mythtv/pull/716
> <https://github.com/MythTV/mythtv/pull/716>) with a fix that does solve
> the REC_PENDING event issue in my testing.

Hi Klaas.

Thanks again for doing this work.

I see that the patch is still under review though. Any updates?

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

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

> On 09/02/2023 22:26, Klaas de Waal wrote:
> > I have just now created a pull request #716
> > (https://github.com/MythTV/mythtv/pull/716
> > <https://github.com/MythTV/mythtv/pull/716>) with a fix that does solve
> > the REC_PENDING event issue in my testing.
>
> Hi Klaas.
>
> Thanks again for doing this work.
>
> I see that the patch is still under review though. Any updates?
>
> Hi Jan,

I did not get any review comments so I concluded that everybody was happy
with the changes.
I have committed it to master, then two days later to fixes/33 and then
closed the pull request.
So it should just work now if you update to the latest, either fixes/33 or
master.

Thanks for reporting and testing,
Klaas.

On 17/02/2023 17:55, Klaas de Waal wrote:
> I have committed it to master, then two days later to fixes/33 and then
> closed the pull request.
> So it should just work now if you update to the latest, either fixes/33
> or master.

I'm on fixes/33 and have updated to the latest mythbuntu packages, and I
do now indeed get REC_PENDING events at 120s, 90s, 60s and 30s before
recordings, so I no longer need to delay my channel changes.

Thanks again.

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

On 25/01/2023 20:31, Hika van den Hoven wrote:
> If you wait a few months, I'll publish my management application.

Hika,

I ended up not waiting; see the wiki article I posted earlier today for
a description of what I did. See the "saving power" section and the
hcpow.sh script.

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

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

Hoi Jan,

Saturday, February 18, 2023, 7:16:14 PM, you wrote:

> On 25/01/2023 20:31, Hika van den Hoven wrote:
>> If you wait a few months, I'll publish my management application.

> Hika,

> I ended up not waiting; see the wiki article I posted earlier today for
> a description of what I did. See the "saving power" section and the
> hcpow.sh script.

> https://www.mythtv.org/wiki/Recording_from_HDMI

> HTH, Jan

I followed the whole discussion with much interest.



Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
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