1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

On board Clock

Discussion in 'HDR-FOX T2 Freeview Recorder' started by GrahamS, Jul 30, 2013.

  1. prpr

    prpr Well-Known Member

    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.
     
  2. xyz321

    xyz321 Well-Known Member

    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.
     
  3. Black Hole

    Black Hole Well-Known Member

    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.
     
  4. prpr

    prpr Well-Known Member

    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.
     
  5. Black Hole

    Black Hole Well-Known Member

    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)?
     
  6. Black Hole

    Black Hole Well-Known Member

  7. af123

    af123 Well-Known Member

    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/

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

     
  8. Black Hole

    Black Hole Well-Known Member

    How does that actually work??
     
  9. prpr

    prpr Well-Known Member

    I don't use the custom portal, but the answer to the other questions is yes, they are all exactly in sync.
     
  10. af123

    af123 Well-Known Member

    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)
    
     
  11. Black Hole

    Black Hole Well-Known Member

    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).
     
  12. GrahamS

    GrahamS New Member

    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!!
     
  13. Ezra Pound

    Ezra Pound Well-Known Member

    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
     
  14. Black Hole

    Black Hole Well-Known Member

    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/
     
  15. GrahamS

    GrahamS New Member

    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!!!
     
  16. af123

    af123 Well-Known Member

    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.
     
  17. GrahamS

    GrahamS New Member

    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.
     
  18. prpr

    prpr Well-Known Member

    You amaze me. How is it our bloody fault?
    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.)
    You're a troll. Go away (and you Brian if you don't like the tone of this message).
     
    Wallace and 4291 like this.
  19. MikeSh

    MikeSh Well-Known Member

    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.
     
    Luke likes this.
  20. Ezra Pound

    Ezra Pound Well-Known Member

    GrahamS : You don't appear to want help getting a problem fixed, you just want an argument. Why don't you fire off a few E-Mails to Humax and see where that gets you - Bye
     
    af123, Wallace and 4291 like this.

Share This Page