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

[David Engel]

On Tue, Apr 30, 2019 at 09:44:21AM -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

Editing the original rule affects the current recordings (unless an
override rule has already been created) and all future recordings.
Creating an override rule (once, with possible multiple edits after
that) only affects the current recording.

> 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

It sound like you created new, override rules.

David

> 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.

-- 
David Engel
david at istwok.net