On board Clock

Black Hole said:
In which case you can say whether the screen saver clock picks up your hourly clock corrections or proceeds on its own merry way between boots.
Click to expand...
The screen saver obviously picks up the system time. What else would it use?
As it's now synced once an hour, it is to all intents and purposes always correct.
Likewise anywhere else the time is used in the humaxtv app.
 
Would it not be better to go the whole hog and install a cut down ntpd server? Using ntpclient to sync every hour is likely to cause the time to "jump" each time which may have unforseen consequences for the humaxtv app. An ntpd server app. will slew the time which will avoid any discontinuities.
 
prpr said:
The screen saver obviously picks up the system time. What else would it use?
As it's now synced once an hour, it is to all intents and purposes always correct.
Likewise anywhere else the time is used in the humaxtv app.
Click to expand...
Do you know that for sure or are you making an assumption? When I was playing with this stuff on an HD-FOX, I discovered it is possible to have the screen saver clock frozen at 00:00:00, and since I presume it is not possible to have the system time frozen that implies the screen saver clock is not simply the system time being queried and displayed. There are at least three time systems in an HD-FOX (to what extent they are interrelated is unclear), for more info check out the ntpclient topic.
 
I don't know for sure as I don't work for Humax or have access to their code, but just based on my own observations. This is also on an HDR, not an HD as I don't have the latter.

To answer xyz321, while there might be problems with steps in time, I haven't seen any and I've been running it like this for 6 months or so. Syncing once an hour means it never gets more than about 0.25 seconds out anyway.
 
Easy observation: is the screen-saver clock in sync with the front panel clock and the time displayed on the i-plate, and also the time displayed by the custom portal (only the screen saver clock and the custom portal time display actually show seconds)?
 
xyz321 said:
Would it not be better to go the whole hog and install a cut down ntpd server? Using ntpclient to sync every hour is likely to cause the time to "jump" each time which may have unforseen consequences for the humaxtv app. An ntpd server app. will slew the time which will avoid any discontinuities.
Click to expand...

You're right, but the packaged ntpclient is up to the job.

The ntpclient that is packaged is the one at http://doolittle.icarus.com/ntpclient/

ntpclient is an NTP (RFC-1305) client for unix-alike computers. Its functionality is a small subset of xntpd, but IMHO performs better (or at least has the potential to function better) within that limited scope. Since it is much smaller than xntpd, it is also more relevant for embedded computers.
Click to expand...

The package (now) runs ntpclient with the -l option.

On to ntpclient -l. ... It will make small (probably less than 3 ppm) adjustments
to the system frequency to keep the clocks locked. Typical performance over
Ethernet (even through a few routers) is a worst case error of +/- 10 ms.
Click to expand...
 
Black Hole said:
Easy observation: is the screen-saver clock in sync with the front panel clock and the time displayed on the i-plate, and also the time displayed by the custom portal (only the screen saver clock and the custom portal time display actually show seconds)?
Click to expand...
I don't use the custom portal, but the answer to the other questions is yes, they are all exactly in sync.
 
Black Hole said:
How does that actually work??
Click to expand...
It makes adjustments to the clock that runs while the system is booted (not the one in the Micom). I can see it working in my ntpclient.log. When the box goes into standby, the Humax software sets the Micom clock to the same as the system one and then the Micom keeps time. On restore from standby, the time from the Micom is retrieved by the Humax software and used for the system time going forward. Micom isn't great at keeping time and tends to drift.

Code: 
# box [( 0.904 , 106505.6 )  ( 32.213 , 245529.7 )]  delta_f -18.955  computed_freq 1242255
41484 78945.511  41595.0    142.9  176017.7  28717.0        0
# box [( -18.641 , 107579.5 )  ( 15.955 , 255102.7 )]  delta_f 0.000  computed_freq 1242255
41484 79545.522  41321.0    397.5  185820.3  37719.7  1242255
# box [( -16.442 , 120690.5 )  ( 17.543 , 266581.3 )]  delta_f -3.973  computed_freq 1502624
41484 80145.537  44694.0    278.7  194598.6  30014.0  1242255
# box [( -19.698 , 121855.7 )  ( 16.580 , 278454.6 )]  delta_f -0.911  computed_freq 1562353
41484 80745.551  43469.0    164.8  203541.4  39016.7  1502624
# box [( -16.321 , 148084.0 )  ( 15.829 , 284699.3 )]  delta_f -8.660  computed_freq 2129869
41484 81345.565  41474.0    108.8  216391.7  27633.7  1562353
# box [( -25.625 , 133108.2 )  ( 9.469 , 289918.9 )]  delta_f 0.000  computed_freq 2129869
41484 81945.586  42569.0    132.5  211513.5  36636.4  2129869

