18 replies to this topic

[Gun]

Receiver Xtrend ET9200 HD Twin, while setting system time GMT+11:00 the time is displayed as +10. Helps neither the installation via the menu nor the manual edit of the file "settings". How to fix?

[Tech]

Switch down the STB and unplug the powercord from the socket and press the powerbutton in the front of the ET9200.

 

After booting the STB, the correct time should appair after getting a lock from a transponder.

[Gun]

Thanks for the reply, but shut down and restart the STB with no effect

[Erik Slagter]

Set the startup channel to a transponder that carries the correct time.

[Gun]

Doesn't help!

[el bandido]

Download and install the System Time plugin from feeds.

[hemertje]

Doesn't help!

It does, use a proper tv channel

[mrvica]

You have to be more specific, which time? what display? time in tke skin? your box has got only alphanummeric display, during normal operation is there normally service channel dipslayed or do you mean display standby time or deep standby display time

[WanWizard]

"while setting system time GMT+11:00 the time is displayed as +10" can imho only be interpreted as "the time displayed is one hour off".

 

Since the STB is a linux system, it stores its internal time in UTC. If the time displayed is wrong, the time source is wrong. And by default, that is the transponder time. If you can't get that right, install the systemtime plugin, and use it to get the correct time from an NTP time source (it has the option to sync the time manually).

[Gun]

Thank you all very much, issue has been resolved through the installation of the systemtime plugin and correct time after click item "enter another system time". Thank you all once again!

[Erik Slagter]

That MEANS that the time from your provider (transponder) is wrong. Or that you didn't select the correct time zone.

[Gun]

After the transfer on April 27 time our area in a different time zone (from GMT+10 to GMT+11), according to the decision of the local authorities, the problems began for all accessories that sync time from external sources, including Android, iOS, Mac, Windows devices.

Of course, problems arose on the STB with Enigma2. Some problems had to be solved by using non-systemic correction programs. About plugin systemtime didn't know, because never before such problems was not. 

 

Thanks to all who participated in solving my problem.

 

P. S. Sorry for my English.

[Erik Slagter]

Why don't you just select the proper timezone then? Proper in this context means the timezone that makes the time correct, not necessarily the one that is dedicated to your country.

[Gun]

Why don't you just select the proper timezone then? Proper in this context means the timezone that makes the time correct, not necessarily the one that is dedicated to your country.

First, please read the whole topic, well, at least, its beginning.

[mrvica]

Erik Slagter and we just wan´t to solve the problem, you have to be a bit cooperative

GMT +10 means you live in Siberia Vladivostok, when you put GMT +11, the time is still diplayed +10, well there are different +11, with or without daylight saving time, you may try some of them or we can even adapt

/usr/share/enigma2/timezone.xml

for you and people having the same problem (for the future)

 

[Gun]

mrvica, thank you for your message!

Nothing, not setting any the installation of no +10 or +11 or +12 in different variants, nor any other time did not lead to its correct mapping. Or in manual mode through the menu or through the edit files (settings, timezone, replace "pool.ntp.org" on "ru.pool.ntp.org" and on the "asia.pool.ntp.org" etc.) - without any effect. This is a system error, this needs to be corrected! By the way, for example, correctly, without plugins, try to put GMT+11.30. How was it?

[WanWizard]

If your government came up with a custom timezone setting that matches none of the others, it can only be addressed by an update of the timezone database.

 

I assume this is about the change mentioned here: http://mm.icann.org/...ril/000038.html ?

 

In that case, we need to update to 2016d. Since the current OpenPLi 4 still runs on 2015a, I'd say an update is overdue.

[Erik Slagter]

Exactly. Either workaround (as I suggested) or the timezones must be updated. There is no other way.

 

The timezone package is bound to the OE version we're using for the build environment, so it's a bit complex. When release 5 comes out, it will have an up to date timezones package.

[Gun]

Exactly. Either workaround (as I suggested) or the timezones must be updated. There is no other way.

 

The timezone package is bound to the OE version we're using for the build environment, so it's a bit complex. When release 5 comes out, it will have an up to date timezones package.

Thanks, will wait for the 5.0 release.