[mythtv] support for broadcasters that don't keep to schedule

[Peter Schachte]

Hi Mythologists,

There has been some discussion recently on the users list, and I
gather here as well, of changes to myth to make it better handle
broadcasters that don't keep to their schedules.  One proposed
approach was to make the pre-roll/post-roll feature more configurable
so it could fill that role, but I understand this approach was not
supported by the developers.

I've found that Myth's start early and end late feature works quite
well to handle this, but that it's not currently very convenient for
heavy use.  So it's occurred to me that a few separate changes, listed
below, could make this about as convenient as possible (short of
educating the broadcasters about punctuality).  My questions for this
list are:  can you foresee any snags with any of these changes, and
would they be accepted into Myth?

Here are the proposed changes:

    1)	Allow configuration of global default start early and end
	late values.  Newly scheduled recordings would get these values
	by default, but of course they would be changeable.  Better
	still would be to allow these values to be specified per
	channel, since some channels are more punctual than others.
	The problems with that are that it's more complex, and not all
	recording schedules specify a channel (eg, "any time on any
	channel"), so I'm just suggesting a global setting.

    2)	Allow myth to record program data into two (or more) files at
	once.  When the start early time of one program arrives while
	another is already recording on the same channel and tuner,
	open the recording file for the second and start writing every
	byte from the tuner into both files.  When the end late time
	of the first program arrives, close the first file and
	continue writing only to the second file.  Then modify the
	scheduler to know that multiple programs at the same time on
	the same channel and tuner are not in conflict.  When two
	programed recordings on the same channel overlap (presumably
	due to start early/end late), the scheduler should then
	*prefer* to schedule them on the same tuner, since it
	minimizes the number of tuners in use, and probably the
	processing cost.  (I wonder if this might not be a first
	step toward recording multiple simultaneous programs on the
	same DVB transport using a single tuner?)

    3)	In the "upcoming recordings" list, highlight programs that are
	conflicting only because of start early and end late settings
	in some way that distinguishes then from conflicts of the
	programs themselves.  Provide a key binding and menu item that
	will immediately override the schedule removing enough of the
	start early and end late values so the recordings do not
	conflict.  Also have a different highlight for programs that
	are scheduled to record, but have had their start early/end
	late settings overridden, and have a key/menu item to remove
	those overrides.  This would make it easy to see the state and
	to toggle the override on and off.

    4)	Provide a global configuration setting that would allow
	automatic overriding of start early and end late values
	similarly to what item (3) does manually.  The options for
	when to automatically override would be:

	    A)	Never (the default)
	    B)	Whenever it would allow a program to be scheduled that
		otherwise couldn't
	    C)	Whenever there's an overlap of start early/end late.

	Of course, if start early/end late are automatically
	overridden, the user can still undo the override (more easily
	if (3) is implemented).  What worries me about this one is how
	to keep the scheduler from re-applying the automatic override
	after the user has manually removed it.

Each of these changes is largely independent of the others, and all of
them leave users in full control over each program's start early and
end late settings.  They all just make it a bit more convenient to do
what users can already do.

I'm interested in implementing these changes, particularly #2, if they
look like they'd be accepted into Myth.  I'd appreciate any pointers
you're willing to give me to the places in the code that need
modifying.

Sorry this is so long, and thanks for reading it.

-- 
Peter Schachte              If you have a procedure with 10 parameters, you
schachte at cs.mu.OZ.AU        probably missed some.
www.cs.mu.oz.au/~schachte/      -- Alan Perlis 
Phone: +61 3 8344 1338