[mythtv-users] Updating the end time or offset of a recording in progress
mythtv
mythtv at mdabbs.org
Tue Apr 30 19:15:33 UTC 2019
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?
More information about the mythtv-users
mailing list