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

mythtv mythtv at mdabbs.org
Tue Apr 30 18:35:58 UTC 2019


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.





More information about the mythtv-users mailing list