Vix 5.1.006. Time wrong

[twol]

I've started so I'd like to finish....
If necessary I'll come up with a compromise and think about the loose ends later.

Don‘t get me wrong, I really appreciate all the work you have put in. As soon as I saw the 1st changes go into the OE-A from Spacerat (19/12/2017), I thought brave guy..... there are always so many issues with timing between components when you change the timing basis.... and it‘s not easy to resolve.

 

[birdman]

That's just it - I haven't had a single issue with my GB Quad+ which uses NTP (but is hardwired to the LAN).

I've not had any problem on my systems either, but then I use transponder time.
It is easy to see that some problems could easily occur, though, and it's not that difficult to avoid most of them.

 

[SpaceRat]

Just my 2 cents, as I don't have the time to assist:

birdman is right about the problem being that E2 will perform time related stuff without making sure the time was really synced. It's just not point 3 but the top point 1 in the list, because everything else could have happened before too.
Letting ntpdate-sync create a flagfile indicating success and making E2 wait for it (rather than just the kick-off of ntpdate-sync) before setting m_time_ready is exactly the same solution as the one I would have come up with if I still had the time.

All the other things (auto-fallback NTP-> DVB and so on) are just a bonus:
The option to configure NTP and having it fail permanently always existed.

Gesendet von meinem SM-N910F mit Tapatalk

 

[birdman]

Letting ntpdate-sync create a flagfile indicating success and making E2 wait for it (rather than just the kick-off of ntpdate-sync) before setting m_time_ready is exactly the same solution as the one I would have come up with if I still had the time.

I'm also trying to do the reverse - set a flag if the transponder time has been set (just so that any forever-backgrounded NTP-trier can give up). The code seems to assume that if you have a transponder then the time can be obtained from it "immediately". Does anyone know whether that is true (not that the time is correct, but that " a time" can be gotten)?

 

[SpaceRat]

I'm also trying to do the reverse - set a flag if the transponder time has been set (just so that any forever-backgrounded NTP-trier can give up).

I was considering a slightly different approach:

In order to solve the possible interfering of DVB and NTP time syncs, one could create an dvbdate-sync app, the source code already exists:
https://github.com/linuxstb/dvbtools/tree/master/dvbdate

That way all the time syncing could be offloaded to the OS (yocto, Linux) and E2 wouldn't need to care about it at all (Except to allow the user to configure its preferences and checking for success).

The options should be
- NTP first, DVB fallback
- NTP only
- DVB first, NTP fallback
- DVB only

plus:
- Fall back after n failed attempts: >=3

ntpdate should only give up if DVB fallback is set and only temporarily.
This is due to NTP being much more accurate than DVB and if the user decides to use NTP only, DVB sync is no option at all.

One actually needs at least two different flagfiles:
- If a sync succeeded within the current "session" at all
- A counter for the failed attempts

As long as NTP succeeded once (e.g. at boot), there shouldn't be an immedeate fall-back to DVB sync just because a later NTP sync failed once.
If NTP succeeds only once per hour, that time is most likely still better than that from transponders (Where I can easily find transponders that are off by ~ 5min).

Once the sync fell back, it should also revert to the preferred method as soon as it succeeds again, for the same reason as above.

My idea so far was to write the time of the last successful sync (after sync of course) into a flag file
/var/tmp/ntp-synced
and the amount of failed attempts into
/var/tmp/ntp-fails

So if /var/tmp/ntp-synced exists, we had a successful sync at least once within the current session (As /var/tmp is volatile and its content is lost on reboot), by reading it, we can learn when it succeeded the last time.
On successful sync, "0" gets written into /var/tmp/ntp-fails, so if /var/tmp/ntp-synced exists and /var/tmp/ntp-fails contains "0", then we know it was the latest sync that succeeded -> Everything ok.

If /var/tmp/ntp-synced does not exist, we have to fall back to DVB until NTP succeeds.

If /var/tmp/ntp-synced exists but /var/tmp/ntp-fails contains "n" with "n > failed attempts before fallback", we also have to fall-back to DVB until NTP succeeds again (= /var/tmp/ntp-fails contains "0" again).

The code seems to assume that if you have a transponder then the time can be obtained from it "immediately". Does anyone know whether that is true (not that the time is correct, but that " a time" can be gotten)?

For DVB sync, m_time_ready gets set to true when the time is already retrieved:
https://github.com/OpenViX/enigma2/blob/master/lib/dvb/dvbtime.cpp#L515

It becomes true a few (milli)seconds before the system time gets actually written though.
That's due to later return statements inside the code that would prevent m_time_ready becoming true if transponder time was retrieved but has no difference to current time.
Ugly spaghetti code ...

 

[birdman]

