Date and Time is wrong and I can't fix it

[NinjaFromNZ]

This morning in New Zealand I found that the date/time is wrong. It is fixed a little over three days ahead of the correct time

I've tried transponder time from different sources (terrestrial and satellite) by changing the bouquet order and also use the NST services from a number of time servers and it makes no difference. Changing time zone does change the displayed time

When I try to change the date & time manually, the change doesn't stick. Here are some examples (what I type is in normal text, system responses are in italics):

# date

Wed May 13 16:38:34 NZST 2020

# date 2020.05.10-13:45:00

Sun May 10 13:45:00 NZST 2020

# date

Wed May 13 16:39:17 NZST 2020

Can anyone suggest a fix?

 

[x-xxxA]

Try this:

add
config.misc.useTransponderTime=false
to "/etc/enigma2/settings file.

run the command "rdate -s time.nist.gov"
Now the time is displayed correctly.

 

[NinjaFromNZ]

I've just tried that but I get this when I type in

rdate -s time.nist.gov

rdate: command not found

 

[NinjaFromNZ]

In case it matters, config is

Vu+ Duo4K
System OE: OE-Alliance 4.3
Firmware version: openbh 4.3.026 (2020-04-23)
Kernel / Drivers: 4.1.45 / 20191218

 

[AlexWilMac]

In OBH there's a NTP server: have you ever explored the function? There's no need of strange ways of only to rely on transponders.
Menu Setup /Time.
Choose "Sync time using": NTP and set also the interval in syncing (30 mins or more).
To be sure, restart GUI.

 

[NinjaFromNZ]

Yes, I have that configured, I have also tried ntupdate from the command prompt.

I suspect something is setting the date forwards by just under three days and I can't work out what

If I need to reflash and preserve my settings/timers/autotimers etc, what's the best way to do so?

 

[AlexWilMac]

Before that, I'd also check, to be sure, which is the channel number 1, that means the first channel in first bouquet, because is the one used for the transponder time.
Then, even if I've never had issues with NTP, set the sync method to transponder time. In case you may try and change the channel number 1 (hoping you have you preferences set to number channels in your bouquets continuously).
Channels may be saved in many way, starting from the OWIF (the web interface and its Bouquet Editor), or by specific software for your O.S.
Also, you may use the Personal Settings Backup, although I much rather save my files (timers, autotimers) manually: they are all within this folder:
/etc/enigma2/

 

[NinjaFromNZ]

I've worked in IT support in the past and I've had users utter those words "I did nothing and the problem went away..." and not believed them

I spent most of yesterday

• fiddling with the NST and Transponder options in the Time settings
• trying over and over again to change the system date (and failing)
• rebooting the box multiple times
• restoring prior versions of backups

I went to bed last night (on Sunday my time) shortly after midnight - and the STB was showing a time of 3am on Thursday 14th May

This morning (Monday) at about 7:30am the box was showing.... 7:30am on Monday morning

I don't know what happened overnight but "I did nothing and the problem went away..."

 

[AlexWilMac]

I know the feeling and I understand you want to know what was that fixed the issue.
Is it active (and was it while you were sleeping ) the NTP sync method? Or was back set to Transponder time?
In this second case, it must've been the transponder to be "fixed" and to give now the right time.
In the first, maybe the NTP server was not accessible and so the syncing didn't succeed. I've never changed the NTP server under OBH but maybe trying another one you would solve before.
Unfortunately, this time we'll never know for sure what happened and I understand how frustrating is having spent a lot of time without having any certain clue in case of future problems.

 

[NinjaFromNZ]

I had the time settings using NTP but I don't think it came to life during the night because one other thing I tried was

ntpdate -u <nst server set in the time settings page>

and this seened to change the time, but executing the date command immediately afterwards, the box reckoned that the date was still Thursday

I suspect I'll never know

 

[wedgehog]

Don't mean to hijack thread but I just wanted to mention I noticed the time was wrong on mine yesterday and when I looked it was set to Europe London which is correct but of course it's an hour out because there is no provision for British summertime and GMT, I have had to set mine to Erie in Ireland to get the correct time?

 

[AlexWilMac]

Was it a question or an exclamation? (!!!)

 

[Mick12334]

There are other threads, regarding this subject, and the fix, for europe.
Just start up the VUCC, VU+ Control Centre. on your PC, or other telnet option, connect to your receiver, then copy, and paste, this line:
opkg install --force-reinstall tzdata tzdata-core tzdata-europe

 

[NinjaFromNZ]

I had the power supply fail on me today and didn’t notice for a while

when I replaced it, I discovered that this time issue has happened again

grrrrr

 

[NinjaFromNZ]

This has now been the case for the last 24 hours.

Does anyone in the know have any idea what other processes might be messing with the time in OpenBlackHole or any suggestions how I can fix this?

I'm running:
System OE: OE-Alliance 4.3
Firmware version: openbh 4.3.026 (2020-04-23)
Kernel / Drivers: 4.1.45 / 20191218

Time is currently configured to use NTP but I've also tried transponder time with Channel 1 set both to a DVB-S channel and a DVB-T channel

When executing the date -s command through a telnet session, it executes successfully but if I check the date immediately afterwards it shows the wrong time

This is an example of what happens when using ntpdate against a local New Zealand NTP server, followed by using the date command to verify the system date

>> ntpdate -u nz.pool.ntp.org
28 Aug 16:54:32 ntpdate[5575]: step time server 103.239.8.21 offset -363025.834373 sec

>> date
Tue Sep 1 21:45:01 NZST 2020

The System keeps adding 4 days, 4 hours and 50 minutes to the actual time which means I'm unable to schedule any recordings

 

[AlexWilMac]

Maybe you can find a different ntp server. Even if I have never had any time issue with OBH, I'm using now a ntp server of our national institute for metrics and standards.
You might try something similar and reliable.

 

[NinjaFromNZ]

The thing that makes me think it’s not the NTP server is that when setting the time from the command line it immediately gets changed to be wrong by some other process

if it was the OBH time keeping mechanism I’d expect it to take up to 30 minutes to be reset

I can correct the time 3-4 times in a row from the command line and it always gets changed back to be wrong by something else

However, last night I succeeded in correcting the system time. Since I was trying so many things I can’t be sure what it was that fixed it unfortunately

 

[NinjaFromNZ]

It's changed back to be wrong again. This is so frustrating. It's not a timezone issue as its several days wrong.

Does anyone know Blackhole, Enigma2 and/or linux to suggest if there's anything I can do to log any process that mightr be changing things?

I've also changed the NTP server from pool.ntp.org to be nz.pool.ntp.org and will wait and see how that goes

 

[AlexWilMac]

That was the only try you should do from the beginning, although I've never had any issue with time in OBH. But maybe the original ntp server was not perfect for your zone.
It was exactly the fact that, after adjusting the time by those commands, it got back to another one, that suggested the time syncing occurred using the NTP server, regardless of the time interval set.
As an alternative (in case the new NTP server wouldn't work), you might try no to use the NTP syncing OBH offers, use the transponder one, give the commands and see what happens.

 

[NinjaFromNZ]

Channel 1 is set to a Sly channel
Time source set to Tramsponder

Entered this command
ntpdate -u pool.ntp.org

response is correct local date/time

issued this command
date

response is next Wednesday