<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Feb 2023 at 13:55, Ian Cameron <<a href="mailto:mkbloke@gmail.com">mkbloke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Feb 2023 at 11:37, Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com" target="_blank">jan.ceuleers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08/02/2023 00:44, David Engel wrote:<br>
>> speak for Klaas but for me that's a little more involved than I want to get<br>
>> into right now.  We just want the scheduler to send out the events in the<br>
>> correct order and at the right times.  The correct behavior appears to be to<br>
>> sent out REC_PENDING events at 120, 90, 60 and 30 seconds before a recording<br>
>> starts, taking any pre-roll into account, and then send a REC_STARTED event<br>
>> when the recording actually starts recording. Any thoughts and how to fix<br>
>> the scheduler to do that correctly?<br>
> <br>
> I see.  Sounds like one more reason, IMO, to kill user-configurable<br>
> pre- and post-roll.  Maybe you all (that's not specifically directed<br>
> at any single person) can appreciate the extra, unnecessary complexity<br>
> that adds.  I'd much rather fix it at 30 seconds or so and add a new<br>
> feature to allow starting some recordings up to so many minutes late.<br>
> Yes, I know that horse has been dead for a long time but I still enjoy<br>
> beating it.  It makes me feel better.<br>
<br>
Please don't. The reason why I use pre-roll (and quite a long-one at<br>
that) is that in this part of the world the guide data is quite<br>
unreliable (meaning that channels see them more as guidelines than as a<br>
commitment to viewers).<br></blockquote><div><br></div><div style="font-size:small">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.<br></div><div style="font-size:small"></div></div></div></blockquote><div> </div><div>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.</div><div><br></div><div>To summarize, I understand that this are the requirements:</div><div>- REC_PENDING always before the REC_STARTED</div><div>- REC_PENDING at 120, 90, 60 and 30 before the start of the recording</div><div>- Start of the recording is the scheduled program start time plus the preroll</div><div>- When a recording is immediately started after scheduling then there is one REC_PENDING event with 0 seconds immediately before the REC_STARTED</div><div><br></div><div>I do have a slightly hacky implementation that does all this, it needs a bit of cleaning up and more testing.</div><div>This is just a fix, not a rewrite/refactoring. That is something we leave for another day.</div><div>I might however make a Github issue for this so that we capture the knowledge and not forget.....</div><div><br></div><div>Klaas.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>