Mod: ntpclient

Black Hole

Black Hole

May contain traces of nut
In a few idle moments I have just had a skim of the Wiki - I don't normally have time to patrol everything, and the Wiki is something I've left to its own devices. I notice the ntpclient package is listed.

Unhappily I do not have my HD-FOX system configured at the moment to check, but my recollection is that the package I installed a few days ago did not restore iPlayer after a cold start.

Is it the case that I am the only potential tester/user for this and it awaits my feedback?

Background reading: follow the trail starting HERE (click).
 
Perhaps 'ntpdate' from the full ntp server would be a better option since it should still correct the time even if the box time is massively out.

Edit: I notice that ntpdate has now been deprecated since the functionality has been incorporated into the main ntpd daemon. I think there are unlikely to be any issues with ntpdate so it may be worth a go.
 
The ntpdate package does seem to work ok on my HDR, but it sets the time too late to fix the portal access. The clock needs to be set prior to launching the humax software. It will be sufficient to set the date to something (anything) this year early on in the boot process - I had intended to build a package to do that but haven't made the time yet!
 
Is that something to go into the CF (boot code)? Read the system clock and if it is 1970 (what it seems to initialise to) write something more sensible (from a stored parameter perhaps?). Presumably the date/time will get re-written from the EPG later.
 
I'm pleased to say that, after several days of cold storage, I fired up the HD-FOX (no aerial) last night and some time later I noticed the screen saver was showing the correct time. So I tried booting iPlayer and it worked. I guess ntpclient must have done its job.

:)
 
Spoke too soon.

I had a lock-up problem on the HD - what typically happens is I sometimes get no sound on the HDMI after a boot, and then warm starts fail to "take" and it drops back to stand-by until I eventually get it to start up (possibly requiring a hard reset). Afterwards the screen-saver clock was showing a few minutes (and counting), and no portal, so the system clock was back to 1970 and ntpclient had not done its job.

I've tried everything including a cold start, and failed to recover the situation. Finally I resorted to a busybox date and then restart commands.

What should I do to force ntpclient into action?
 
Ok, I'll roll you a 'set clock to something current on boot' package and see if it helps. I have been meaning to get around to this. Could you check that the new diagnostic screen in the webif shows all passes first?

I think the ntpclient is firing too late in the proceedings whereas forcibly setting the date to something current immediately prior to the Humax software starting should be effective.
 
I've been playing this morning (after the clock forgot overnight) and found the date command applied very soon after a reset has very good effects - all the way down to the i-plate date display (which I have not seen before). A special boot may not be necessary if turning off power saving helps preserve the clock in stand-by.

What I would like at the moment is a means to monitor/control ntpclient. If I can be sure when and if it runs, having the system clock up to date before a reboot (as long as the clock survives the reboot) should solve the problems.
 
Where is the diagnostic screen? If it's on the Settings page I get this:

Code: 
Runtime Error: /mod/var/mongoose/lib/system.class:57:
in procedure 'header' called at file "settings.jim", line 89
at file "/mod/var/mongoose/lib/setup", line 13
at file "/mod/var/mongoose/html/lib/header.jim", line 19
at file "/mod/var/mongoose/html/lib/topbar.jim", line 9
in procedure 'system' called at file "/mod/var/mongoose/include/diskspace.jim", line 6
at file "/mod/var/mongoose/lib/system.class", line 57

I updated to the latest WebIF before this, and I had a load of errors because (no aerial) it couldn't collect EPG data (presumably for the channel icons).
 
xyz321 said:
Perhaps 'ntpdate' from the full ntp server would be a better option since it should still correct the time even if the box time is massively out.
Click to expand...
Aha! Does this mean ntpclient can only pull a clock into sync, not set it up in the first place? I've done a little background reading on ntpclient, and from what I understood of it, it fiddles with the clock calibration in the OS???

I think a boot process which checks the date, and only if it is "1970" just roughly gets it current enough to run the TV Portal (don't ask me how), would be good enough. After that, if some manual control is available (eg via the WebIF) to "set system time" to current and then reboot, it could be applied only when necessary (which might only be after a cold start if my ploy to turn off power saving helps, and as long as the timekeeping is OK).
 
Black Hole said:
Aha! Does this mean ntpclient can only pull a clock into sync, not set it up in the first place?
Click to expand...

That's the usual function of NTP as abrupt changes to the system clock aren't a great idea, but the ntpclient package just does a one-time update from an Internet time server and sets the clock to that time. It only runs the once, after the Humax software has started up. I didn't want to run a permanent clock synchronise process as it would likely interfere with Humax's own mechanism.
 
af123 said:
Ok, I'll roll you a 'set clock to something current on boot' package and see if it helps...
Click to expand...

I've uploaded a forcedate package which hooks into the boot process and forcibly sets the date/time to Wed, 16 Nov 2011 12:34:56 GMT. If you give it a try, it should create a log file under /tmp called forcedate.log and if you update the webif you should even be able to view that from the diagnostics screen.
 
The new revelations about UPDs and FAT32, resulting in the jiggery-pokery to convert it to Ext2, seem to have solved the problems and ntpclient seems to be working now. I will keep an eye on it, but unless I report otherwise readers can assume it's a runner.
 
I've lost my clock again, so I thought I would try forcedate. Here is the log output:

Code: 
>>> Contents of /var/log/forcedate.log 224.00 bytes
/var/lib/humaxtv/mod/xinit.d/forcedate: line 6: date: not found
/var/lib/humaxtv/mod/xinit.d/forcedate: line 7: /var/lib/humaxtv_backup/mod/setclock: not found
/var/lib/humaxtv/mod/xinit.d/forcedate: line 8: date: not found

Would this have anything to do with my CF still being 1.14? Or with my custom software running from an Ext2 UPD?
 
Update

I would like to get to the bottom of this if we can. I have forcedate and ntpclient installed, and the CF is up-to-date at 1.17 (HD-FOX).

My forcedate log says:

Code: 
>>> Contents of /var/log/forcedate.log 224.00 bytes
/var/lib/humaxtv/mod/xinit.d/forcedate: line 6: date: not found
/var/lib/humaxtv/mod/xinit.d/forcedate: line 7: /var/lib/humaxtv_backup/mod/setclock: not found
/var/lib/humaxtv/mod/xinit.d/forcedate: line 8: date: not found

(my line breaks)

What usually happens (at the moment) is no TV Portal unless I do a hard reset, or issue a date command by Telnet. The screen saver clock is usually wrong or stalled at 00:00:00, and the iPlate date/time is stuck in 1970. If I warm start and the reboot fails (as it so often does if only turned quickly off and on) it's back to square one.

I will experiment with telnetting date immediately after boot - some time ago I found this would set everything correctly if soon enough after boot - but I'm being pulled away at the moment...
 
Something is wrong with the forcedate package, or your installation of it.. I'll have a look tonight.
 
You must log in or register to reply here.
Back
Top