[mythtv-users] Inconsistent treatment of starttime/endtime vs runtime

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

    > Date: Sun, 12 Apr 2009 00:29:56 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 04/12/2009 12:07 AM, f-myth-users at media.mit.edu wrote:
    > > [Should this be on -dev?]

    > IMHO, no.

No offense, Mike, but I think I'd really like to hear what a -developer-
thinks of this idea.  That's why I wondered whether I should be
starting off on -dev.  There are several reasons why a developer's
opinion would be the most valuable, all of which I thought would be
obvious enough, but let me explain, just so we're crystal clear here.

The most important reason I'd like to hear from a developer is because
any potential solution I (or they) might come up with is much more
valuable if it is not restricted to a private ugly hack that only
I run.  I am obviously not the only user to see inconsistent data.

The secondary reason I'd like to hear from a developer concerns the
multiplicity of possible scenarios available to deal with this issue.
I'd like to figure out which branch we're going down so I don't waste
my time on an unproductive one.  I list them below, with the outcomes
I like best listed first.

(a) Developer agrees this is a bug and should somehow be fixed:
    (1) He writes a patch.
    (2) He gives me hints on how I could write a patch he can then
        modify (if necessary) for application to trunk and/or 21-fixes.
    (3) He at least specifies which of several possible solutions
        would be most likely to get committed, so whatever solution
        -I- come up with at least won't be a total waste of my time
        (e.g., likely to require re-fixing when I upgrade).
(b) Developer disagrees that this is even a bug.
    (1) I come up with some kluge, confident at least that, no matter
        how ugly and horrible it is, at least it's the best I could
        do and I'm not just wasting my time fixing soemthing that will
        be fixed in a different manner later.  I solve my problem, but
        everyone else continues to trip over the same problem.
    (2) I give up.  I get screwed by the bug, and so does everyone else.

[I'm saying "he" above because AFAIK none of our devos are female.]

The best solution I can see involves silently extending the endtime of
a program with an endtime/runtime inconsistency to be the max of both
possible endtimes.  I don't know how this will interact with the rest
of the scheduler.  In particular, will the scheduler become confused
if two programs appear to overlap?  It seems like it shouldn't,
because then any sort of pre- or post-roll hard padding of any sort
should trip it up.  But maybe it handles that in some special way
that leaves it less confused than if the programs themselves
overlapped.

I also don't know which of the two possible sets of data Mythweb would
use and thus whether it would become confused as well.  Or where else
in the codebase this might cascade problems into.

Another solution might be to take any hard padding already associated
with the program and add the inconsistency to it.  If the program is
already padded, it will be padded some more.  If it's not, it will be
padded by the degree of inconsistency.  If the user is scheduling this
as a one-off (e.g., he didn't already have a rule for it and is now
just adding one), he'll notice the padding and go "hmm" and maybe add
more---especially if we document how this could come about.  There are
some problems here because I doubt that a yet-unscheduled program has
any place to record the padding we'd want to apply, so there may be no
noninvasive way of getting Myth to do this.  (It also seems to require
some sort of Myth-has-already-padded-this flag so repeated runs of
mfdb don't just keep extending the padding, etc.  Ugly all around.)

Another possible solution, which is safer wrt the scheduler but more
invasive everywhere else and much more of a hassle for the user, might
be to notice the discrepancy and set a bit somewhere in, say, the
"program" table that says "this data is inconsistent---warn the user
if he schedules something involving this".  This solution would
necessarily involve lots of various pieces, although an interim
one might be to just set the bit and leave it up to individual users
to work up whatever disgusting kluge they'd like to use (such as
dumping out the scheduler's idea of what it's doing, comparing to
the table, and sending mail/tooting a horn/whatever if the user
schedules that item to record).

[One way of solving this problem would just be to make a separate
"runTime" column in the various relevant tables that -only- contains
the "runTime" data extracted directly from SD data.  It would then be
fairly trivial for anyone to run a tool over the database looking for
mismatches between start/endtimes and runTime, but knowing whether
that's a problem---e.g., whether that particular program is actually
going to be -recorded- and hence whether the inconsistency matters---
is much more of an issue, since that requires asking the scheduler
what it's going to do.  But right now, Myth extracts runTime and then
fumbles it away again, as far as I can tell, never quite storing it
in any non-temporary table.]

An even grosser solution is to manually parse the input datafile used
by mfdb, manually parse the output of the scheduler's upcoming
actions, and manually alert the user if an inconsistent item is
found.  That doesn't require touching myth's code at all, but it
does involve a lot of reinventing of the wheel.

So let's assume that I actually want this bug fixed.  I'd love it if
it was fixed for everyone, but I'd certainly like to see it fixed
for me.  What's the path that's most likely to lead to it getting
fixed for everyone?  What's the path that's most likely to at least
not waste a lot of time?