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

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

    > Date: Tue, 21 Apr 2009 00:11:44 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

First off---thank you for spending the time here.  I do appreciate it.    

    > a) The <runTime> element is only included in MV* (movie) <program> elements.

Yes, as I said in my original report, I was only talking about movies.

    > b) The same <program> element is referenced in multiple <schedule> 
    > elements--regardless of the starttime and duration of those scheduled 
    > airings of the movie.

Yes, of course.  But I am not sure how this is relevant.  For any
given starttime, endtime, and runTime, Myth has all the data it needs
to compute whether the runTime exceeds the difference of the starttime
and endtime.  [You may argue that Myth might err in assuming that it's
necessarily the runTime that's wrong, but that's a different argument.
It certainly has enough information to deduce that something fishy may
be going on.]

    > And--though I have not yet confirmed this by having someone with access 
    > to the data definition for the TMS DD-format raw data--I'm almost 100% 
    > positive that the <runTime> is the original runtime of the movie as 
    > released.  It does /not/ take into account the "This movie has been 
    > edited to fit your screen *and to run in the time allotted*."

I am also not sure how this is relevant, for two reasons:
(a) In 100% of the cases in which I've been burned, the runTime
    exceeded the (endtime - starttime) difference.  [This ignores
    burns where the problem was clock skew; that's out of scope for
    what I'm trying to fix.]
(b) The movie channels I've had the problems with do not edit for
    content or runtime.  [Or, as you so courteously put it on IRC,
    ``yeah, he'll say, "Well, you might have OTA only, but I have
    movie channels where they air the original movie, so it still
    applies..."'' which is not too hard a prediction since my original
    mail -said- I'd seen this behavior on at least TCM and Sundance,
    both of which are movie channels.]

Because of (a), it seems that Myth could alert the user and/or take
corrective action of some sort.  I assume your concern is that movies
airing on stations where they've been cut to ribbons will thus have
runtimes that far exceed their allotted time on the schedule, and thus
doing max(runtime, (endtime - starttime)) will needlessly pad the
recording in these cases.  There's a good chance of that.

But, to take one of your examples:
    
    > <title>I Still Know What You Did Last Summer</title>
    > <runTime>PT01H41M</runTime>
    > http://www.imdb.com/title/tt0130018/ states Runtime: 100min

...I can't tell whether the actual scheduled time for the showing in
your lineup was less than, equal to, or greater than 1h41m.  In my
case, rarely but with nonzero probability, I see runTimes that exceed
scheduled slots -and the runTime was right-, e.g., the SD data about
when the showing was to end was incorrect.  Often, the channel's
website repeats the mistake, as I mentioned in my first mail,
typically claiming a 130m movie in a 120m slot, etc.

It really doesn't matter what IMDB thinks about it, of course,
since Myth isn't getting that data when it's getting program
information.

    > Yeah, they're not all exact, but it's enough to convince me (especially 
    > considering that the imdb data is just contributed by users).  I can 
    > keep going, if you need more proof--and, of course, if you need me to 
    > continue doing the research you should have done yourself

What research, exactly, do you think I should have done?  You've
compared runTime program elements with IMDB runtimes.  That wasn't
what I was talking about.

The research I -thought- I was doing was asking, "If I were to write
a patch to fix this, which direction is most likely to be committed?"
That pretty much requires asking -somebody-, because it's a judgment call.

    > 							      before riling 
    > up the -users and getting the mob to cry out for implementing these 
    > changes to fix a "bug" in Myth.

"Riling"?  "Mob"?  To my understanding, there have been precisely
three other people involved in this discussion besides you and me:
(a) Robert, who has stalwartly defended you against a slight I had no
    intention of making, and
(b) two other "ordinary users" (I presume) who have -both- stated (one
    repeatedly) that they think you misunderstand what I was trying to
    say.
[Oh wait, latebreaking news:  Nick's definition of runTime.  So four.]

If that's a riled-up mob, I'd hate to know what you think of the
incessant discussions about top-vs-bottom posting.

    > Note, also, that these same <program> elements that contain the 
    > <runTime> element list "<advisory>Nudity</advisory>" for many of the 
    > movies shown in my listings.  However, as I get /only/ OTA broadcasts in 
    > the US, none of them actually contain any nudity.  The runTime--just 
    > like the Nudity advisory--is /meaningless/ in the context of the 
    > schedule, as it's just information about the /original/ program, not 
    > what's actually airing.

Nonetheless, in 100% of the cases in which I've been burned by
incorrect endtime data from SD, the runTime indicated that the
showing was in fact longer than the scheduled slot.  That's all
I was saying.  Note in paticular that I am making no other assertions
about what runTime means or is supposed to mean, where the data comes
from, or whether SD's data is likely to be better in the future.  (I'd
guess not, since it's presumably the individual channels that are
screwing the pooch before they even hand the data off to TMS, and
I've been seeing this for years.)

    > Now, I know you have no reason to believe anything I said.  I know I'm 
    > not a -developer-, so my opinion is meaningless to you.

I'm sorry if I made you defensive, but you have repeatedly gone far
out of your way to reassure everyone that you are, in fact, not a
developer, and---in particular---that you cannot speak for them.
Since I was trying to do due diligence on writing a patch, I needed
to know which path to take to maximize the chances that it would be
committed and that I wouldn't be wasting my time going down a blind
alley.  When you responded in a way that indicated (to me, and at
least a couple other people, apparently) that you'd misunderstood me,
I asked for a second opinion.  That's all.

And I said "developer" because to me that means "people with commit
access."  If you take it as a more-expansive term, and I should have
explictly used the term "PWCA" in every instance as well, then I
apologize for misleading you.  [But then, why are you so adamant all
the time that you are -not- a dev and don't speak for them?  I'm only
repeating to you what you say to everyone else about yourself!]

    >    							     But--here's my 
    > theory--the actual -developer-s have far better things to do than waste 
    > literally hours of their time trying to quell the dissidence when 

There's that word again.  I do not think it means what you think it means. :)

    > someone throws up an idea--without doing the research

Again, what research, exactly?  I pointed out information that Myth
had that it wasn't giving to me that would have saved my bacon if it
had.  I -did- the research, over the past couple of years, to show a
100% correlation between that data and getting screwed.

At this point, I'm unsure exactly what the nature of your disagreement
with me is.  Do you think:
(a) I'm incorrect or lying about the correlation?
(b) The correlation is, in fact, not actually a bug at all?
(c) It's a bug, but it's insoluable without
    (1) hairing up Myth's code unacceptably?
    (2) hairing up Myth's -support- unacceptably?

I'm fairly sure that you believe c2, at least, if Myth was to
automatically extend recordings to max(runtime, (endtime - starttime)),
since you've already said that.  I'm not sure about the rest.

[I think your suggestion for "the only patch that should be considered"
from your previous message at least indicates that we're in branch c here,
which is progress, I suppose.]

I'm certainly hoping that it's -not-:
(d) It's just personal, and you'll go out of your way to gainsay
    anything I have to say, expending whatever resources it takes.
    Judging by your comments about me on IRC, a reasonable person
    might be led to this conclusion.
I'd like you to know that -I- am not in branch d and do not anticipate
arriving there.

    > 							 --and convinces a 
    > bunch of other people that the idea has merit so they start arguing for 
    > its implementation.

Once again, the "argument" has basically been three pieces of mail
from two other users, both of whom have said, "Sounds reasonable to me."
Considering the overwhelming avalanche of off-topic messages and even
entire threads on this list, this doesn't seem excessive to me.
Apparently it does to you, though.  And apparently you also believe
that it's you against the unwashed masses, keeping the devs safe from
things you think are evil.  Okay, that's fine, but please don't blame
me if that's how you want to spend your time.

And what's my alternative?  Remember, I'm following the process here:
When considering a proposed patch, start in -users, maybe move to
-dev, maybe move to trac.  Would you have preferred that I simply
started in trac and -definitely- wasted dev time closing the report
because I'd solved the wrong problem in the wrong way?

    > 			 They're probably actually using the free time they 
    > devote to MythTV to -develop- code rather than doing the research that 
    > the person who threw up the idea should have done.

Well, you could have done the same.  I thank you for spending the
time, but I do not thank you for the tone and attitude.  You had ways
to give your opinion without being so unpleasant about it, and you
still do.  [For example:  "Doing autoextension is technically possible,
but fatally hard to explain to users."  That's a perfectly reasonable
stance.  Or:  "Doing autoextension will fatally confuse the scheduler,
and here's why it's not feasible to try to fix the scheduler."  But
launching into a tirade about mucking about with the starttimes of
later programs, and generally acting belligerant towards me, is not
the way -I- would have preferred you got into it.  That's all.]

    > ...I wonder how much code I could have written (not -developed-, you 
    > see, because I'm "not a -developer-") for MythTV had I not wasted all 
    > those hours on this thread...

By the same token, given how much time this has taken already, I'd
have already built a patch for myself if I hadn't asked first, but I
wanted to see if I was being totally stupid and there was a better
solution---and I wanted to try to give back to the community by fixing
this for everyone, not just me.  If I'd known that this was the
reaction I was going to get, though, I'd have simply said, "Screw
giving back, screw proper process, I'll just fix it for myself and
maybe someday just open a trac ticket without any discussion and see
what happens.  Or maybe I'll decide it's not worth even trying to give
anyone a patch because I'm tired of getting yelled at on the most
unpleasant technical list I've ever been on."

    > Mike "Not a -developer-" Dean

When I said "no offense", I actually meant it.

When you say you aren't a developer and don't speak for them,
do -you- mean it?