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

Tue Apr 30 19:22:54 UTC 2019

On 4/30/19 2:15 PM, mythtv wrote:
> On 4/30/19 1:35 PM, mythtv wrote:
>>
>> On 4/30/19 11:01 AM, David Hampton wrote:
>>> On Tue, 2019-04-30 at 09:44 -0500, mythtv wrote:
>>>> On 4/30/19 9:22 AM, Bill Meek wrote:
>>>>> 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. 
>>>> Well, I was hoping calling rescheduleRecordings would help. I 
>>>> thought about editing the rule itself, and I guess that's still a 
>>>> possibility. I wondered about modifying the rule and setting the 
>>>> endOffset back down to zero when the game finally ended. Otherwise 
>>>> that endOffset would always be in effect for every future 
>>>> occurrence. I've actually tried editing the rule over the course of 
>>>> time to set the endOffset and it never seems to stick. My network 
>>>> is notorious for only recording 2.5 hours of 3 hour game, and I've 
>>>> set the offset to 30 minutes but it always reset to 0, and I always 
>>>> thought because its a power rule, that some things just weren't 
>>>> saved correctly. Then again, that rule was created back in 2015. 
>>> As David mentioned earlier, MRE works by creating an override rule 
>>> and them modifying the override. You don't want to modify the 
>>> original series/power rule because that would affect all future 
>>> recordings. I hacked on the MRE code extensively a decade ago, but I 
>>> can't find my changes anywhere now. (My changes also modified the 
>>> database in the pre-API days.) I would be happy to help in any way I 
>>> can, but I don't have many cycles at this point. David 
>> Well, I think I had everything right. I programmatically created a 
>> single override rule, and changed its endOffset a few times (adding 
>> 15 minutes each time). I then saw the override rule in the Recording 
>> Schedules list via mythweb, and it had a green border (assume that 
>> means its currently recording). But the in-progress recording still 
>> stopped at the normal time. Its almost like the endOffset was never 
>> consulted. i.e. The original recording was to end at 9:45pm but the 
>> end offset was 120 minutes. I have a cushion of 5 minutes before and 
>> after each recording, and the recording stopped at 9:50pm. I don't 
>> suppose that cushion is affecting anything???
>>
>> Even this morning, the override was still showing up in the list with 
>> a border. mythweb showed the recording still in progress, but the 
>> status page showed that nothing was being recorded. I restarted the 
>> backend to clear out any confusion.
>>
>> I appreciate you all helping out. I'll keep digging. Maybe the 
>> backend was not in a real happy state with that weird override 
>> hanging around.
>>
>>
> Also, I'm still on Myth 29. Any chance that could be part of the problem?
>
>
Oh, and my latest test failed.

Steps:

1. Call GetRecordSchedule with chanId and startTime set and 
makeOverride=true
2. Because the Id of the returned rule was 0, I call AddRecordSchedule 
and pass it everything from the returned rule except for Type which I 
set to "Override Recording" (because I get a soap error if I don't) and 
endOffset which I add 15 to. I get a valid recordId back from this.

I see the override rule in my list of recording schedules via mythweb, 
but it stops recording at the normal time. (endTime plus 5 minutes of 
cushion).