Pending Recording event
Forum rules
Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.
* One suggestion per thread please. Do not post new suggestions in replies. *
Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.
* One suggestion per thread please. Do not post new suggestions in replies. *
Pending Recording event
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
- 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
Re: Pending Recording event
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?
What does this show
Code: Select all
curl --header Accept:Application/JSON localhost:6544/Myth/GetSetting?HostName=_GLOBAL_\&Key=RecordPreRoll
Code: Select all
curl --header Accept:Application/JSON localhost:6544/Myth/GetSetting?HostName=_GLOBAL_\&Key=WakeUpThreshold
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?
Re: Pending Recording event
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
thanks for the quick reply.
Code: Select all
phil@Fuji:~$ curl --header Accept:Application/JSON 192.168.2.109:6544/Myth/GetSetting?HostName=_GLOBAL_\&Key=RecordPreRoll
{"String": "120"}phil@Fuji:~$
phil@Fuji:~$
phil@Fuji:~$ curl --header Accept:Application/JSON 192.168.2.109:6544/Myth/GetSetting?HostName=_GLOBAL_\&Key=WakeUpThreshold
{"String": ""}phil@Fuji:~$
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
Re: Pending Recording event
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
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
![Wink ;)](./images/smilies/icon_e_wink.gif)
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
Re: Pending Recording event
@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...
In line 2550 then
Code: Select all
if ((secsleft <= kSysEventSecs[i]) &&
Code: Select all
if (((secsleft - prerollseconds) <= kSysEventSecs[i]) &&s
Not tested though...
Re: Pending Recording event
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?
Code: Select all
MythEvent: SYSTEM_EVENT REC_PENDING SECS 240
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?
Re: Pending Recording event
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?
![Smile :)](./images/smilies/icon_e_smile.gif)
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?
Re: Pending Recording event
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.
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.
Re: Pending Recording event
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.
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.
Re: Pending Recording event
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.
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.
Re: Pending Recording event
Fix now in master, commit https://github.com/MythTV/mythtv/commit ... f7f1501e9d
Re: Pending Recording event
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.
![Cool 8-)](./images/smilies/icon_cool.gif)
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.
Re: Pending Recording event
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.
A fix is forthcoming.
Re: Pending Recording event
Many thanks to you both.
Phil
Phil
Re: Pending Recording event
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
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