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

[Steve Hodge]

On Sun, Apr 12, 2009 at 4:29 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 04/12/2009 12:07 AM, f-myth-users at media.mit.edu wrote:
>
> 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?
>

If program A starts at 10pm and the following program B starts at 11pm but
program A's runtime is supposedly 65 mins then something is clearly wrong
with the schedule: either the runtime of A or the start time of B. But
which? If we leave program B's start time at 11pm but change program A's end
time to 11:05pm we'd be able to succesfully record either program (or both
with two tuners) regardless of which piece of data was wrong.


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

Does the scheduler require that?

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

So rather than do the best we can with the data provided we should ignore
one piece of data entirely and have a blanket rule that guesses the worst
case scenario?

Regards,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090412/48075cd0/attachment.htm>