PDA

View Full Version : Wrong time shown on SliMP3



Matt Sims
2004-03-17, 04:36
An update to my slow clock problem...

My original setup which didn't exhibit the problem:

WinXP machine with two network cards, one wired (statically assigned an
IP address of 192.168.0.1) and one wireless (dynamically assigned an IP
address in the range 10.0.0.x by combined wired/wireless router).
SliMP3 was connected to the wired network card, and statically assigned
the IP address 192.168.0.2 (and told that the server was running on
192.168.0.1). Clock keeps perfect time.

My new setup which has the problem:

Same WinXP machine above is now only connected via the wireless card to
the combined wired/wireless router. Another WinXP machine is used as
dedicated SlimServer, wired to the combined wired/wireless router (and
therefore dynamically assigned an IP address in the range 10.0.0.x).
SliMP3 now also wired directly to the combined wired/wireless router
(and therefore also dynamically assigned an IP address in the range
10.0.0.x). SliMP3 detects SlimServer and works fine, only now the clock
on the SliMP3 will lose time. When the SlimServer is started (perl
source run as a service using FireDaemon), clock is in sync. After an
hour, clock has lost approx. 5 minutes, and continues to lose the same
amount of time every hour thereafter.

Any ideas anyone? My first thoughts were that there must be some kind
of delay of the clock 'tick' signal being introduced in the router, but
then I thought that surely the SlimServer sends the actual time rather
than just an 'increment second' signal, so even if it missed a few
signals here and there it would still display the correct time?

Very bizarre indeed, so any info (or experiences of others running a
similar setup) would be much appreciated!

Thanks in advance,

Matt.

P.S. The system clock on both WinXP machines, as well as the routers
clock, are all spot on, all set by NNTP (although the router does use a
different NNTP server to the two WinXP machines if that makes any
difference?).

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of kdf
Sent: 12 March 2004 17:30
To: Slim Devices Discussion
Subject: [slim] Wrong time shown on SliMP3


Quoting Matt Sims <mailinglists (AT) mojo-it (DOT) co.uk>:

> Hi,
>
> I've just noticed that the time displayed on my SliMP3 when switched
> off is wrong. The time on the server (WinXP, 5.1.1 perl) is correct
> (synced with NNTP). Any ideas where to look?
The SliMP3 gets the time from the server. Where to look, depends on how
far off the time is. If its shifted by hours, then you have something
perhaps nto matching between your system timezone and the timezone set
for you nntp client/server. If its minutes or seconds, that's another
matter. I would be surprised it that was the case, however.

-kdf

seanadams
2004-03-17, 08:05
Bizarre.

We don't maintain our own notion of time-of-day anywhere in the system.
Not in the server, not in SLIMP3, and not in Squeezebox.

Any time we need to know what time it is, we ask the OS. This happens
every time the clock display is updated, which is once per second.



On Mar 17, 2004, at 3:36 AM, Matt Sims wrote:

> An update to my slow clock problem...
>
> My original setup which didn't exhibit the problem:
>
> WinXP machine with two network cards, one wired (statically assigned an
> IP address of 192.168.0.1) and one wireless (dynamically assigned an IP
> address in the range 10.0.0.x by combined wired/wireless router).
> SliMP3 was connected to the wired network card, and statically assigned
> the IP address 192.168.0.2 (and told that the server was running on
> 192.168.0.1). Clock keeps perfect time.
>
> My new setup which has the problem:
>
> Same WinXP machine above is now only connected via the wireless card to
> the combined wired/wireless router. Another WinXP machine is used as
> dedicated SlimServer, wired to the combined wired/wireless router (and
> therefore dynamically assigned an IP address in the range 10.0.0.x).
> SliMP3 now also wired directly to the combined wired/wireless router
> (and therefore also dynamically assigned an IP address in the range
> 10.0.0.x). SliMP3 detects SlimServer and works fine, only now the
> clock
> on the SliMP3 will lose time. When the SlimServer is started (perl
> source run as a service using FireDaemon), clock is in sync. After an
> hour, clock has lost approx. 5 minutes, and continues to lose the same
> amount of time every hour thereafter.
>
> Any ideas anyone? My first thoughts were that there must be some kind
> of delay of the clock 'tick' signal being introduced in the router, but
> then I thought that surely the SlimServer sends the actual time rather
> than just an 'increment second' signal, so even if it missed a few
> signals here and there it would still display the correct time?
>
> Very bizarre indeed, so any info (or experiences of others running a
> similar setup) would be much appreciated!
>
> Thanks in advance,
>
> Matt.
>
> P.S. The system clock on both WinXP machines, as well as the routers
> clock, are all spot on, all set by NNTP (although the router does use a
> different NNTP server to the two WinXP machines if that makes any
> difference?).
>
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com
> [mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of kdf
> Sent: 12 March 2004 17:30
> To: Slim Devices Discussion
> Subject: [slim] Wrong time shown on SliMP3
>
>
> Quoting Matt Sims <mailinglists (AT) mojo-it (DOT) co.uk>:
>
>> Hi,
>>
>> I've just noticed that the time displayed on my SliMP3 when switched
>> off is wrong. The time on the server (WinXP, 5.1.1 perl) is correct
>> (synced with NNTP). Any ideas where to look?
> The SliMP3 gets the time from the server. Where to look, depends on how
> far off the time is. If its shifted by hours, then you have something
> perhaps nto matching between your system timezone and the timezone set
> for you nntp client/server. If its minutes or seconds, that's another
> matter. I would be surprised it that was the case, however.
>
> -kdf
>
>