In order to solve the possible interfering of DVB and NTP time syncs, one could create an dvbdate-sync app, the source code already exists:
https://github.com/linuxstb/dvbtools/tree/master/dvbdate

...but doesn't work.

root@et8000:~# ./dvbdate 
./dvbdate: Nothing to read from fd_date - try tuning to a multiplex?

It's querying [FONT=courier\ new]/dev/dvb/adapter0/demux0[/FONT] by default, but I've also tried it with [FONT=courier\ new]/dev/dvb/adapter0/demux7[/FONT] and [FONT=courier\ new]/dev/dvb/adapter1/demux0[/FONT] (an external USB tuner) with the same result.
It looks like it expects you to have run [FONT=courier\ new]dvbtune[/FONT] first, which isn't compatible with having enigma2 running(?).

 

[SpaceRat]

We would need to check with E2 first if it has already tuned a transponder (Then use that) and if not, tune one using dvbtune (e.g. while E2 is in standby).

 

[birdman]

We would need to check with E2 first if it has already tuned a transponder.

It had, hence an attempt to use dvbtune resulted in an error that it was in use.

 

[birdman]

Well, this is where I've got to now:

View attachment ntpdate-sync.zip

(there are some debug statements in there...).

This is an ntpdate-sync which:

• Has a few different modes of running - it sets different ways according to whether it has been called by ifup, from enigma2 or from a terminal. It also has options so you can change these.
• Uses flock rather than the (more complicated) lockfile-create/-touch/-remove method to protect the ntpdate call.
• Can "try forever" (retries get done up to every minute). This is used by the ifup call. After the first attempt the rest are done in the background.
• Can do "quick" (single-shot) time sets. This is used by the ifup call.
• Can run in the background. This is used by the "enigma2" call.
• Can slew the time (rather than set it absolutely). This used by the "enigma2" call, and the ifup call if enigma2 is already running.
• The "try forever" code will stop if something else sets the clock. This negates the need for enigma2 to create a marker file saying that it has set the time using a transponder.
• Creates a marker file the first time it sets the time.

Provided this can be put into then build then the enigma2 code can also be improved by looking for the marker file.

 

[Joe_90]

Hi Gordon - will try out your new version and report back!

 

[adm]

An observation

I have my box set to get the time from the transponder.

If I have the router disconnected the boot time is 3 minutes 5 seconds
If I have the router connected (wired) the boot time is 1 minute 10 seconds

Im sure a with a 3 minute boot some people would panic and start removing power while the box is booting to see if a power cycle would fix it.

 

[birdman]

If I have the router disconnected the boot time is 3 minutes 5 seconds
If I have the router connected (wired) the boot time is 1 minute 10 seconds

When you say you've disconnected the router do you mean:
you've disconnected the router from the box
you've disconnected the router from the internet, but it's still connected to the box
In testing ntpdate timed out after 2 seconds if it was trying to reach a non-existent system or one with no NTP server running - and timed-out immediately if there was no network*.
So it could be other things slowing it down (the extra 2mins sounds like a TCP connexion...).


* Tested by unplugging the Ethernet cable from a Kubuntu Linux system, but that is managed by NetworkManager, so isn't quite the same - difficult to test on an Enigma2 box if there is no network...

However, whilst writing this I worked out how to test it with no Ethernet cable in (I don't need to be looking - I can keep a log and look later). The timeout is then 23s.
Given that the command has a timeout option, and it should get an answer in <2s I can improve the script (which you aren't actually using - yet(?)).

Thanks....

 

[adm]

When you say you've disconnected the router do you mean:
you've disconnected the router from the box
you've disconnected the router from the internet, but it's still connected to the box.

The Ethernet cable between my ET10K and the router was still connected.
The wall wart supplying low voltage power to the router was still supplying power and connected to the router.
The router was switched off with it's own on off switch which to the best of my knowledge completely turns it off. It had been left off for 6+ hours.


I've Just repeated a couple of boot-ups with just the (short) Ethernet cable disconnected at the router end.

First boot 3 minutes.

Second boot
Times below are the cumulative times between the switch on to the end of that sequence
The second and third Vix splash screens on my box have the same image but there is a few seconds of blank screen between them. I have customised boot splash images.

Extrend splash screen 15 seconds
First Vix splash screen 40 seconds
Second Vix splash screen 1 minute 45 seconds
Third Vix splash screen 3 minutes 5 seconds

All other equipment normally connected to the box was still connected and switched on.
Fire stick on the HDMI input (via a HDMI switch)
TV on HDMI output
AV amp connected optically


Using OpenVix 5.1.021.

Note in case its relevant
The Extrend 10K has LAN and VLAN connections. The former is used, the latter isn't.