<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 Feb 2023 at 17:19, Klaas de Waal <<a href="mailto:klaas.de.waal@gmail.com">klaas.de.waal@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 13:55, Ian Cameron <<a href="mailto:mkbloke@gmail.com" target="_blank">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 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></div></blockquote><div><br></div><div style="font-size:small" class="gmail_default">Phew!  Thanks.</div><div><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></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></div></blockquote><div><br></div><div style="font-size:small" class="gmail_default">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.<br></div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">Thanks for your ongoing work, on behalf of us users.<br></div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">Cheers, Ian</div><div style="font-size:small" class="gmail_default"><br></div></div></div>