Time Standard

[Black Hole]

Does the time correct itself if you power cycle the Humax?

Having seen that the time offset does not change much with a warm start, I deliberately performed a cold start and the screen saver clock is now 2 secs behind MSF.

Particularly for users of padding, it would seem to be necessary that the internal clock gets synced to EPG regularly (via a cold boot), otherwise recorded consecutive programmes are more likely to get splt in the wrong place. This could be a reason to install ntpclient even with an aerial connected!

 

[Ezra Pound]

I think it may be possible to persuade the Humax to extract the correct time from the TV signal during every warm re-start, by resetting the time kept in the front panel clock display just before the humaxtv process starts

 

[Black Hole]

It seems a remarkable oversight that this is not done already, seeing that the normal use is never or rarely to have cold starts. I think we might go so far as to classify this as a bug, but on the other hand if it were to attempt a clock sync each boot it could have adverse effects when operating 100% aerial free (LOL).

 

[4291]

Just out of interest I have given my HD-FOX a cold start (hands and knees job) and my screen saver is now 2 seconds slow. It was 36 seconds fast.

 

[af123]

I think it may be possible to persuade the Humax to extract the correct time from the TV signal during every warm re-start, by resetting the time kept in the front panel clock display just before the humaxtv process starts

That would be easy enough to implement as an optional package..

Most UNIX time sync programs actually adjust the speed of the internal clock so that over time it corrects itself (the logic being that it is better than a sudden clock jump) so maybe that's what they are doing? Since the Humax isn't generally on all of the time that wouldn't be a suitable approach here. I might try setting the Micom clock wrong by 30 minutes and see what it does.

 

[4291]

Interesting observation: Doing the cold restart from standby has caused the Humax to come on in the half-awake state mentioned elsewhere.

 

[Ezra Pound]

Most UNIX time sync programs actually adjust the speed of the internal clock so that over time it corrects itself (the logic being that it is better than a sudden clock jump)

In Telecoms. it's called Equipment Clock Hold Over, where the internal clock is compared to the network clock and the difference in parts per million is stored locally, this is then used to slowly 'drift' the local clock towards network clock and the PPM value is added to the local clock's timing

 

[Andrew Benham]

Most UNIX time sync programs actually adjust the speed of the internal clock so that over time it corrects itself (the logic being that it is better than a sudden clock jump) so maybe that's what they are doing? Since the Humax isn't generally on all of the time that wouldn't be a suitable approach here. I might try setting the Micom clock wrong by 30 minutes and see what it does.

A Humax isn't generally on all the time. When it is on, it may not be on t'Internet, and it may not have an antenna connected. Makes it a little harder.

Do we get events on the Humax when network interfaces go up and down ? My Debian boxes (re)start ntp when an interface is brought up. Actually they run ntpdate to get the time fairly close, and then run ntpd to get the accurate sync.

 

[Brian]

I have noticed that both of my HDR-FOX T2's are displaying the wrong time on their front panel display whilst in standby, one is 42 seconds fast and the other is 150 seconds fast.

How often do they check and update the time?

I should add that the first box was last in use yesterday to record and watch a few programmes, but the second box has not been on for a few days, although it has made a couple of scheduled recordings this morning. Both boxes are running "disable-ota" just in case this is relevant.

 

[Ezra Pound]

It was originally thought that the Humax corrected it’s clock every time it was switched out of standby, by getting the correct time from TV transmitted data, however the latest thinking is that this only occurs after a cold start e.g. a when the mains power supply is switched off and then back on. I think af123 was looking into forcing the Humax to update the time every time Humax is switched from standby. I don't think this 'problem' is caused by the use of disable-ota

 

[grahamlthompson]

I have noticed that both of my HDR-FOX T2's are displaying the wrong time on their front panel display whilst in standby, one is 42 seconds fast and the other is 150 seconds fast.

How often do they check and update the time?

I should add that the first box was last in use yesterday to record and watch a few programmes, but the second box has not been on for a few days, although it has made a couple of scheduled recordings this morning. Both boxes are running "disable-ota" just in case this is relevant.

If you boot them does the time correct itself ?

 

[Brian]

Thanks for the replies, I have powered the second box out of standby and left it for a few minutes before returning it to standby, and the clock display is now 3 seconds slow. This would suggest that the clock does get corrected when switched out of standby, but not during scheduled recordings.

 

[grahamlthompson]

Thanks for the replies, I have powered the second box out of standby and left it for a few minutes before returning it to standby, and the clock display is now 3 seconds slow. This would suggest that the clock does get corrected when switched out of standby, but not during scheduled recordings.

We already know the box doesn't update the epg during padded recordings. I would think an AR one would update the time during the pre 15 minute boot. You will have to wait till it drifts to find out

 

[Brian]

We already know the box doesn't update the epg during padded recordings. I would think an AR one would update the time during the pre 15 minute boot. You will have to wait till it drifts to find out

I Only use AR on my boxes so have already found out that the time is not being updated during the pre 15 minute boot of a scheduled recording from standby. I thought that I had read somewhere that the time was updated during the 04:30 OTA check, which is why I mentioned that my boxes are running "disable-ota". Perhaps I should remove this and see how things go over the next few days.

 

[grahamlthompson]

I Only use AR on my boxes so have already found out that the time is not being updated during the pre 15 minute boot of a scheduled recording from standby. I thought that I had read somewhere that the time was updated during the 04:30 OTA check, which is why I mentioned that my boxes are running "disable-ota". Perhaps I should remove this and see how things go over the next few days.

Interesting, how about a short daily repeating manual watch only reservation (I have one already on a HD FOX T2 and not noticed any time drift)

 

[Brian]

Interesting, how about a short daily repeating manual watch only reservation (I have one already on a HD FOX T2 and not noticed any time drift)

I think that I will remove "disable-ota" and see how things go first, as I don't remember having this issue previously.

 

[Ezra Pound]

If removing disable-ota does fix the problem, you could replace it with a daily reminder from 4:20am to 4:40am as this looks like it also prevents ota and also updates the EPG when you are on holiday

 

[Brian]

I don't need disable-ota any more as I have updated manually to the latest firmware and CF, and my EPG gets updated during the pre AR boot.

 

[af123]

It makes sense to me that a reminder would quash the auto-update.
With the reminder in place the Humax would never see a wake-up as a result of reason 2 (which is the OTA trigger - look in the setup database).

 

[Black Hole]

My HDR clock is currently a second and a half fast, but I did a cold start only yesterday. I have OTA check disabled by reminder (rather than software) so I'll monitor how things drift over the next few days.