On board Clock

You people amaze me!!
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.
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!!!
You're a troll. Go away (and you Brian if you don't like the tone of this message).
prpr, I do tend to agree with what you are saying. GrahamS, What are you hoping to gain from your membership of this forum?
 
Hi All.

Last gasp help before both Fox t2 PVR's returned for full refund.

I might ramble a bit, but please stay with me.
I understand the causes of lack of EPG update, (Black Hole et al) and that the system clock is dependant on the displayed EPG clock.
My problem is, that although the EPG does indeed update, the EPG clock does not!
I should point out, that at first boot the displayed time/EPG time were synced and equal to radio controlled clock (and my pioneer hdd/dvd recorders) but since then have been advancing by about 10sec per day.
Have done a factory reset on one m/c,:correct time on reset, 10sec per day advance thereafter.
Huge disappointment as, apart from above, excellent vid, straight forward usability.

Only purchased one week ago, so offer of return to Humax turned down. Have been offered full refund unless anybody out there has a magic wand.

Regards GrahamS
Graham, I have merged both of your on board clock threads.
After re-reading your post above, I am a little surprised that less than Two months ago, you were considering returning 2off one week old HDR-FOX T2's for a full refund. Did this happen? and if not, what made you purchase a Third box if they were so bad?
 
Those, on this forum who eulogise this m/c, are in denial of its deficiencies...

Had my box for years and never noticed my clock drifting - maybe I am in denial?!?

Oh well - ignorance is bliss I suppose!

@GrahamS - what fw version do your boxes run? I dont think there are enough people running the latest firmware on this forum to completely rule out the possibility that humax have broken the clock resync on the latest version.


Posted on the move
 
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!!!
I'm still waiting for an explanation of how the screen saver clock drifting affects the functionality of the unit in a major way. Maybe this user bought it to use as a clock rather than as a PVR?

Of course we work around the deficiencies, that's what we are gurus for (what else?). In the absence of a Topfield equivalent, where else can you go for a FreeviewHD+ PVR with an underground developer community?

"Oh Lord, grant to us the serenity of mind to accept that which cannot be changed, courage to change that which can be changed, and wisdom to know the one from the other."
 
Had my box for years and never noticed my clock drifting - maybe I am in denial?!?
If you rarely see the screen saver you probably won't notice. Alternatively, you might have been lucky and got a timing crystal (or ceramic resonator) at the centre of the Normal Distribution bell curve (the operating temperature will also have an effect).
 
The OP says that his carries on drifting forever though - where everyone else says theirs snaps back if it drifts more than 1min?

I don't think I would notice a 1min drift. I dont think any two clocks in my house are within 1min of each other!

I also use AR. I can only assume graham is using padded recording with no actual padding? Thats the only time I think a drifting clock (within a min) would be an issue.

Posted on the move
 
There has to be at least some padding for it to be a padding recording (zero padding = AR), although either the start padding or the end padding could be zero (in which case, what's the point?). The actual broadcast times drift, so the system clock drift would be irrelevant in comparison, and do we know whether padding recordings are timed to the system clock or the EPG clock? AFAIK we don't know.

My clock experiments are conducted in comparison with a radio time code clock (used to be broadcast by MSF Rugby, but I have been told I'm out of date) accurate to a few milliseconds.

The snap-back is an idea I postulated recently following some experiments; I don't know whether people are reposting my hypothesis or whether they have observed the same thing. See here: http://hummy.tv/forum/threads/mod-ntpclient.710/page-3#post-47837
 
My clock experiments are conducted in comparison with a radio time code clock (used to be broadcast by MSF Rugby, but I have been told I'm out of date) accurate to a few milliseconds.
The MSF signal is transmitted from Anthorn Radio Station in Cumbria by Babcock (formerly VT Communications), under contract to NPL.
 
The tourist site Anthorn | Visit Cumbria claims that some digital STBs use the Anthorn time signal.
www.visitcumbria.com/car/anthorn/ said:
The time signal is also used by speed cameras, and by digital set-top boxes.
If that is true I wonder which ones and why. As the digital TV signal will include the time it sounds like an extra production expense.
 
Slightly OT but the reference to the box clock not updating from the broadcast 'clock' puts me in mind of my wife's TomTom (satnav). These rely on millisecond (if not microsecond) time signals from satellites - but on hers at least you have to set the time of day clock manually, if you want it. ?!? (AFAIK it will still work without the clock set.)
I've often wondered why, and maybe it's just not a trivial task, in which case the same thing may apply to DVRs - it's possible but a PITA to actually do.
 
but on hers at least you have to set the time of day clock manually, if you want it.
I can only speak for the TomTom Go series, but with these there is a "sync" option to bring the clock display into line with the satellite datum - and then you have the option to offset the time display (presumably this is how they have chosen to implement local time zones and daylight saving). The clock runs at satellite rate, it's only a question of the user's desired offset.
 
I have had GPS devices from three different manufacturers and they all have an automatic time synch facility. Not only do they synch to the satellite time, they also correct for the difference between UTC and satellite time as GPS time is now ahead of UTC by some 16 seconds. They also do automatic correction for DST.
 
Ditto. As BH stated.
I have two TomTom Go devices. One a first generation, the other a Live 750. Both have the 'sync' option BH mentioned. As a point of fact, my TT Go 750 is in daily use and I can't help noticing that the clock is spot on to the Greenwich Time Signal, AKA the 'pips', when in use. That's OCD for you!
 
The received time data from the satellites is always in GMT (both summer and winter ). The GPS always uses this time internally to do it's calculations, regardless of the time displayed to the user
 
No it isn't. It's not even UTC. It's GPS time. GPS time was zeroed to UTC at 0h 6-Jan-1980. It does not have leap seconds so is now 16 seconds ahead of UTC (GMT). Most (some) GPS devices correct for this, as the time difference (GPS-UTC) is part od the data stream from the GPS system, and display local time with UTC as the reference.
 
O.K. GMT and (GPS-UTC) have drifted apart by 16 seconds over the past 33 Years, my point was more to do with the time being used not switching in and out of daylight saving time which varies from country to country
 
Back
Top