[mythtv-users] How do I get coverart/etc in watch recordings?

[f-myth-users at media.mit.edu]

    > Date: Wed, 16 Sep 2009 23:21:06 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 09/16/2009 09:47 PM, f-myth-users at media.mit.edu wrote:
    > > I have 3 identical motherboards which occasionally (5%? 1%?) boot with
    > > the clock running at least 5% fast; this is enough to cause NTP to lose
    > > sync within 5 to 60 minutes and drop out.

    > Does your system do an "ntpd -gq" (replaces the deprecated ntpdate) on 
    > boot before starting ntpd as a daemon?

According to the ntpd documentation, that would essentially act like
ntpdate (except that the systems involved are old enough to lack -q
and do have ntpdate), and would reset the clock even if it was more
than 1000 sec (e.g., 16 minutes) off.

That's not the issue.  The problem is that (when the hardware comes up
wrong), the machine starts out within a few seconds (probably within 1
second) of the correct time, but then tries to run 5% fast.  If ntpd
weren't running it -would- be running 5% fast from the first second it
was up.  If I reboot, it will (most likely) come up -not- running 5%
fast.

In any event, my systems do run ntpdate on boot, and then they start
ntpd.  When the hardware is 5% fast, I can see ntpd run for a while
until its PLL loses lock, and it logs ever-increasing desperate clock
excursions before it finally decides to give up the ghost.  At that
point, nothing at all is attempting to discipline the clock, and it
then runs away at something like 3 seconds per minute.  [NTP's tracking
loop is quite badly-behaved in this circumstance, since after all it
was never designed to cope with what amounts to a huge Doppler shift,
and it also writes a lot of bogus loop stats in this configuration,
which cause the machine on the -next- boot (when the clock is running
right) to display quite a bit of ringing and overshoot until the PLL
manages to reacquire reality.  That's the other reason why forcing
ntpd to run in this degraded mode isn't such a hot idea---even if
it -didn't- give up, it would leave behind a lot of bogus info about
how fast the hardware clock ran that the very next boot would have
to laboriously undo.]

Since this is the typical behavior when FSB spread-spectrum was turned
on, my guess is (a) the BIOS is buggy with SS and (b) occasionally it
comes up enabled even though the BIOS claims it's off.  But it only
happens a very small percentage of boots.  The problem, of course, is
that when it happened, I typically didn't notice until several hours
of recordings had started increasingly early and had increasing
amounts of their ends chopped off.  After all, the machine was
running 3 minutes fast every hour... :)