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

David Hampton mythtv at love2code.net
Tue Apr 30 16:01:39 UTC 2019


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




More information about the mythtv-users mailing list