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

[Ian Cameron]

On Wed, 8 Feb 2023 at 11:37, Jan Ceuleers <jan.ceuleers at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230208/0f6d8733/attachment.htm>