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

William Kenworthy billk at iinet.net.au
Thu Sep 17 02:10:42 UTC 2009


On Wed, 2009-09-16 at 21:47 -0400, f-myth-users at media.mit.edu wrote:
> > Date: Thu, 17 Sep 2009 08:45:57 +1000
>     > From: Jean-Yves Avenard <jyavenard at gmail.com>
> 
>     > The NFS server was 4 minutes ahead of time... even with ntpd running ;
> 
> ntpd will punt if the difference gets too large and will just let your
...

Only if you let it! Read the ntpd man pages, there is a setting that
allows it to try and keep tracking no matter what the difference.  There
are also settings to "loosen" the default parameters to enable it to
track more wildly varying sources (either by stepping, or slewing - your
choice), and also a "huffpuff" value that can help deal with overloaded,
low bandwidth connections to the reference.  The burst and iburst
parameters can also help in some cases.

That being said, there seems to be something badly wrong with your
network/systems for this to happen with the default parameters.  ntp may
run into problems with heavily overloaded dialup links, but I have yet
to see a good home network causing this.

Some things to look for:

gadgets that access the /proc files directly - for quite a while gnome
battery applets would cause this by blocking the /proc file system, and
I have heard of other apps that can do it too - have not seen this for
2yrs or so.

Incorrectly set vmware, host and client timing options.  vmware sucks at
timing, but can usually be made to work if on a machine with enough
horsepower.

Badly setup ntpd.conf - defaults are usually good these days though.
You should have a single host (normally your gateway) syncing to the
outside world, and all local machines syncing to that (hence it seems
strange that local machines have different times.

ntp sync packets going over a very heavily loaded link - never seen this
on a 100mbs ethernet though.

Heavily loaded time server - loads have to be ridiculous to cause any
problem though.

Lastly, check out ntpq, ntpdc and ntptrace to check your ntp operation.

Comment on step/skew: ntp tries to keep the time in step by "slewing"
the time back to the target.  If it thinks its too far out to skew, it
will abruptly step to the correct time.  If further out still, it will
silently fail.  All are tunable parameters.  For database users, its
considered that skew is less of a problem than stepping, because large
steps could cause problems with timestamps on some operations.  For
mythtv, this doesnt seem to be a problem.


BillK




More information about the mythtv-users mailing list