• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Mod: ntpclient

It might take longer to acquire a valid Internet time. Separately, there may be an issue with ntpclient too, it may try before the network is fully up.
 
Can you try the updated forcedate? I still think something went wrong with the installation of the original, which the upgrade should fix, but this has a couple of tweaks too.
 
Here are some results from my fiddling:

As found, system date and time were current and the TV Portal worked, but the iPlate was frozen at 00:00 01/01/1970 and the screen saver clock stalled at 00:00:00.

I uninstalled forcedate and ntpclient.

I tried a "S90settop restart" but it didn't change anything.

I then took power off at the wall for a couple of minutes and then did a cold start, and as soon as I could get Telnet access checked the system date (01/01/2000). I then put in the real date and time. With the system fully booted the iPlate showed current time and date (and incrementing), screen saver clock showed current time (and incrementing), and the TV Portal worked.

Then I did a warm restart (standby for a couple of minutes), and had the boot failure (goes through the Humax splash screen and then falls back to standby). Clearly it needs to be in standby for more than a couple of minutes. The front panel clock (in standby) still showed the correct time. Went away, did a couple of chores, came back (about 5 minutes) and did another warm start - booted OK this time, iPlate still intact, Portal OK, screen saver OK (talk about watched pots!).

Next I did a hard reset (from power on). It booted, but the iPlate was back to 00:00 01/01/1970 (frozen), no TV Portal, system time/date 00:00 01/01/2000 (and counting), screen saver 00:00:00 (frozen). Updating the system clock by Telnet did not get the TV Portal back this time round, presumably because it was done some time after the system booted.

I've found out the system time is preserved in standby and warm start, so try that (standby for about 10 minutes). Now it gets really interesting: iPlate 01/01/1970 with time incrementing... not from the time of the warm start but from (I think) the cold start! Screen saver clock also showing the same time (ie 00:00:00 would have been the cold start event). No TV Portal of course. Even weirder, the system time shows 01/01/1970 (not 2000), with the time the same as the iPlate and screen saver.

It's like the Humax software is maintaining yet another source of time that resets to 1970 and increments from a cold start, which it uses to initialise the system clock under certain circumstances (whereas the Linux initialises to 2000 if it gets the chance).

I'm pretty confused at the moment and will have to have another look at this with a clearer head. If anybody would care to repeat my results (a necessary part of any scientific investigation) I'm using an HD-FOX (HDR-FOX may or may not respond the same) and the aerial needs to be unplugged.

The relevant Telnet incantation to set the system clock is "date yyyy.mm.dd-hh:mm".
 
Beedin'eck, get this: out of sheer frustration I put the right date-time in again (with the system in the state last mentioned above) - and the iPlate and screen saver updated to the correct date-time without any other intervention! BUT... no TV Portal!!!
 
...and after being in standby overnight and warm started this morning, everything is in sync complete with TV Portal.
 
