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

[Michael T. Dean]

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

IMHO, no.

> I've been burned a few times by the following inconsistency.  I'm
> running a very old Myth, but it appears that the relevant code is
> essentially unchanged (except for formatting changes) all the way
> up to at least 0.21.  Can someone tell me what Myth is -supposed-
> to be doing here?  Or maybe this is already fixed in SVN?
>
> Check out the following data from SD:
>
>     <schedule program='MV000273580000' station='12852' time='2009-04-11T13:00:00Z' duration='PT03H00M'/>
>
>     <program id='MV000273580000'>
>     <title>Little Dorrit Part Two: Little Dorrit&apos;s Story</title>
>     <description>Dickens&apos; tale of a girl (Sarah Pickering), her father (Alec Guinness) and their benefactor (Derek Jacobi) is seen through the girl&apos;s eyes.</description>
>     <mpaaRating>G</mpaaRating>
>     <starRating>***+</starRating>
>     <runTime>PT03H03M</runTime>
>     <year>1988</year>
>     </program>
>
> Note carefully that the duration in the "schedule" tag is exactly 3
> hours, but the one listed in the runTime tag is 3 hours and 3 minutes.
> (The TCM website currently claims that this is actually 184 minutes,
> or 3 hours and -4- minutes, but -also- that the showing starts at
> 9am and ends at noon.)
>
> Obviously this data is inconsistent.
>
> The actual showing was, in fact, longer than 3 hours.  I routinely
> pad recordings from TCM by 2 minutes on both sides, which is usually
> plenty, but not in this case---the last few minutes got truncated.
>
> I've also seen this behavior from Sundance, and perhaps from other
> channels.  It's rare, but frequent enough to be a hazard.
>
> Myth's behavior appears to be to follow the data in the "schedule"
> tag, even though I see code in datadirect.cpp that clearly seems to be
> also extracting the runTime info, only to stuff it into a variable and
> then (I believe) drop it on the floor later in the handoff from the
> dd_schedule temporary table to the dd_v_program temp table.
>   

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.

> 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--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?

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 ...

> Opinions?
>   

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

Basically, the right solution--in the face of garbage listings--is
manual padding.  Lesson learned...  Hindsight is 20/20...

Mike