Mod: ntpclient

Black Hole said:
I had complete power down on the HD-FOX last night, and of course the clocks were all back to dot. I've taken the opportunity to install the updated ntpclient, and the screensaver and iPlate clocks are all up and running with no reboots, so I would be interested to know how it did that.

However, this being BST it's an hour out!
Click to expand...

I have had far fewer problems with booting since 1.02.27 (in fact, none at all but that's like speaking too soon). I still have ntpclient installed, and it is still on GMT. I had a look for the (presumably) script which runs it at boot time to see if there are any parameters to tweak but I couldn't find anything the diagnostics editor would open (BTW: what's that recursive /mod/boot/2/mod/mod/mod... directory?).

Where should I look?
 
There will not be any ntpclient parameters that can be tweaked for this. The NTP protocol always uses UTC and is not changed for daylight saving time or for different time zones. Similarly *nix systems usually have their system clock set to UTC. It is then up to the applications to make a library call to translate the time to display the time in the correct locale.

I think your best bet is to set the TZ variable before the humaxtv application starts and then hope that it calls the correct library routines to translate the time to BST.

This may or may not work:

Edit: Change to TZ variable deleted since it is probably a bad idea.
 
xyz321 said:
I think your best bet is to set the TZ variable before the humaxtv application starts and then hope that it calls the correct library routines to translate the time to BST.
Click to expand...

I very much doubt that Humax have ever tested their software running with a non-standard TZ variable! Definitely one to try at your own risk.
 
Is there any mileage in me attempting to adjust the source code for ntpclient and recompile it to account for BST?
 
I was going to try setting the TZ variable on and HDR (in the absence of an HD) to see if I could break it:). I performed an initial test, without making any changes, to see what happens when it is powered without the aerial connected. In this case the front panel clock started at 0:00 and then jumped to 01:00, which suggests that the DST correction is being applied. Looking at setup.db, I notice that 'GMT_OFFSET_MINUTES' is set to 60. What value is it set to on your HD? If it is set to zero then it might be worth a go at setting it to 60:

Edit: Alternatively you could look at the 'Get Network Time' setting in the Hidden settings menu - it is set to 1 hour on my Humax.
 
I guess this might be another consequence of no aerial - somehow the EPG data is used to track the clock change and update that parameter.

What's the magic incantation? (Edit - I see you have edited it in thanks)
 
Black Hole said:
I guess this might be another consequence of no aerial - somehow the EPG data is used to track the clock change and update that parameter.

What's the magic incantation? (Edit - I see you have edited it in thanks)
Click to expand...
Sorry, I have changed it yet again ;)
 
Ouch!

Well, that certainly did update the database parameter, but my clocks are back to 1970 (albeit 0100)! A warm restart has not improved matters, I will give things time to settle and see how the patient is later (I'll give it a cold boot it will never forget...)
 
xyz321 said:
Sorry, I have changed it yet again ;)
Click to expand...

We're out of sync here. Is it either/or?

Ah, OK, I see the database tweak has now been reflected through to the service menu setting.

(For the uninitiated, go through my links below to the Index of Existing Informative Topics and you will find the Hidden Service Menu listed under Standard Fimware. To save you the bother this time, it is Menu >> Settings >> System >> System Information >> Red >> Green >> Yellow >> Blue >> Green >> Yellow >> Blue.)
 
Success! Thank you :)

Even though the I-plate and screen saver clocks were stalled (01:00 01/01/1970 in the case of I-plate, 00:00:00 on the screen saver - weird), the front panel standby clock still showed GMT so I knew there was still system time in there somewhere.

A few warm starts later (including circumstances which would definitely have hit the HD-FOX failed boot syndrome pre 1.02.27 - that's another plus) I have I-plate and screen saver clocks which match my RDS clock within a second.

For anybody else: the trick of system time management when running without an aerial feed is ntpclient and manual control of BST offset through the hidden service menu, plus a little patience while it sorts itself out through a few reboot cycles (because ntpclient updates the system clock some time after boot, but the system clock does not update the various display clocks until another reboot - or more).
 
The latest version of this package, i.e. Ntp Client 2010-365-4 runs the -l option which continues to keep Humax time in sync. with internet time in between re-boots, there is a link to the info. HERE
 
To resurrect an old friend: I noticed the screen saver clock on my HDR3 has drifted nearly a minute fast since the last cold boot (whenever that was; we have discovered that the system time on the HD/HDR-FOX only updates itself from the EPG data after a cold boot, not a warm start from standby). I decided to have a play and see what consequences there would be of the clock is significantly out, it certainly appears that manual timer recordings are affected.

Via Telnet I poked a time in that was about 20 minutes fast. It appeared to take, the date command responded with the system time I poked in. I then performed a short instant recording, anticipating the recording time stamp would reflect the new system time, but it didn't. I then paused the live TV to let the screen saver clock come up - when it did, it was within about a second of the time on my radio controlled clock! Querying the system time produced the same response - somehow having the system clock so far adrift from the EPG time caused it to resync.

Foolishly I did not check the correlation of the system time with true time before I poked it. Next I will try to see how far different the system time has to be before it triggers a resync.
 
OK folks, experimenting with the date command indicates the system clock can be set up to a minute fast or slow, but over a minute and it resyncs to the EPG.

Hypothesis: the screen saver clock drifts compared with real time, but will never be observed more than a minute out.
 
...and the screen saver is now running only 5 seconds fast. Conclusion: my hypothesis that the system clock is resynced to the EPG clock if it drifts more that a minute appears to be correct, and the rate of drift on HDR3 is 9 seconds over 4 days!
 
My ethernet connected box starts ntpclient fine every time, but the one with a wireless adapter does this every time:
Code: 
>>> Contents of /var/log/ntpclient.log 85.00 bytes
=== Setting clock from NTP ===
pool.ntp.org: Unknown host
pool.ntp.org: Unknown host
Is there a way to test that DNS is working before attempting to start it?
Checking if-up is obviously not enough.
I have bodged it for now using a "sleep 30" in /mod/etc/init.d/S90ntpclient
I tried "sleep 10" but that wasn't enough.
 
You must log in or register to reply here.
Back
Top