and confirm that the current frequency adjustment is 2129869..

Code: 
humax# /mod/sbin/adjtimex
    mode:        0
-o  offset:      0
-f  frequency:    2129869
    maxerror:    16384000
    esterror:    16384000
    status:      64 ( UNSYNC )
-p  timeconstant: 2
    precision:    1
    tolerance:    33554432
-t  tick:        10000
    time.tv_sec:  1375311043
    time.tv_usec: 270579
    return value: 5 (clock not synchronized)
 
I'm having trouble getting my head around that, possibly because of the way it is written up. I don't understand how the software can adjust the hardware frequency, unless it is able to access the divider ratio settings (which I would have thought are fixed in hardware based on the nominal crystal frequency).
 
Having 3 HDR-Fox T2 Recorders exhibiting the same ridiculous time keeping problems i.e gaining approx 10sec per day, and to turn off/on to sync with with DVB data stream to set correct time, strikes me as bizarre. These m/cs are the epitome of the classic "curates egg", good in parts but rubbish in others, and although the basic user interface is attractive and user friendly, there are many procedures that are restrictive and unhelpful.

Those, on this forum who eulogise this m/c, are in denial of its deficiencies, and should start hammering Humax for a positive response to the failings that are clear for all to see; that's if you can actually log into their Help page, which for many weeks has had "No Entry"symbols prominently displayed!!
 
Nothing in life is perfect, including the Humax HDR-Fox T2, you have to find the PVR with the least things wrong with it or the one where problems will actually be fixed, either by the maker or the products users. If you think you can get someone at Humax to fix the things about it you don't like, go ahead. If you find that approach doesn't work (and I think you will), then maybe you will find a use for the Custom Firmware
BTW
The Custom Firmware has a fix for the drifting clock
 
We are enthusiasts for the HDR-FOX because we have learned to work around the deficiencies. Other PVRs have deficiencies with no means to work around them. The clock errors are largely irrelevant, and I have discovered the clock resyncs from a cold start, or if the difference between system clock and EPG clock accumulates to a minute either way.

If it bothers you that the screen saver time isn't quite the same as real time, the custom firmware offers the ntpclient package to sync the system time to an Internet source each boot.

I suggest you look at Things Every HDR-FOX Owner Should Know (click), and the topics about system time here: http://hummy.tv/forum/threads/mod-ntpclient.710/
 
You people amaze me!! The fact that the unit does not keep time with DVB data stream and that you are prepared to accept this as a minor problem is, frankly, gob smacking. I admit that nothing in life is perfect, but this is a major fault, and both of you so called gurus are prepared to pass this off as working around deficiencies!!!
 
GrahamS said:
You people amaze me!! The fact that the unit does not keep time with DVB data stream and that you are prepared to accept this as a minor problem is, frankly, gob smacking. I admit that nothing in life is perfect, but this is a major fault, and both of you so called gurus are prepared to pass this off as working around deficiencies!!!
Click to expand...
Different units exhibit different rates of clock drift. My main box doesn't drift more than a few seconds a month. If it ever drifts more than a minute then it will automatically resync to the DVB stream although it would be nice if it did it on every boot or even just periodically when turned on.

You could always ask Humax to replace it under warranty if it is drifting that much.
 
Please be more explicit. My units can drift forever without auto sync, which means I cold start every Monday, Wednesday, Friday and Saturday just for a fighting chance of maintaining some semblance of real time.
 
GrahamS said:
You people amaze me!!
Click to expand...
You amaze me. How is it our bloody fault?
The fact that the unit does not keep time with DVB data stream and that you are prepared to accept this as a minor problem is, frankly, gob smacking.
Click to expand...
What exactly do you expect us to do about it? Humax designed the box. It is their problem. They of course are not interested in fixing anything, like most manufacturers of stuff. You either take it or leave it (or install the custom firmware and an NTP client to keep it in sync.)
I admit that nothing in life is perfect, but this is a major fault, and both of you so called gurus are prepared to pass this off as working around deficiencies!!!
Click to expand...
You're a troll. Go away (and you Brian if you don't like the tone of this message).
 
GrahamS said:
The fact that the unit does not keep time with DVB data stream and that you are prepared to accept this as a minor problem is, frankly, gob smacking. I admit that nothing in life is perfect, but this is a major fault, ...
Click to expand...
How is this a major fault? A minute out - max - is hardly life threatening and will only affect padded recordings, which typically will use enough pad to cover such an error anyway. I imagine most people use AR with these boxes, so the time (within a minute) is irrelevant for any practical purpose.
 
You must log in or register to reply here.
Back
Top