[mythtv] More scheduling scheduler

[Paul Andreassen]

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

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

On 19/11/06 03:08, 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.

Well, that's disappointing.

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

I can certainly see that.

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

This I'm a little confused about, because surely it's possible for users
to misapply any MythTV function. Couldn't you equally say
SchedMoveHigher shouldn't exist because it can confuse users, or power
rules, or preroll/postroll, or show-specific padding versus global
padding, or priorities, or, well, anything?

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

That sounds handy. Another feature of Paul's work is notification of the
amount of soft padding in "Upcoming Recordings", including different
colouring when soft padding can't be applied. It'd be nice to keep that,
or the infrastructure that makes it possible.

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

My original patch! Wow. At the time, I was told it was unacceptable for
precisely that reason: because it sat outside the scheduler ("if we want
to support soft scheduling, we should add first class support for it and
not let it just fall out as a result of mis-using pre/post-roll"). If
that objection is gone, what's wrong with the patch?

Regarding allowing us to "experiment:" I'm not sure that's what we need.
The problem for Paul and I hasn't been figuring out how to make soft
padding work better: we've produced quite a number of working versions.
The problem has been how to make it acceptable to MythTV devs.
Unfortunately, this has been something of a moving target, to the point
where we now seem back where we started!

And I don't want to piss you off, but I have to say: I really feel for
Paul, who has jumped through an awful lot of hoops by now. I appreciate
your work, David, and I understand you've generously donated your time
on a feature you personally don't care for. I hope some devs also
understand that Paul has spent a lot of his time complying with various
requirements that turn out to be furphies. Obviously nobody intended
this, but it sucks.

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

Back in 2005, I got the impression that devs would like to get rid of
preroll/postroll altogether. I was certainly told I shouldn't enhance or
fix it, because that would just encourage people to use something the
devs wanted to scale back. Has that attitude changed? Because unless it
has, I can't imagine any softpad solution that could ever be acceptable.

I still have an interest in getting something into the trunk, because I
get mail from Aussie MythTV users about it, and know it's important to
them. Just this week a guy wanted to hire me -- i.e. actually pay money!
-- to port my original patch to v0.20.

Thanks again for your work.

Max.