[mythtv] More scheduling scheduler

[Paul Andreassen]

Hi,

I've had the flu, so sorry for the delay in replying.  I've forwarded the last 
two messages because of there importance.

On Sun, 26 Nov 2006 05:49 pm, Paul Andreassen wrote:
> ----------  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.

I guess I should put my hand up for this but I'm not willing to run svn 
versions of MythTV.  An Australian developers willing to do this?

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

What you are talking about is a second scheduler and that isn't going to be 
acceptable to you or I.

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

I could be upset but I'm not.  I'm just disappointed for Australians.  In a 
few years when the broadcasters start messing with programs time around the 
world, a patch will go in.  Thanks David and Barry.

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

I've thought about a manual method.  In the Upcoming recordings screen we 
could fix conflicts by adding a button that drops softpadding progressively 
for a program and reschedule each time.  Very silly.

I've put current patches up at http://members.iinet.net.au/~paulone/mythtv/ 
for 0.20fixes.  softpad-branch.patch has everything in the svn softpad 
branch, and softpad-update.patch has a small change which greatly improve 
scheduling when there are conflicts. softpad-prechannel.patch allows only 
selected channels to be softpadded, very useful to save recording space and 
time.

Thanks,
Paul
--