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

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Mon Apr 20 05:52:16 UTC 2009


To be clear about Mike Dean's misunderstanding of what I was trying to
get across (and Mike Perkins' correct understanding of it), my comments
on what the former thought I was saying:

    > The schedule info is the final arbiter--with the small exception that
    > when there are gaps in the schedule, the preceding program's endtime is
    > extended to the following program's starttime.  I.e. schedule is the
    > final arbiter, but starttime is more authoritative than endtime.

The "schedule info" that Myth is seeing is INCONSISTENT.  So which of
those two sources, BOTH of which are coming from SD, do you say is the
final arbiter?

    > > I would argue that Myth should take the max of the two values and use
    > > that in computing the endtime of the recording.  (It should -not- just
    > > use runTime!  If runTime is too short, the recording will certainly be
    > > truncated---I'd certainly rather that Myth took the maximally-conservative
    > > approach and possibly record too much than the reverse.)

    > So, you're saying that it should ignore the starttime of the following
    > program

I'm saying no such thing.

If it's your contention that there is no way to cause Myth to (say)
pad the end of the recording without fatally screwing up any later
recording (e.g., not that "it uses another tuner" but that "the
scheduler will be -unable- to make sense of the resulting situation"),
then I'd like some proof of that.

    > 	   --so that the guy who wants to watch that show writes an e-mail
    > to the list saying that the program was clearly listed with the proper
    > starttime in the raw data, but for some reason, Myth changed the
    > starttime to the incorrect starttime, so he lost the beginning of his show?

Again, I said -nothing- about changing the starttime of -any- program.
I said I want the starttime of the second program to overlap the
endtime of the first program, by extending the endtime of the first
program.  This works just fine in the case of hard-padded programs;
can it work in this case?

    > The problem is that the entire schedule--not just the schedule for
    > /this/ program--has to line up with endtimes matching starttimes and no
    > gaps and ...

Myth is already seeing inconsistent data.

    > > Opinions?

    > Garbage in, garbage out.  Fix the schedule, save the world...  There can
    > be only one starttime/endtime...

Myth is already seeing inconsistent data.

    > Basically, the right solution--in the face of garbage listings--is
    > manual padding.  

I already -said- that I manually padded -everything- to some degree.
I'm saying that this solution is insufficient.  To put this more clearly:

This happens frequently enough that it's cost me the ends of several
movies, and in none of the cases so far has the movie been repeated
within the year---and it's been going on for three years at least, and
probably longer.  Expecting the data from SD to improve is probably
unrealistic, given that it's had this issue forever and that DD had
the same issue before it---and that the source of the garbage may well
be inconsistent data coming from the various broadcasters and going to
Tribune, judging by the example I gave of TCM's website.

But this is a bad failure mode to deal with by hand, because (a)
manually checking the end of the movie (1) spoils endings and (2) is
-too late- anyway if it's not going to be repeated, and (b) it's
nonetheless rare enough that having to add 10-15 minutes of padding to
-every single movie- just in case the data's wrong is a -lot- of extra
storage.  And I'm -already- doing that in the case of Sundance (having
been screwed too many times on this) and I'd like to not have to start
doing it for -every- movie channel.  Storage may be cheap, but it's
not absolutely free, and adding tons of padding also chews into the
available tuners---especially given the random nature of most movie
channel's endtimes already.  It would be one thing if this was just
clock skew---Myth has no way of establishing broadcasters' skews.
But it -does- have a way of noticing this particular failure mode,
and actually invests effort in collecting the data required to
recognize it, only to then throw it away in the end.


More information about the mythtv-users mailing list