[mythtv] More scheduling scheduler

[William Uther]

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           :-}