[mythtv] scheduling, starttime accuracy

[Janne Grunau]

On Thursday 12 February 2009 17:51:41 David Engel wrote:
> 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.

What about using progstart/progend for display purposes? I'm using 
default "start early / end late" and the startime - 1minute annoys me 
for well known programmes. starttime could then changed back to the the 
exact time.

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

Assuming that the clocks are synchromized error wouldn't be more than a 
second. Not perfect but bearable.

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

extract the pts from the frame at the cut point and save it in 
recordedmarkup. This will obviously only for digital tv streams.

> I'll defer to Daniel and those who know more about this.
>
> 4) Could you use the ctime of the recording file?

should work too

Janne