[mythtv] More scheduling scheduler

[Paul Andreassen]

On Mon, 27 Nov 2006 09:54 am, William Uther wrote:
> On Sun, 19 Nov 2006 02:08 am, David Engel wrote:
> > On Mon, Oct 30, 2006 at 08:09:21AM +1100, Max Barry wrote:
> >> On 30/10/06 03:42, David Engel wrote:
> >>> I apologize, again, for being so unresponsive.  I am currently
> >>> discussing with the other developers what to do with softpadding.
> >>> I'll let you know when we reach a decision.
> >>
> >> Thanks for the update! Look forward to hearing what's up.
> >
> > OK, here's the scoop.  In short, the current softpad approach won't be
> > going into trunk.  The main reason is that nobody wants to support it
> > and be responsible for it.
>
> Fair enough.
>
> > The multi-candidate approach is conceptually a simple extension of the
> > current scheduling algorithm.  This is why I had mild interest in
> > seeing how it would work out.  However, the quadrupling of candidate
> > recordings makes it much harder to follow and explain the results for
> > all but trivial scenarios.  Additionally, many users would probably
> > enable softpadding naively expecting it to solve all of their
> > scheduling issues.  That's not something we want to deal with.
> >
> > I do empathize with you, though, in having to deal with unreliable
> > guide data.  Because of this, I am willing to add some of the
> > softpadding infrastucture into trunk.  Specifically, that would be to
> > add softstart and softend to the PI class and Myth protocol.  I would
> > also make the scheduler account for softend when changing the end time
> > of an in-progress recording.
>
> This would be great.  It would at least make maintaining a separate
> branch much easier.  The extra columns are where the conflicts
> usually arise.
>
> > This won't give you softpadding in trunk, but it will give you a base
> > on which to continue experimenting on your own.  In theory, the
> > protocol compatibility should make it easier for others to try your
> > patches.  If you do experiment on your own, I suggest going back to
> > something along the lines of Max' first attempt.  That was to have a
> > single function add softpads by re-arranging things after the main
> > scheduling was completed.
>
> The current softpad branch actually works really well.  With the
> extra infrastructure you're suggesting it would be much easier to
> keep running that branch.
>
> > Let me know if you would like to go with this scaled back approach of
> > only putting the infrastructure in trunk.
>
> Yes please :).
>
> > Please note that none of
> > this constitutes a promise to add any more to trunk.  Unless you come
> > up with an extremely elegant solution, I expect there will always be
> > resistance to having large number of users doing softpadding.  We feel
> > pretty strongly that most users don't really need it, even if they
> > think they do.
>
> I agree that many countries don't need it.  However, I think most
> people in Australia would find it really useful.  I'd be interested
> in why you think we don't really need it.  We definitely have a
> problem.  What solution would you suggest if not soft padding?
>
> Be well,
>
> Will           :-}

Well, I'm glad people have been using it and get great benefit out of it.

Paul
--