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

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

[Should this be on -dev?]

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.

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

Opinions?

(In the meantime, I'm currently looking at some extremely rude hacks
to fix this before (a) it can be fixed -and released- in SVN, and (b)
I actually get the opportunity to upgrade to that release.  I'm
thinking of perhaps either trying to max it myself, or adding a
column to some tables to indicate "things are inconsistent here"
so if something gets scheduled with the inconsistency I can have
something else peruse the tables & notice.  But I'm not 100% sure
how to even add the maximization---probably the cleanest solution---
because I haven't yet completely followed the logic in datadirect.cpp.
If I've analyzed this correctly and this looks like a straightforward
fix in current SVN, I could backport it into my own version and give
it a whirl.)

Thanks!