[mythtv] Re:Proposed scheduler patch

[Paul Woodward]

I have been thinking about this recently, and given the versatility of
Myth there, might not be a 'one size fits all solution'. Would a
possible solution be to externalise the rule set so that users can tweak
recording to their own needs without touching the code?

As a first step I would say we need a flow chart showing all the
decisions involved and all of the external preferences we would like to
impose. Also it would be very good to include proper support in the
scheduler for recording multiple streams from each multiplex in DVB.

As for Mark's points below:
1. tuner ranking - I would say very important, if you have both digital
and analogue cards...

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?
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?
3. Can the scheduler cope with the loss of a remote backend?
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.
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).
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.

Paul

-----Original Message-----
From: mythtv-dev-bounces at mythtv.org
[mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of Mark Chou
Sent: 12 February 2004 08:13
To: mythtv-dev at mythtv.org
Subject: [mythtv] Re:Proposed scheduler patch

David (& others working on multiple tuner conflict resolution),

I've been following this thread with interest, but fundamentally I think
there are implicit, unstated assumptions that is not apparent to
everyone here.  Quite frankly, with all the talk of the conflict
schedule code changing, I for one am no longer sure what the ultimate
"intended" vision for multiple tuner conflict resolution looks like
(from a user perspective).

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

I'll start by bring up some things that are unclear to me at this point
in time regarding multiple tuner scheduling:

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?
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
not available, what then?  On the other hand, some (such as myself) have
also asked why leave a tuner free for live TV at all?

In this thread you mentioned Tivo. The difference between myth and tivo
is that tivo, to the best of my knowledge, doesn't have to deal with
multiple tuners, whereas myth does (local and remote).  Recently, as of
myth 0.13, I feel that myth has moved towards a Tivo scheduling model,
which is not necessarily correct, since that tends rely too much on the
"one tuner" model....

Perhaps someone ought to come up with a straw-man stating how multiple
tuner conflict resolution works, have a thorough discussion on it first,
before we move on to the implementation phase?

====================================================================
David Engel wrote:

I purposely waited until late this evening before replying to see if
anyone else chimed in. No one has. If anyone else feels stronly
about this, now is the time to chime in.




---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 06/02/2004