[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