[mythtv] More scheduling scheduler

[David Engel]

On Sun, Apr 09, 2006 at 11:31:55PM +1000, Paul Andreassen wrote:
> On Sun, 9 Apr 2006 04:08 pm, David Engel wrote:
> > Here are my initial comments on your patches.
> 
> Thanks for any input.

You're welcome.  I'm glad to see someone pick this up and do the grunt
work.  It's something I'll likely never use, so it's been extremely
low on my TODO list.

> > Don't change the current pre/postroll code.  Some people, including
> > myself, like it the way it is.  If it proves unnecessary, it can be
> > removed later.
> 
> It was only a attempt at simplifying things.  I believe preroll/overtime is 
> for CAM setup on DVB-S, and if it could be scheduled it would help.  What is 
> the else is it used for?

It's used for extremely soft padding.  IOW, do it if possible, but
don't change the scheduling in any way because of it.

> > Remove the softp->recpriority2 stuff.  That was just for proof of
> > concept.  It can be addressed later if needed.
> 
> How would the scheduler then pick the best showing?  Based on length?

There's already recstart comparison in comp_priority.  That should
handle soft starts without any changes.  You should just need to add a
comparison to prefer programs with soft ends.

> > I think your handling of the ChangeRecordingEnd check is incorrect.  I
> > think the best way to handle interaction with that feature is to
> > remember when soft end padding is added and take that into account
> > when needed.  In addition, any soft end padding becomes hard once the
> > recording starts and that needs to be accounted for if the user really
> > does want to change the end time.
> 
> This would require the storing of soft padding, or doing what the comment says 
> and moving it PruneOverlaps.

I think storing the soft end is fine.  You'll probably want it for thw
comp_priority check anyway.

> > Limit your changes to the soft padding feature only.  If you spot
> > non-related problems, address them separately.
> 
> I noticed that retrylist is used low priority to high when searching in 
> MoveHigherRecords.  See patch.

That's on purpose.  The intent is starting with the lowest priority
loser will have the least impact on the highest priority winners
already scheduled.  How well that works in practice is probably
debatable.

I can see, though, how this might not be ideal with soft padding.  I
always expected soft padding would need an extra pass at the end to
add partial padding wherever possible.  For example, say 20 minutes
padding before and after is desired and two programs stop and start 30
minutes apart.  Obviously, they both can't each get the full 20
miniutes.  With the current approach, one would get 20 minutes and the
other wouldn't get any.  An extra pass could give the unused 10
minutes to the program that didn't get any.

David
-- 
David Engel
gigem at comcast.net