I'm running without the helper packages at the moment, trying to get a firm understanding of what's going on. Fiddling about with the LAN caused a spontaneous reset for some reason (I had the HD directly wired to the HDR at the time, and cycled the HDR through standby - of course that wasn't going to work because I have them set to DHCP), and the iPlate and screen saver is back to 00:00 01/01/1970 (frozen) and the system time reset to 01/01/2000 (counting). I have manually updated the system clock, and if my deductions are correct the rest of the system should pull back in over the course of one or two warm starts (if cycled not too quickly).
 
News flash: in fact, the clocks have sync'ed after one warm start this morning (having been put into stand-by after my viewing last night).

I will have to try it again, but previously when I set the system clock and then performed an "S90settop restart" it did not take, so I presume a software restart is not quite the same as a warm restart.

I aim to work out what a helper package needs to do to be reliable, I will look at the new versions of ntpclient and forcedate soon(ish).
 
Everything's been fine until the HD-FOX did a hard reset while I was fooling around with the move/copy menus, now (without further reboot) the screensaver is stalled at 00:00:00, i-plate stalled at 00:00 01/01/1970, and the system clock is 01/01/2000 and counting.

Restored system clock, rebooting now.

There's interesting, look you. I didn't notice the standby (LED) clock when I set stand-by, but before I powered up again the standby clock was correct. Having rebooted, everything is in sync.

The questions in my mind are these: Does the standby clock get its time from the system clock? Under what circumstances do the screensaver and i-plate clocks refresh from the system clock? It is possible the i-plate clock only looks for a source of time if it is detected at its reset state (1970) at boot.

Not that it matters terribly, because the TV Portal seems to use system time, but it seems to me that the sequence required to synchronise time throughout the HD-FOX is:
  1. Hard reset
  2. Set up system time
  3. Reboot through stand-by (at least a few minutes off)
 
Another incident last night: boot failure and then I did not leave it long enough before trying the warm start - boot failure again. The front panel showed the correct time even after the second boot fallback. I applied the trick which I know will start it up immediately after the fallback - press the front panel on/off button (I'm talking HD-FOX here) but which I know results in the time getting screwed up. Sure enough: i-plate time stuck at 1970, frozen screen saver, no TV portal (which means out-of-date system clock) - none of which mattered for my networked link to the HDR. Some time in the night I woke up again and put the HD-FOX into standby.

Now the really weird thing which I'm having trouble coming to terms with: this morning I powered up (warm start), and the i-plate is correct, the screen saver is correct, and the TV portal runs. I do not have forcedate or ntpclient running, and I am on CF1.17. It's like not only being shown evidence for the existence of God, but being given his phone number.

This goes against everything I have worked out so far. The only thing I can think of is that somehow having a Samba connection to the HDR has provided a source of time?
 
I have some more information that might be relevant but I will need to see if works in the same way with the HD model.

The HDR front panel contains a self-contained microprocessor which runs even when the main Humax software is not. It appears to be responsible for at least:
  • displaying the clock (if not in power saving mode);
  • detecting power-on from the remote control;
  • waking the box up ready for a recording;
  • putting the box into standby;
  • controlling the various LEDs.
Why am I posting this here? When the Humax goes into standby, it programs the clock in the front panel with the current time. The front panel uses this to display a clock if necessary. It is possible to query the current time back from the panel so we could read it at boot and use it to set the system time accordingly. It's actually something they are looking at doing for the Foxsat over at avforums although I don't know the driver there.

Now, the HD model doesn't have a clock (does it?) but the hardware might operate in the same way and act as a place to save the current time. It isn't going to survive a cold boot though.
 
af123 said:
The HDR front panel contains a self-contained microprocessor
Click to expand...

If you could monitor the 'REC' icon on the front display and then force the centre LED to be Red, You would make a lot of people very happy I think ... Sorry back to topic
 
af123 said:
Now, the HD model doesn't have a clock (does it?) but the hardware might operate in the same way and act as a place to save the current time. It isn't going to survive a cold boot though.
Click to expand...
Yes, the HD model does have a clock.
 
af123 said:
When the Humax goes into standby, it programs the clock in the front panel with the current time. The front panel uses this to display a clock if necessary. It is possible to query the current time back from the panel so we could read it at boot and use it to set the system time accordingly. It's actually something they are looking at doing for the Foxsat over at avforums although I don't know the driver there.
Click to expand...
The Foxsat HDR uses /dev/ttyS64 for reading the time from the hardware clock. This was determined by monitoring system calls from the settop process during startup using the strace utility. Adrianf36 has since written a small utility which reads epoch time from the hardware clock and sets the system date/time prior to settop startup. This functionality was needed to determine if it was the 3.a.m. housekeeping task, in order to run some scripts prior to settop start. I'm sure Adrian would provide sources if you feel they would be helpful to you.
 
Anybody got any ideas that might explain the sudden reincarnation of system time (front panel clock display while in standby not withstanding), when all prior experience says that the boot failure scenario results in a dead i-plate and screensaver clock (which it did) and the failure of the TV portal indicates lack of system time?
 
raydon said:
The Foxsat HDR uses /dev/ttyS64 for reading the time from the hardware clock.
Click to expand...

It's the same as on the T2, just a different device name. Adrian sent me his source code and it's very similar to mine. He's reading the clock from the same place, the standalone microcomputer that controls the basic functions (rather than a battery-backed system clock).

Thanks for explaining why he needed to do it!
 
Black Hole said:
Anybody got any ideas that might explain the sudden reincarnation of system time (front panel clock display while in standby not withstanding), when all prior experience says that the boot failure scenario results in a dead i-plate and screensaver clock (which it did) and the failure of the TV portal indicates lack of system time?
Click to expand...

This behaviour is confirmed. I had a HD-FOX boot failure night before last (I turned it off when I was expecting to turn it on, didn't wait long enough to turn it back on again (it needs a good 5 minutes at least) and it did its stall routine - only easy way out being to turn on again instantly it drops back to red light) and wound up with dead clocks and no TV Portal.

The HD- was then on overnight, off for a day, and then when turned on again the following night all the clocks were restored (regrettably I did not notice whether the front panel time display was correct before turning on).

I have checked the installed packages and neither ntpclient nor forcedate are listed. Is there anything I should do at the command line to confirm that?

Presuming there are no remnants of ntpclient hanging about, the major difference from when I was having system time problems before is the installation of network support. Clearly I shall have to resort to uninstalling CIFS and running a few trials.
 
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!
 
hmm... I had a crash 13hrs 4 minutes ago (its been counting from zero) (HDR-FOX)
The last time that happened was on one of my OAP's boxes and that reset itself overnight.
My box has the latest redring for the clock display - could that be affecting an auto update on the clock?

The settings in the menu give the correct time - its just the front panel thats wrong. (is there a manual way to reset it?)
 
You must log in or register to reply here.
Back
Top