21 replies to this topic

[smith]

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 

[Tech]

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?

[smith]

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'.  

[smith]

root@h9combo:~# ping pool.ntp.org

PING pool.ntp.org (195.171.43.10): 56 data bytes

64 bytes from 195.171.43.10: seq=0 ttl=55 time=31.305 ms

64 bytes from 195.171.43.10: seq=1 ttl=55 time=29.903 ms

64 bytes from 195.171.43.10: seq=2 ttl=55 time=28.532 ms

64 bytes from 195.171.43.10: seq=3 ttl=55 time=28.491 ms

64 bytes from 195.171.43.10: seq=4 ttl=55 time=29.557 ms

64 bytes from 195.171.43.10: seq=5 ttl=55 time=30.905 ms

64 bytes from 195.171.43.10: seq=6 ttl=55 time=28.431 ms

64 bytes from 195.171.43.10: seq=7 ttl=55 time=27.940 ms

64 bytes from 195.171.43.10: seq=8 ttl=55 time=28.113 ms

64 bytes from 195.171.43.10: seq=9 ttl=55 time=30.517 ms

64 bytes from 195.171.43.10: seq=10 ttl=55 time=39.286 ms

64 bytes from 195.171.43.10: seq=11 ttl=55 time=27.175 ms

64 bytes from 195.171.43.10: seq=12 ttl=55 time=27.471 ms

[WanWizard]

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

 

 

[Pr2]

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.

[WanWizard]

@Pr2,

 

Time Synchronisation method > Internet (ntp)

NTP Hostname > pool.ntp.org

 

Is already set correctly.

[smith]

root@h9combo:~# grep ntp /var/log/messages

Jan  1 00:00:11 h9combo user.info kernel: Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)

Apr  2 08:21:56 h9combo daemon.notice ntpdate[1687]: step time server 81.128.218.110 offset +1712046096.635665 sec

Apr  2 08:30:00 h9combo cron.info crond[1716]: USER root pid 1883 cmd /usr/bin/ntpdate-sync silent

Apr  2 08:30:09 h9combo daemon.notice ntpdate[1892]: step time server 185.177.149.33 offset +2.001515 sec

Apr  2 09:30:00 h9combo cron.info crond[1716]: USER root pid 1961 cmd /usr/bin/ntpdate-sync silent

Apr  2 09:30:10 h9combo daemon.notice ntpdate[1970]: step time server 77.104.162.218 offset +2.013473 sec

Apr  2 10:30:00 h9combo cron.info crond[1716]: USER root pid 2039 cmd /usr/bin/ntpdate-sync silent

Apr  2 10:30:09 h9combo daemon.notice ntpdate[2048]: step time server 217.114.59.3 offset +2.011938 sec

Apr  2 11:30:00 h9combo cron.info crond[1716]: USER root pid 2260 cmd /usr/bin/ntpdate-sync silent

Apr  2 11:30:09 h9combo daemon.notice ntpdate[2269]: adjust time server 159.65.53.52 offset +0.020038 sec

[WanWizard]

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 ?

[smith]

root@h9combo:~# cat /etc/timezone

Europe/London

 

root@h9combo:~# date

Tue Apr  2 12:14:06 UTC 2024

[WanWizard]

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?

[WanWizard]

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

 

[smith]

root@h9combo:~# ls -l /usr/share/zoneinfo/Europe/London

-rw-r--r--    1 root     root             0 Jul 31  2023 /usr/share/zoneinfo/Europe/London

[WanWizard]

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.
 

[smith]

Hi,

 

Yes the 0 filesize do not look correct at all!

 

The command:-

 

opkg install tzdata-europe --force-reinstall

 

Did not work for me unfortunately! I did flash two of these boxes in January with Open PLi 9.0 and copied the file from that box and replaced the version on this box with these results:- 

 

root@h9combo:~# ls -l /usr/share/zoneinfo/Europe/London

-rw-r--r--    1 root     root          1599 Apr  2 14:09 /usr/share/zoneinfo/Europe/London

root@h9combo:~# date

Tue Apr  2 14:11:39 BST 2024

 

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?

 

Just wondering if it was due to running the date -s command, but just tested it and its okay, the time is auto updated again after a few seconds.

[WanWizard]

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.

[smith]

 

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.

 

Edited by smith, 2 April 2024 - 19:36.

[WanWizard]

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.

[smith]

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

 

 

Yes that's right.

[WanWizard]

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.