Ticket #6898: 0--RATIONALE

WHY

These patches implement detection of programs whose broadcaster claims
will overflow their listed timeslot.  This can only work if you're
using Schedules Direct.  They make no actual change to the way
scheduling works at all---they only give information to the user.

Note that, since this just affects the DB and UI (and, in fact, only
MythWeb---there's no implementation for mythfrontend since I never use
that to do scheduling) its impact should be zero if only the DB half
is installed, except for a trivial (~30K in my listings) increase in
the size of the DB.  The UI half only affects the display of the
detailed recording info for a particular recording, whether or not
it's been scheduled to record, and only changes that behavior if it
looks like the recording is going to overflow its timeslot.  This
means, alas, that it won't help you if some recording that will
overflow was found automatically via a Power Search or a normal
scheduling rule, unless for some reason you happen to be looking at
its detailed info anyway.  But it -will- help you if you're scheduling
it by hand, as is likely on a movie channel.

The most important part of the patch is to preserve the incoming data
from SD, so that Myth can use it later in its UI.  Since the data is
preserved in the DB, MySQL queries can also pull it out, independent
of Myth itself.

This ideas was controversial when suggested on the myth lists, but I'm
including this proof-of-concept here so people know what I'm talking
about, in the hopes that at least the code that sticks stuff into the
DB will make it into a release.  These patches certainly won't work
for everyone---I've been told (but have not seen personally) that some
broadcasters sometimes claim outrageously long runtimes (many hours
too long)--but these patches have been saving my bacon for months now
with Sundance, IFC, and TCM, to name a few, all of which tend to very
occasionally air things that are from several minutes to half an hour
(!) longer than their listed timeslot.  Having to add up to half an
hour of postroll just to catch these is ridiculous---it eats up
storage for the 99% of the time when this isn't necessary, and---much
worse---eats up tuners, too, since most movie channels have rather
random start/end times, and excessive padding eats into tuners that
might otherwise be needed to record things from other channels that
tend to start on the hour or half-hour.  And when one's tuners are
actual physical cable boxes feeding analog capture cards---hence
multirec is unavailable---this starts to generate conflicts pretty
fast.  So even though I routinely pad things on movie channels by 5-10
minutes at the end, I've often been screwed by this -still- not being
enough---even though it's usually way too much.  Hence, these patches.

INSTALLATION

This patch does NOT include the necessary modifications to dbcheck.cpp
to change the relevant table schemas!  This is, in part, because any
such stanza would just have to be changed to match the schema current
when the patch is actually applied, if ever.  It must contain the
following MySQL:

ALTER TABLE program ADD COLUMN sd_runtime SMALLINT UNSIGNED DEFAULT '0' NOT NULL;
ALTER TABLE recordedprogram ADD COLUMN sd_runtime SMALLINT UNSIGNED DEFAULT '0' NOT NULL;

WHAT

Four files are attached:

(a) Example data from SD that shows the problem, and some simple shell
    scripting to show how, once the data's in the Myth DB, it can be
    manipulated.
(b) An UNTESTED patch against current SVN (revision 21445).  It's
    untested because I'm not currently running trunk, and didn't
    expect only 72 hours of notice on the feature freeze.  Oh well.
    If this patch isn't immediately closed as a bad idea, I will work
    up a tested and working version for trunk, but I won't waste my
    tiem if somebody closes the ticket and says this will never go in.
    [But if someone does this, I will pout and be quietly sad. :( ]
    I'll probably need some hints for the Ajaxified current MythWeb,
    and perhaps a volunteer for the mythfrontend piece of the UI,
    which I haven't examined at all yet.
(c) A TESTED AND WORKING proof of concept, both for the DB side and
    the UI side, in a very old version of Myth.  I've been using this
    version of the patch for months and it's worked excellently.
(d) A quick explanation of why I'm running an old version.  For people
    who want to make an issue of it (you know who you are), read it.
    For people who don't care, skip it.  It's here to keep people from
    flaming on the mailing list about it and wasting everyone's time.

OTHER NOTES

Note that the MythWeb example I've supplied doesn't add sd_runtime to
the Myth protocol; it just makes direct calls to the DB to get the
info it needs.  I did this to minimize the invasiveness, and because
plenty of other parts of MythWeb in that version do the same thing.
If this actually goes into trunk, and if it's deemed important, it's
straightforward to add sd_runtime to the protocol and have MythWeb get
it that way---but it requires a protocol bump as well, of course.
(I assume that making the frontend know about this requires such an
addition anyway.)