[mythtv] scheduling, starttime accuracy
janne-mythtv at grunau.be
Thu Feb 12 17:20:46 UTC 2009
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
> > 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
> > 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
More information about the mythtv-dev