[mythtv] scheduling, starttime accuracy

[David Engel]

On Thu, Feb 12, 2009 at 04:27:26PM +1100, Nigel Pearson wrote:
> 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.

That would be me several years ago.  I used (and still do) a 5 second
pre-roll and hated seeing all of my recordings displayed as starting
at xx:29 and xx:59 and having filenames with *2957 and *5957.  I
changed the scheduler to round the starttime to the nearest minute.

> 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

As long as you don't break the display and filename issues I noted
above, maybe this is OK.  A very quick glance of the MySQL reference
seems to indicate the DATETIME type only has 1-second granularity.
Are you sure that would be accurate enough for frame-based cut lists?

> 2) Add another column, like realstarttime. e.g. 8:30:02.874

Ugly and required a new column in the DB, but might be the best
option.

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

I'll defer to Daniel and those who know more about this.

4) Could you use the ctime of the recording file?

On Thu, Feb 12, 2009 at 01:02:23AM -0500, Daniel Kristjansson wrote:
> "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

Why we haven't added an id column to the recorded table and used it to
uniquely identify recordings?  If we was used a unique id in the
filename, we wouldn't have to worry about starttime duplication.  It
would also probably speed up table accesses where we currently use
chanid/starttime instead.

David
-- 
David Engel
david at istwok.net