[mythtv] More scheduling scheduler

[Paul Andreassen]

----------  Forwarded Message  ----------

Subject: Re: softpad
Date: Sun, 19 Nov 2006 02:08 am
From: David Engel <gigem at comcast.net>
To: Max Barry <mythtv at maxbarry.com>, Paul Andreassen <paulx at andreassen.com.au>

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.

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 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.

Let me know if you would like to go with this scaled back approach of
only putting the infrastructure in trunk.  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.

David
--
David Engel
gigem at comcast.net

-------------------------------------------------------

--