[mythtv] Re:Next Scheduler Patch

[David Engel]

Most of my comments are directed to Mark, but since Bruce already
addressed some things, I'm replyint to his message.

On Mon, Mar 01, 2004 at 07:31:09PM -0800, Bruce Markey wrote:
> Mark Chou wrote:
> >such as a flow chart.  The message that came across (whether intended or
> >not) was "It's going to be done our way, take it or leave it."

Again, I apologize if you got that impression.  If I didn't care what
others thought, I wouldn't have bothered posting the patch and asking
for feedback, I would have just committed it.  I also don't think I'm
too proud to abandon an idea if it doesn't pan out.

> >Keep in mind that most people here probably use mythtv (more or less) in
> >a production capacity, and unless one understands how a critical process
> >like multiple tuner conflict resolution works beforehand, there will
> >definitely be a reluctance to try something that's not clearly understood.

Well, I thought I tried a couple of times to explain the ideas I was
planning.  However, since I hadn't coded anything yet, I couldn't be
more specific.  That was the purpose of posting the patch.  It had the
specifics.

I encourage you, or anyone else, to look at the code.  The heart of
the scheduling is done in two small functions (SchedNewRecords and
MoveHigherRecords) and is remarkably simple, IMHO.

> In the new scheduler, all titles are sorted by the total priority
> value. For things that have the same total priority, they are
> sorted by the record type from most specific to least specific
> so that Single recordings will win over Channel or All record
> by default. 

For completeness, here are the actual checks done for the initial sort
and scheduling pass, with a brief rationale.

  Currently recording beats not currently recording -- they're already
  recording, get them out of the way.

  Higher total priority beats lower total priority -- should be
  obvious.

  Future start time beats passed start time -- try to record a
  complete program before a partial one.

  More specific rectype beats less specific rectype -- should be
  intuitive, especially if a user doesn't use priorities at all.

  If both start times have passed, later start time beats earlier
  start time -- try to miss the least amount of time.

  If neither start time has passed, earlier start time beats later
  start time -- should be obvious, if you can record it earlier, why
  wait.

  Lower input id beats higher input id -- users have come to expect
  lower cards to be used first.

  lower record id beats higher record id -- need a tie breaker if
  everything else fails.

> Once the list of title is sorted, the episodes for
> the highest are placed then the next highest and so on. As a
> result, your highest show in a timeslot will go on Alice, the
> next highest on Betty and if there is a third, it would be
> marked "C"onflict on the conflicts page. 

Additionally, if you set the "Reschedule Higher Priorities" option,
the scheduler will make another pass.  All programs that weren't
scheduled (the conflicts) are resorted based on the highest priority
and number of higher priorities they conflict with.  For each one, the
scheduler tries to find other, viable showings of the already
scheduled programs.

> >As a myth user who uses/gets cvs updates at least once every two weeks,
> >quite frankly the change in schedule conflict resolution between myth
> >.12 and myth .13 was jarring, to say the least.  This (unexplained)
> >change just deepens the mystery, without allowing the user to evaluate
> >the potential trade offs a priori.

I have to take some exception with this.  There weren't any scheduling
changes made (at least of substance) during that time.  What did
happen is that the improved status reporting had the (some would say
beneficial) side-effect of showing what the scheduler was actually
going to do if you didn't intervene.

David
-- 
David Engel
gigem at comcast.net