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

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

    > Date: Mon, 20 Apr 2009 01:58:53 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > <keeping it short so I'm not accused of berating you>

Oh, I don't think a long message is berating me.  It's what you say,
not at what length you say it.  [But please see my reply to Robert.]

[I mean, my god, if sheer length = beratedness, every damned message
I send would be berating, right?  We all know I'm a wordy SOB. :) ]

    > On 04/20/2009 01:52 AM, f-myth-users at media.mit.edu wrote:
    > > I already -said- that I manually padded -everything- to some degree.
    > > I'm saying that this solution is insufficient.  To put this more clearly:

    > Which means /you/ agreed to all the consequences involved with 
    > overlapping start/end times.  If Myth unilaterally messes with 
    > already-properly-aligned (though perhaps inaccurate) start/end times, it 
    > will cause conflicts for poor unsuspecting users who don't have as many 
    > tuners as you.

Yes, it will.  I debated suggesting that this behavior be configurable,
but assumed that it would unleash a whole different can of worms, because
I'm well aware of the unpopularity of adding yet another option to Myth's
already baroque configuration.

[I still think that adding such an option would solve the most
-technical- problems, but whether it's worth adding an item to the
documentation and fielding support questions about it is a separate
question.]

    > People are already upset enough that they have to manually do start 
    > early/end late to account for overlaps caused by some stations starting 
    > or ending a minute or two later than other stations.  If Myth just adds 
    > extra time to the /displayed/ start and end times, it will upset a lot 
    > more people.

I wish I could think of a clean way to indicate that the claimed
runtime doesn't match the scheduled slot, but it seems that it would
clutter the interface quite a bit in many places.  [The invasiveness
of adding it to every theme, plus MythWeb, was one of the reasons I
suggested this be made automatic, but OTOH, it's only code and if it's
sort-of boilerplate to add it to everything...]

    > IMHO, the only patch that should be considered is one that stores the 
    > runtime in the DB and displays it for the user to see when choosing 
    > appropriate start early/end late times.

If a patch implementing this has some nontrivial chance of being
accepted, then that's what I'll write.  It's certainly the only clean
way I can see of even making the data available to any other attempts
to cope with the problem.  Would it be presumptious to assume that I
can call the column "runtime" without colliding with anyone's plans?

I never use the frontend to schedule, so I won't try to include any
interactions with themes to provide the new information.  I do use
MythWeb, but I haven't studied that section of its code carefully,
and I'm presuming that xris (I'm guessing?) could knock this out in
a line or two of code, if he were so inclined.  [If so, my suggestion
would be to put runTime in any screen the user might be actually using
to schedule from, and to make it RED iff runTime exceeds the scheduled
slot.  Red isn't great for colorblind people, but I think seriously
suggesting the <blink> tag would get me exiled from civil society,
and rightly so.  Some solution that doesn't also involve the user
having to do mental arithmetic might be nice, too, like:
  "runtime: 134m <red>(15m longer than slot!)</red>
and yes that HTML is obviously 100% bogus.]

I am concerned, however, that only -displaying- this information is
insufficient in the face of movies recorded via a Power Search or
other rule, because in that case the user never actually sees the
display (unless he goes looking) and hence won't see the called-out
mismatch.  I can't immediately see how such a rule could specify
additional padding -only if- runTime was too large, since as far
as I'm aware how the recording gets padded is outside the scope
of what the rule itself can express.  I'm likely missing something
here---if there's some way to write such a rule, I'd feel better
about the notify-only approach.  [If there was some way to avoid
hairing up -every- movie rule written to deal with this corner case,
that'd be even better---that's why I suggested doing so automatically
and would support even a user-settable parameter as an alternative,
despite the documentation/support hair that adding parameters can
involve.]

Thanks again.