[mythtv] More scheduling scheduler

[f-myth-users at media.mit.edu]

    > Date: Mon, 17 Apr 2006 20:30:24 +1000
    > From: Paul Andreassen <paulx at andreassen.com.au>

    > > SUGGESTION #3: In "Setup," soft pads should be specified in minutes, not
    > > seconds. Soft pads are "just in case" buffers, for which it's not
    > > important to specify a time that is precise to the second.

    > I believed some people would only require a small pad.  Some set top box take 
    > 10 seconds to change channels and remove their osd.

Certainly when I was trying to do things like this on a TiVo, I wished
I had 30-second granularity (instead of just 1-minute) to try to split
the difference for shows I knew would run only a few seconds long or
start only a few seconds early---a full minute was too long for one
and would chop the beginning off the next, etc.  In Myth, this is
less of an issue only because I can throw extra tuners in the box.
(Eventually, if one tuner can write to multiple streams simultaneously,
this will become even less of an issue, for those cases where two
back-to-back programs are recording on the same channel and each
of them needs some padding due to jitter at the broadcaster.)
OTOH, this might require making the rest of the UI seconds-aware
instead of minutes-aware.

By the way---if we wind up in a situation where doing the right thing
is contingent on "don't bump something to a another tuner" vs "please
bump to record everything I asked for", I'd like to put in a bid for
making this configurable.  Since all of my tuners are identical, I'm
in the "please use as many tuners as you'd like" camp, but I know lots
of people have a rather heterogeneous set and would be in the "please
don't swap between tuners" camp.  I don't know if the current tuner
priorities are sufficient for making this distinction or not.

P.S.  Exactly how many ways -are- there of adding a buffer to the
beginning or end of a recording, in either the existing mechanism
or the one being discussed?  I'm trying to come up with better
terminology, but it would probably help to start with a really
clear listing of what each one does...  (I think better terminology
would also make the discussion and the code easier to follow.  Even
saying "type 1 padding" vs "type 2 padding" might be better, if there
was a single clear and unambiguous table of what those meant...")