MythTV Official Community Forum

The Pending Recording event exists but (in v32 at least) runs immediately after the Recording Started event. This is too late to do useful things like:
- touch a file on a disk to 'spin it up' before writing starts.
- some require actions on an external tuner box.
This would be more useful if it could be triggered some configurable time before the started event.
Phil

Do you use a global pre roll on all your recordings?

What does this show and
The last one will probably not return a value so will use the default of 5 minutes.

Just wondering if the first one has to be less that the second one, which they are by default, for you to see the events in right order?

Hi Paul,
thanks for the quick reply. However, I have an oddity in this area.
Following migration (ubuntu 14.04 + mthtv 0.27) to new hardware (xubuntu 22.04/myth v32) I changed pre-roll in default recording rule from 240 down to 120. Many rules presumably still have that 240. I'm also unsure where that global pre-roll setting is.
The 'upcoming recordings' page initially shows the start recordings time at 2 mins before scheduled time. It actually starts recording 4 mins before and then switches display to 4 mins before. This is also reflected in the StartTS field in the GetUpcomingList api.
Phil

The global pre-roll is in the TV Setting -> General -> General (Advanced) -> Time to record before start of show (sec) on the frontend. This setting will attempt to start ALL recordings the set amount early.

There is also the setting per recording rule where you can record X number of minutes before the recording scheduled time. I believe this is the preferred method to add pre-roll if you need it and not use the global pre-roll setting. I'm sure someone will put me right if I'm wrong

I think from a quick look at the code the problem is that the sending of the REC_PENDING event does not take into account the global pre-roll setting. If that setting is set to less than 120 second (the default is 0 seconds) then it will work as you want otherwise the event will be sent too late.

The code is here if someone wants to verify/fix the problem
https://github.com/MythTV/mythtv/blame/ ... .cpp#L2547

@paulh it looks to me that your analysis is OK.
In line 2550 then should be replaced by similar to how that is done in lines 2600 and 2613.
Not tested though...

I've done some testing and yes this fix does work. I think also the seconds reported in the event, such as needs possibly to be changed.
This is the time until the scheduled start time of the recording.
The recording will start always 30 seconds early, plus then the preroll setting (here it was 180 seconds) so here it will start at 210 seconds before the scheduled start time.
I think that also here the preroll setting needs to be subtracted and possibly also the 30 seconds to get a realistic number.

Another behavior that is a bit strange is that after the recording is started (the REC_STARTED) event there comes a last REC_PENDING event with a time of 0 seconds. Is this correct or is this a bug?

Thanks for testing

Where does the extra 30 seconds come from. We always start recording 30 seconds early?

I would say it's a bug to send any REC_PENDING after the REC_STARTED but I'm not sure how it is supposed to work. Is the intent to send just one REC_PENDING event or several at 120, 90, 60 and 30 seconds?

The 30 seconds are used to do the actual tuning so that the recording can start at exactly the correct moment.
Question is, should this be taken into account in the number of seconds sent with the REC_PENDING event?
Current users of the REC_PENDING event (if any...) do not expect this so I think it should stay at the number of seconds until the recording starts.

About how often the REC_PENDING should be sent, I think it is the intention of the code to do this at 120, 90, 60 and 30 seconds but it does not do that.
The code for all this is in HandleWakeSlave and this is not called that often/early in my logs. If the HandleWakeSlave is not called then the REC_PENDING event is also not sent.

I can put a tentative fix in master... That will at least fix the preroll.

Do you know when the REC_STARTED event is sent is it when the tuning starts or the actual recording starts?

I don't use these events either but I would think it's better to send the REC_PENDING event early rather than late. I would think the most common use would be to wake some device up before the tuning and recording phase starts.

If you have a fix for the pre-roll then that can only improve the situation so yes go ahead and commit that part if you want.

And the results of some more investigations....

The HandleWakeSlave function in scheduler.cpp, starting around line 2530, is where this starts and this function called quite often.
The loop which tests for 120, 90, 60 and 30 seconds is there to make sure that the REC_PENDING event is sent at most only once per 30 seconds.
This mechanism works OK; the last correct REC_PENDING is sent when there are 29 seconds left and then immediate the ASK_RECORDING starts, as discussed before, and this starts the tuning and the recording.

In this process the recording is identified by a unique key, generated by ProgramInfo::MakeUniqueKey and this key consists of the channel ID plus the recstartts (record start time). This key is used to keep track if a REC_PENDING event has been sent for this recording in each 30 second interval.

Before the recording has started the recstartts is the scheduled start time of the program, excluding the preroll time.

What now happens is that when the recording starts then recstartts is updated with the current time; this effectively subtracts the preroll time.

The next time the HandleWakeSlave function is called the unique key is computed again and for the same recording this key is now different because recstartts has changed. Therefore the logic thinks that this is a new recording for which no REC_PENDING has been sent yet and hence the REC_PENDING Is sent even when the recording has already been started.

Changing the usage of recstartts and MakeUniqueKey is definitely off-limits as these are used extensively in the scheduler and the correct operation of the scheduler does depend on them.

The complete solution is then:
- Take the preroll time into account when determining the moment to send the REC_PENDING, as discussed before
- Subtract the preroll time in the number of seconds in the REC_PENDING message. Tuning will start when this is about 30 seconds so if REC_PENDING is used to power-on a network tuner this should have been done at the first REC_PENDING event.
- Send only the REC_PENDING message if the number of seconds is more than 0. This filters out the incorrect REC_PENDING event that is sent after the recording has started.

A fix is forthcoming.

Fix now in master, commit https://github.com/MythTV/mythtv/commit ... f7f1501e9d

Cool thanks for fixing it properly

I see it's now in fixes/33 also. Unfortunately the PPA's for 33 and 34-pre (master) are currently broken or non existent but will be fixed in the next few days hopefully.

As discussed in the mailing list, the REC_PENDING is still wrong when the recording is scheduled AFTER the start of the program, including preroll. The solutions as implemented only works in case the recording is scheduled BEFORE the start of the program, including preroll.

A fix is forthcoming.

Many thanks to you both.
Phil

I have a follow up question.
My RecordPreRoll is set at 120.
The frontend upcoming recording screen shows recording due to start 2 minutes before scheduled time.
StartTs in the Dvr/GetUpcomingList api shows the same figure, as do the recording rules.

The recordings actually start 4 minutes before, at which time the frontend screen and the api both show 4 minutes before.
What might I have set wrong?
Phil