Forums

Hi,

Following the weekend Daylight savings changes to the local time normally the time on my receivers updates automtically. I have three Zgemma H9Combo's and two have updated okay but the third is an hour behind. I noticed that it will not update automatically from the internet and when set to look at the transponder it is always one hour behind. I can overwrite the time using the date -s command but will not read the time from pool.ntp.org.

Thanks 

Are you sure that pool.ntp.org can also be reached for that receiver, perhaps something is not set up correctly in the DNS settings?

More testing:-

Time zone Area > Europe

Time Zone > London

Time Synchronisation method > Internet (ntp)

NTP Hostname > pool.ntp.org

So I set the time from telenet to say 09:00

Box updates to 09:00

Flick between channels BBC One / Two (Astra 2 Satellite)

Box updates the time to 11:00

So it is -1 hour out and it looks like it is applying an offset. I cannot tell where the update is being applied from but I am assuming it is from the Transponder even though it is set to 'Internet' rather than 'Auto'.  

9.0-release has a bug that causes transponder time not to be disabled with you select "ntp", so basically "ntp" behaves the same as "auto". Which is why you get transponder time now.

Being able to ping says nothing about being able to make an ntp connection, for that UDP port 123 needs to be open.

You can check what the box is doing using

grep ntp /var/log/messages

the box itself uses

/usr/bin/ntpdate-sync silent

to do a time update, using the configuration in

/etc/default/ntpdate

Check the setup for your time settings, you can decide to only use NTP, or only use the Transponder Time or use both.

It is probably better to use NTP only.

@Pr2,

Time Synchronisation method > Internet (ntp)

NTP Hostname > pool.ntp.org

Is already set correctly.

That's good, that means ntp works fine, it picked up the correct time from NTP 11 seconds after the box started.

The box uses /etc/timezone:

root@ustym4kpro:~# cat /etc/timezone 
Europe/London

root@ustym4kpro:~# date
Tue Apr  2 13:11:32 BST 2024

Is this set correctly? Does it report the time in BST ?

That is EXTREMELY weird. At least, it explains the issue you have.

The question is now, WHY? I have to think about that. I assume restarting the box doesn't fix it?

Does the zoneinfo file exist?

root@ustym4kpro:~# ls -l /usr/share/zoneinfo/Europe/London
-rw-r--r--    1 root     root          1599 Apr 28  2023 /usr/share/zoneinfo/Europe/London

That's the problem found.

For some reason, the file size of the zoneinfo file is zero. That can be fixed by

opkg install tzdata-europe --force-reinstall

but it begs the question what has caused this, and what else is corrupt.

I'd flash the box again, from the menu so you can make a backup on USB before the flash.

Unless you have installed all sorts of stuff manually (i.e. not from the plugins download), this will bring your box up after the flash automatically.
 

So why did it not fix it? It should just replaced the corrupt files with the correct ones. What was the output?

Nothing else uses the files, only the OS, which reads the file /etc/timezone is pointing to.

 

So that has fixed it, thanks. Of the files in the /zoneinfo/Europe folder three were showing as 0 filesize, London, Paris, Moscow. Now I have been doing some experimenting to try and force things to work so I may have tried those other time zones, I can't say for certain. Even so, I wouldn't expect them to become corrupted simply by a setting change?

 

 

It did fix it, thanks. Apologies, bit of a waffling reply. I was just thinking about testing it fully and determining the cause.

I'm lost.

You wrote the reinstall didn't fix it, and manually copying files did. So that wasn't true?

Just trying to understand what the problem was.

You wrote the reinstall didn't fix it, and manually copying files did.

 

Yes that's right.

In which case this is still a valid question:

So why did it not fix it? It should just replaced the corrupt files with the correct ones. What was the output?

 

Nothing else uses the files, only the OS, which reads the file /etc/timezone is pointing to.