[mythtv] scheduling, starttime accuracy

Nigel Pearson nigel at ind.tansu.com.au
Sun Feb 15 07:18:55 UTC 2009

> I can't quite see how -any- time-based metric can help your problem,
> which (as I understand it) was sharing frame-accurate cutlists.

It is, but just for watching, not frame-accurate editing, et c.
If I do want to make something from him frame-accurate in my
recording, I have been using his as a guide for editing,
in the same way as I would commflagged cutpoints.

Still a big experiment, but for the majority of the recordings,
the cut points are within 1.6s. That is good enough,
particularly if the cut points aren't too aggressive
(e.g. start a little late and finish a little early),
and if there are long programme title sequences,
or long fades to/from black.

> Even if both machines are NTP-synchronized and even -if- we recorded
> the exact time (down to the frame) that a recording started on (which
> a ctime won't give you, if you're using a filesystem with 1-second
> granularity---and some are),

On one test server, ctime was good enough.
On production, it was wildly out.
(by days! That volume is mounted as
  noatime, but it shouldn't do that)

This, coupled with DST/TZ, meant that I went
with using the backend log lines like:

2009-02-12 13:00:03.410 Started recording Blah: channel ...
2009-02-12 13:00:03.582 scheduler: Started recording Blah: ...

This, with NTP, got us most of the way there.

> you're still screwed, even if both of you
> are recording from exactly the same source (same cable channel on same
> cable system, same OTA broadcast, whatever):

Yes. Same major city, same digital source.
Anything else would make sharing pointless.

Analogue recordings should be "screwed",
but interestingly enough I have been surprised.

For things like Oprah and Dr Phil,
synch'ing his DVB-T to a local NuppelVideo
(768x576 lightly compressed to MPEG-4)
have been within 12 frames !

> Rather than mess around with recording accurate starting times (there
> may well be reasons to do this---but not, I think, for the reason you
> gave initially), you might be able to accomplish this with something
> more computationally intensive but much more reliable, such as
> analysis of the input.

Very possible, but a lot more work. I was trying to save my time :-)

Nigel Pearson, nigel at ind.tansu.com.au| "Peacemaking is our profession"|
Telstra Net. Eng., Sydney, Australia |Motto of Burpelson Airforce Base|
Office: 9202 3900    Fax:  9212 6348 |Commanded by Gen. Jack D. Ripper|
Mobile: 0408 664435  Home: 9792 6998 |        Dr Strangelove          |

More information about the mythtv-dev mailing list