[mythtv-users] Events at the beginning of a recording

[Jan Ceuleers]

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