[mythtv-users] Updating the end time or offset of a recording in progress

[Bill Meek]

On 4/30/19 6:59 AM, mythtv wrote:
> On 4/30/19 6:55 AM, John Pilkington wrote:
>> On 30/04/2019 12:37, mythtv wrote:
>>> On 4/29/19 9:02 PM, mythtv wrote:
>>>> On 4/29/19 8:17 PM, David Engel wrote:
>>>>> On Mon, Apr 29, 2019 at 07:13:27PM -0500, mythtv wrote:
>>>>>> I'm trying to create my own version of Myth Recording Extender but using the Dvr services API instead of directly writing to the DB. I'm 
>>>>>> able to call the GetEncoderList service and determine that an NHL game is being recorded, I can get the status of the game from a website. 
>>>>>> I can get the original recording rule that caused the game to be recorded. What I can't do is to actually extend the recording. I can call 
>>>>>> UpdateRecordSchedule and pass it a new endTime (which only seems to actually work once), or I can give it a new endOffset which seems to 
>>>>>> work multiple times. But I think I have a problem: The recording rule is actually a Power Search and I'm not sure it's actually affecting 
>>>>>> the in-progress recording. When I get the rule from GetRecordSchedule, the actual start and end times are from back when I created the 
>>>>>> rule (back in 2015), so I don't think I'm really getting the right rule. Is there some way within the services to extended an in-progress 
>>>>>> recording? Thanks for any help. 
>>>>> Use Dvr/GetRecordSchedule. Specify the program in quesiton using nChanId and dStartTimeRaw and set bMakeOverride to true. It should 
>>>>> probably aslo work by using nRecordedId but it currently doesn't. That will give a recording rule you can use to call Dvr/AddRecordSchedule 
>>>>> or Dvr/UpdateRecordSchedule. Use the former if nRecordId is 0 and the latter otherwise. David 
>>>> Sorry, I sent the reply to the wrong address. Ok, I've implemented that. I'm not sure if its working but I'll know later in the week.
>>>>
>>>> For now, it looks like the only thing I can adjust is the endOffset, correct? Changing the endTime acts like before, it doesn't seem to 
>>>> stick each time I call GetRecordSchedule and Add/Update, but the endOffset seems to stick. Hopefully that will be enough to advise Myth to 
>>>> keep recording.
>>>>
>>>> Thanks for the help!
>>>>
>>> Well, although it looked as if everything was going swimmingly, it actually failed to continue recording beyond the normal stop time. I 
>>> noticed a service operation called rescheduleRecordings. Do I need to call that any time I make a change to a recording? Or does the 
>>> endOffset of the current recording not get taken into effect? Am I missing anything else?
>>>
>>> I'd like to dig through the code and follow the logic but I don't really know where all of this logic takes place. I know C++, just not Qt. I 
>>> guess I'd need to know where or how the updated recording is being sent to the current in-progress recording, or how the recording knows when 
>>> to stop recording and if/how it can be updated.
>>>
>>> Thanks! I feel like I'm close and would love to revive MRE if possible.
>>>
>>
>> I don't know if this will help in your efforts to automate it, but in the frontend, when a Recording is selected, the Menu key has
>>
>> Recording Options > Edit Recording Schedule > Schedule Options >
>> End Recording X minutes late.
>>
>> This will work while a recording is in progress.
>>
> Thanks, that at least tells me that there's probably a way to do it through the services as well. But that also tells me that updating the 
> endOffset is probably correct but its not taking effect for some reason. Maybe the rescheduleRecordings needs to occur or something. I will play 
> with it some more later today.

I've used Dvr/UpdateRecordSchedule successfully when a certain network has overtime events
that cause following programs to start late (I just extend their EndOffsets.)

I just tested this with a Power Rule. During a +33 minute EndOffset, I changed to
+22 minutes. The recording stopped in +22. Also, I'm modifying the rule itself, not an
override as David mentioned above (need to try that myself.)

UpdateRecordSchedule calls RecordingRule::Save that does ScheduledRecording::RescheduleMatch
so you don't need to do anything to have changes take affect.

-- 
Bill