[mythtv] Proposed scheduler patch

[David Engel]

Please note that I am replying to several messages here.

On Thu, Feb 12, 2004 at 12:12:46AM -0800, Mark Chou wrote:
> It's possible that I might have missed it, but is there a functional
> description for this ultimate vision?  Without this shared
> vision/specification it's rather tough to answer your questions....

An ultimate vision?  No.  More like some goals and some ideas for
achieving them.  Here goes.

Goal 1.  Improve the status reporting of the scheduler for things that
have recently been done and things that are currently being done.
This is pretty much done now.

Goal 2.  Simplify the scheduler for its own sake.  A simpler scheduler
should mean fewer bugs and anomalies.

Goal 3.  Simplify the scheduler to allow some of the frequently
requested features to be added.

Main idea.  Switch to a straight forward "priority" based algorithm,
where priority can be defined flexibly to meet the user's wishes.

Planned implementation:

  Sort all potential recordings into priority order.

  Process each potential recording in order.  

    If it can be scheduled without conflicting, mark it as such and
    mark any duplicates as not recording.

    If it can't be scheduled, tey to move already scheduled recordings
    around, within constraints, to allow it to be scheduled.

  Anything left over is a priority casualty.  Mark is as such.

> 1.  Are tuners "ranked?"  Some have expressed that they want programs
> recorded on the "best" tuner while others want to treat all tuners
> equally.  How will this be handled, if at all?

As someone else already mentioned, tuners are currently implicitly
ranked by cardid (lower id is higher rank).  It's probably not too
much of a stretch to allow explicit ranking of tuners.

> 2.  Some have expressed a desire to leave a tuner free for live TV use.
>  Others have mentioned if an (upcoming) recording is contending for a
> tuner is (currently) used for live TV, that the recording be dynamically
> started on a free tuner, if one is available.  And if a free tuner is

I intend to support both by making the definition of priority somewhat
configurable.  For users who want to keep tuner(s) free, preference
will be given to recording on the lowest numbered tuner first.  For
users who want to use all tuners whenever possible, preference will be
given to the earliest recording.

On Thu, Feb 12, 2004 at 08:38:25AM +0000, steve at nexusuk.org wrote:
> of one of the shows so it conflicts with another show, and I haven't 
> already told it which one I want it to record I want it to highlight.

I already said that conflict losers will get highlighted.  It will
even be semi-smart in that a conflict loser will only get highlighted
if no showing of that episode can be recorded

> Maybe it's worth asking on the -users list.  Afterall, if I hadn't pointed 
> out that there was no way to save entries in the tables anymore I wouldn't 
> have found out about the plans until a new version had been released with 
> all the functionality ripped out.

Go for it.  I've been too busy with a new job to pay very close
attention to the -users list lately.

On Thu, Feb 12, 2004 at 03:12:51PM +0000, Steve Davies wrote:
> I now have 2 tuners, and all of those problems evaporate :-)

It's amazing how many problems one more tuner can solve.

> I would propose a compromise... Lose the conflictres* tables, and replace
> with a new conflict resolution button/option. This button will create a
> high-priority single-record entry for the show that is to be overridden.
> As long as the priority is calculated to be higer than all conflicting
> shows (which should be pretty trivial with the current codebase) then the
> conflicting show becomes a "V" rsOverlap, and the singlerecord will
> out-vote all conflicts. This is also easy to un-select, and will be purged
> from the database periodically by mythfilldatabase.

Something like this is eventually going to be added -- probably as a
replacement for the current recordoverrides.  Besides allowing more
fine grained priority control, it will also allow control of start
early/end late and recording profile for individual showings.

This won't be done until after the current scheduler changes though.
In the mean time, I suppose a DoRecord override could be interpreted
as a super-high recpriority to achieve the same result.

On Thu, Feb 12, 2004 at 07:45:05PM +0000, Steve Davies wrote:
> Derek Atkins wrote:
> >The problem, as others have pointed out, is that Myth would rather
> >schedule a program into a subsequent showing rather than onto another
> >card.  OTOH some people do have different types/qualities of card and
> >therefore want real priorities, and want to tell myth whether it's
> >more important to get a show onto a high-quality card or get it recorded
> >ASAP.
> 
> Ah... Now that is a different problem entirely, and I believe that this 
> choice will be available in the new scheduler.

Yes, minus the explicit tuner ranking, at least for the first pass.

On Thu, Feb 12, 2004 at 08:51:03AM -0000, Paul Woodward wrote:
> I have a few questions too:
> 1. Can you specify a particular recording to a card - i.e. if you want
> to record from an external source, can you say which card to use?

No.

> 2. If recording from a DVB card and multiple streams are being decoded,
> could you watch live TV on a card that is currently recording if it's
> tuned to the right multiplex?

I don't know about live TV, but it sounds like there is some work
being done to handle multiplexed programs on DVB.

> 3. Can the scheduler cope with the loss of a remote backend?

Not currently, but it's an area that's going to be looked at.

> 4. (related to 3) Is the scheduling done live or in advance. i.e. does
> it come up with a strategy for recoding programs or does it grab the
> first tuner available for the first and then deal with each scheduled
> recording as it has to.

The scheduling is done in advance.

> 5. On back-to-back recordings will it try to use 2 different tuners or
> is it better to make a single continuous recording and ask the user to
> split it (using the excellent cut screen).

There are too many variables to say definitively if back to back
recordings will be on the same tuner or not.  Unless you have a good
reason not to, choose separate recordings since it gives the scheduler
more flexibility.

> 6. If the backend can't figure out a way to schedule a series of
> programs, could it ask for assistance, and if no response fall back on a
> best effort basis.

Yes, if you consider highlighting the programs that can't be recorded
as asking for assistance.

David
-- 
David Engel
dlengel at attbi.com