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

Tue Apr 30 19:38:19 UTC 2019

On Tue, Apr 30, 2019 at 02:15:33PM -0500, mythtv wrote:
> 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?

That shouldn't matter.  I don't think the functionality in question
has changed in years.

David
-- 
David Engel
david at istwok.net