[mythtv] scheduling, starttime accuracy

[Daniel Kristjansson]

On Thu, 2009-02-12 at 16:27 +1100, Nigel Pearson wrote:
> I am trying to share commercial block markup data with someone local,
> and am having problems with the accuracy of the cutlists.
> 
> It seems that my recordings are often up to 3s offset with his
> cutlist data. Looking at the recorded table, the starttime is
> _always_ an integral minute (i.e. 20:27:00, 21:30:00).
> 
> Haven't looked yet, but suspect its just the way the code works.
> e.g. Recording 1 ends at 8:30. Recording 2 starts at 8:30 on
> the same card, The scheduler and file IO takes 3sec to create
> a new recording file, update the database, et c., but the start
> time is recorded as the scheduled time of 8:30.
> 
> 
> Proposals:
> 
> 1) Use the real starttime in the recording classes. e.g. 8:30:02
> Con: May break things that expect starttime to be the :00,
>       or the scheduled time minus preroll
>
> 2) Add another column, like realstarttime. e.g. 8:30:02.874
> 
> 3) For true interoperability, use the digital stream's timecode,
> or analogue VBI/teletext/etc data, if available and not too
> divergent from local time.
>
> Thoughts? I am tempted to implement at least 1 soon,
> simply because it seems the "correct" behavior.

"recstarttime" is what is used for the filename, mucking with this
will cause problems as it needs to be artificially incremented in some
cases until there is no conflict in file naming. I don't know if fixing
"starttime" will have any negative consequences, but it seems like
"recstarttime" would really be the proper one do update for "correct"
behavior. In that case the filename creation code may need to be
revisited. Option 2 would be easiest to implement, but the downside
there is obvious, adding another column with almost the same meaning
as recstarttime. Option 3 would probably not work too well as DTV
times are often many seconds distant from the real time, and the
timecodes are a complete mess on many broadcasts that include commercial
interruptions.

Note: I haven't looked at the filename creation code lately it may have
changed when Storage Groups were introduced; if there is only one place
where the artificially incremented recstarttime is used to synthesize a
recording name that is then stuffed in ProgramInfo and used from then
on, the recstarttime could subsequently be updated to the "correct" time
later without negative consequences. (i.e. when the first byte is
written to the RingBuffer.)

-- Daniel