[mythtv] More scheduling scheduler

[Paul Andreassen]

On Fri, 14 Apr 2006 12:32 pm, David Engel wrote:
> On Fri, Apr 14, 2006 at 08:49:18AM +1000, Paul Andreassen wrote:
> > On Fri, 14 Apr 2006 06:24 am, David Engel wrote:
> > > Thanks.  I created a branch called softpad for these changes to go
> > > into.  People who want this feature should help test it out.
> > Are we at this stage already?  Cool.
> I think so.  The core scheduling changes are just an update of the
> previous proof-of-concept.  There are some usability issues (see
> below) which will have to be worked out though.  That's one reason
> this is on a branch.
> Another reason for having a branch is to make it easier for would be
> testers with patchophobia to try it out.  I must add that anyone who
> wants to see this merged into trunk needs to help test it.  Unless
> there's feedback, positive or negative, I will let it die on the vine
> like previous attempts.

If anyone is interested the patch applies to head and is here:
http://svn.mythtv.org/trac/changeset/9707?format=diff&new=9707
It should also be easy to back port to 0.19.

If you try it please post on the user list with any problems it causes.

> > > Don't apply soft padding at the start or end if corresponding hard
> > > padding has already been added.  Hard padding is limited to a
> > > resolution of 1 minute so they can't currently be mixed.
> > I can't see why you can't mix soft and hard padding.  If you take out
> > your test, it should just work.
> Consider the following examples, both of which have SchedSoftEnd set
> to 1200 seconds (20 minutes) and endoffset initially set to 0 minutes.
> Also note the same issues apply to SchedSoftStart and startoffset as
> well.
> A program with softend added is scheduled to end at 9:20.  The user
> thinks that might not be late enough and changes endoffset to 15
> minutes.  There happens to be another program scheduled to record at
> 9:30 and it can't be moved.  Since the softend can no longer be
> applied, the scheduler changes recendts to 9:15.
> A program without softend added is scheduled to end at 9:00.  Again,
> the user wants more time and changes endoffset to 15.  That bumps a
> program scheduled to start at 9:00 to some other place or time.
> Softend can now be added so the scheduler changes recendts to 9:35.
> In both examples, the resulting recendts is nonintuitive.

These are intuitive to me but I guess I know more of what is going on behind 
the scenes.

Also these examples are exactly what the 'no scheduling' preroll/overtime does 
now, without any feedback to the user.

The user could well have meant to do both these things and if not, based on 
the feedback from the scheduler could decide against his changes.

This is how I record programs.  I use a softstart of 5 minutes, because I set 
Jump Amount to 5 minutes, and a softend of 10minutes.  For most programs this 
is enough but for two late night programs I need more, so I add 10 minutes of 
endoffset, which is 5 minutes before and 20 minutes after a program.

> OK, the obvious solution is to automatically absorb softend into
> endoffset when the recording rule is edited.  That presents new
> problems.
> First, say the user goes to edit something else about a recurring rule
> and they access it through the EPG.  If that showing happened to have
> softend added, they've now inadvertantly added that softend into the
> endoffset for that rule.  The only way to not do this would be to
> access the rule through the Set Priorities screen since it doesn't
> have specific showings tied to recurring rules.
> FYI, this is why the ability to change the end time of an in-progress
> recording has a separate button for doing that.  It creates a
> kOverride rule on the fly as needed so this won't happen.
> Second, endoffset might get adjusted every time the rule is edited.
> In other words, endoffset could keep growing higher and higher.

This is very weird idea.

> In the end, I think the simplest, most deterministic thing to do is
> not add softend when endoffset is non-zero.  The rationale is that if
> the user went to the trouble of specifying endoffset, they probably
> had a reason and that should be the exact end time.

My understanding was the soft padding would be added if it could be.  No 
matter if the endoffset was in effect or not.

Paul
--