<div dir="ltr">On Tue, 24 Jan 2023 at 18:02, Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com">jan.ceuleers@gmail.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was wondering whether there is any more documentation about the<br>
recording pending and recording started events than is available on the<br>
wiki (which isn't very much).<br></blockquote><div><br></div><div><div style="font-size:small" class="gmail_default">I'm not sure there is, so you'll have to rely on the wisdom of folks on this list, I think.</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">
I have read that the one envisaged uses of the recording pending event<br>
is for it to trigger e.g. a set-top box being woken up, but for that to<br>
be possible it would have to be triggered before the recording actually<br>
begins, and the beginning of the recording should also wait until the<br>
recording pending script returns.<br></blockquote><div><br></div><div><div style="font-size:small" class="gmail_default">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.</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">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.</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">If you're passing %SECS% as the first parameter to your script, then in the script you can do something like:</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">ME="$(/usr/bin/basename ${0})"</div><div style="font-size:small" class="gmail_default">TIME_SECS=${1}<br></div><div style="font-size:small" class="gmail_default">if [ ${TIME_SECS} -gt 35 ]<br>then<br>  echo "${ME}: time to programme start ${TIME_SECS}; exiting" \<br></div><div style="font-size:small" class="gmail_default">    >> /some/path/recording_pending.log<br>  exit<br>fi<br></div></div><div><div style="font-size:small" class="gmail_default"># put channel change stuff here</div></div><div><br></div><div><div style="font-size:small" class="gmail_default">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.<br></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">
On my backend I'm seeing the opposite: the recording started event<br>
occurs before the recording pending event, and it obviously doesn't wait<br>
for one event to be handled before the next-one begins.<br></blockquote><div><br></div><div style="font-size:small" class="gmail_default">I haven't tried using recording_started, but it seems like it should come after pending to me, so that's a bit odd.</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>