Wrong Time

[dondyall]

Edision os mio 4K
OpenViX 5.2.043
Problem wrong time:
Menu>Setup>Time>
Timezone Area US
Timezone Central
Sync Time Using NTP
NTP Server pool.ntp.org
Sync Time Every 30 Minutes

Turn Off Internet
Go To No Channel or Tune Fail
OpenViX will lose accurate time

It's important to keep accurate time every if the internet connection is loss or there's no signal

I have multiboot
and other images do NOT have this problem

[dondyall]

Edision os mio 4K
OpenViX 5.2.043
Problem wrong time:
Menu>Setup>Time>
Timezone Area US
Timezone Central
Sync Time Using NTP
NTP Server pool.ntp.org
Sync Time Every 30 Minutes

Turn Off Internet
Go To No Channel or Tune Fail
OpenViX will lose accurate time

It's important to keep accurate time even if the internet connection is loss or there's no signal

I have multiboot
SatDreamGR TNAP does NOT have this problem --- LegitFTA download

[birdman]

It's important to keep accurate time even if the internet connection is loss or there's no signalBut not actually possible. That's why protocols like NTP exist.

[abu baniaz]

Does it go to a different timezone or just random time? Does it slowly change or change 30 minutes after tune failed?

You'd expect time to continue at ongoing rate if it can't re-sync. It shouldn't corrupt if there is no signal lock or internet access

[dondyall]

Tried Experiment again
to get Wrong Time
Turned Off Internet
Go To No Channel or Tune Fail
OpenViX lost accurate time in less than 30 minutes
Reverts to 6:50PM Wed December 31
Wrong Time

Note the Timezone Area and Timezone stayed the same
No Change

Checked Menu>Setup>Time>
Timezone Area US
Timezone Central
Sync Time Using NTP
NTP Server pool.ntp.org
Sync Time Every 30 Minutes

Turned On Internet
Went to a channel
OpenViX immediately goes back to correct time

[birdman]

Reverts to 6:50PM Wed December 31What year? If 1969 that's the system clock resetting to 0. Which is probably easier to look into than if it is some other year.

EDIT: seems possible, given that Dec 31, 1969 was a Wednesday.

[el bandido]

My test defaulted to January. I do not know which year.
Looks like the image tries to get the time from the transponder since the internet is not working? There is no time to get on a dead channel, so the time defaults?

What I do understand is this:
Why disconnect the internet?
Why tune to a dead channel?

Doing these things on purpose makes little sense. But if these things are unavoidable, then try changing the time sync from 30 minutes to once a day.

[dondyall]

Moving the C bank dish will cause signal loss
Weather events can cause bad reception signal loss
Satellite or network signal loss
Turning off the internet to save energy
All the above prevent PVR recording
caused by wrong time

The SatDreamGR TNAP image will keep accurate date and time despite losing internet connection and no signal

[clivejo]

I find that the clock on the front panel seems to freeze when I tune to a radio channel or use the YouTube plugin. It often takes a bit of time after switching to a TV channel to start displaying the correct time. This is one of the reasons I want it to display the channel number rather than the time.

[el bandido]

Moving the C bank dish will cause signal loss
Weather events can cause bad reception signal loss
Satellite or network signal loss
Turning off the internet to save energy
All the above prevent PVR recording
caused by wrong time

The SatDreamGR TNAP image will keep accurate date and time despite losing internet connection and no signal

Set the box to time sync once a day, and reboot the box when you have internet connected. Or quit turning off the internet.

What the time does when it is supposed to sync and there is no internet is really a preference. If it is changed to satisfy your needs, then someone else may have time issues. The only other solution would be to add more options in the time menu.

[birdman]

Or quit turning off the internet.Perhaps he doesn't have permanent access to it?


What the time does when it is supposed to sync and there is no internet is really a preference.No, it's a coding issue. If it tries to sync and fails then it really shouldn't change the current time at all.

[el bandido]

I see it as a preference.
Right now, it looks like If time fails to internet time sync, then it reverts to transponder time sync. This would work great for some people.

Having the time sync only when internet is available if sync with internet is chosen would also be nice,

[el bandido]

I tested on a dead transponder or dead channel again, and find the clock has reset to 12-31-1969. Birdman is correct.

[birdman]

I see it as a preference.So you're suggesting that there should be an option such that if you are using NTP and it can't reach any servers at any point that it should completely ignore the current time and forcibly reset the system clock to 0?

[el bandido]

No.
The preference I see is falling back to transponder time sync if internet time sync is not available.
Like you said, the reset to 0 should not take place. Would be nice if the time did not did not make any change if the only option is to sync to 0

Here is how I think the image acts now after a few tests:
If internet time sync is chosen, then it is used.
If internet time sync is chosen and there is no internet then transponder time sync is used.
If internet time sync is chosen when there is no internet, And the current channel being watched is on a dead transponder, then the time syncs to 0.

[birdman]

If internet time sync is chosen when there is no internet, And the current channel being watched is on a dead transponder, then the time syncs to 0.And I'm wondering why would you ever want that?
The OP doesn't, as that is the whole point of this thread.
Surely it makes more sense just to leave the system running with its current clock time, which may be slowly drifting away from true time, but will be much closer than setting it to 00:00 01 Jan 1970 UTC.

There is the issue that if you have no internet connexion and no working transponders then the time set on the box has little significance, given that it can't do anything useful anyway, but I see no point in just discarding an approximated (and close) time just for the sake of it.

[el bandido]

I did not say I wanted that. (I simply observed the box doing that per post#15.) Nowhere did I say to discard an approximated (and close) time just for the sake of it. But the box is working that way now with VIX.

Currently if the box is set to sync with internet time and no internet is available then the time syncs using transponder time. This appears to be someone's preference because if the box is set to sync with internet time, then it should not sync with transponder time for any reason. Either someone set the internet time sync to fall back on transponder time sync if no internet is available as a preference, or it was done by accident.

[birdman]

I did not say I wanted that.Well, not exactly. In post #12 (https://www.world-of-satellite.com/showthread.php?61530-Wrong-Time&p=486829&viewfull=1#post486829) you said, "I see it as a preference", which implies you want it as a possibility.

[birdman]

Edision os mio 4K
OpenViX 5.2.043
Problem wrong time:
Menu>Setup>Time>
Timezone Area US
Timezone Central
Sync Time Using NTP
NTP Server pool.ntp.org
Sync Time Every 30 Minutes

Turn Off Internet
Go To No Channel or Tune Fail
OpenViX will lose accurate time

It's important to keep accurate time even if the internet connection is loss or there's no signalI've tried reproducing this by removing my default route (so that NTP calls fail) and unplugging the aerial connexions to both (terrestrial) tuners.
The time just stays where it is (advancing 1s/s)

Do you have debug logs enabled?
If so, can you post one that covers the period where this happens? It should contain some info as to where/by what the time was set.
If not, could you enable them to produce a set, please?

[Joe_90]

@birdman - I suspect this is a situation where there is a transponder giving out invalid time data and the box is setting the clock to zero (1/1/70). The poster(s) are in the U.S., so there may be some data on the transponders upsetting the clock routine. I used to get issues years ago on my (non-linux) STB's whereby, if I tuned to certain satellites, the clock would reset to some crazy values. Here in Europe, most of the usual sats have well behaved transponders with fairly accurate UTC time. Maybe there is an odd use case which is not catered for in the vix code as the other image being used (SatDreamGR TNAP) is a North America "tweaked" version. Just a suggestion...

[abu baniaz]

I used to get this too when I had a motorised dish.

[birdman]

@birdman - I suspect this is a situation where there is a transponder giving out invalid time data and the box is setting the clock to zero (1/1/70). On re-reading post #5 (https://www.world-of-satellite.com/showthread.php?61530-Wrong-Time&p=486807&viewfull=1#post486807) I see that it isn't setting the clock to 0, but rather to 3000 (Wed 31 Dec 18:50:00 CST 1969).
Which would seem to tie-in with that suggestion about bad data (rather than no data).
However, if we could work out what path through the code was taken to do it we might be able to add or change a check such that clock values lower than a reasonable setting were ignored.

[abu baniaz]

Hopefully debug logs will show the issue

Debug logging is enabled as follows:
Menu -> Setup -> System -> Logs -> Enable debug logs = yes, and then GUI Restart.

[Joe_90]

On re-reading post #5 (https://www.world-of-satellite.com/showthread.php?61530-Wrong-Time&p=486807&viewfull=1#post486807) I see that it isn't setting the clock to 0, but rather to 3000 (Wed 31 Dec 18:50:00 CST 1969).
Which would seem to tie-in with that suggestion about bad data (rather than no data).
However, if we could work out what path through the code was taken to do it we might be able to add or change a check such that clock values lower than a reasonable setting were ignored.

The clock data on the transponder is presumably corrupted in some way which is putting it to 00:50 1/1/70 (UTC) which is then translated back to the US timezone in the receiver. The transponder should be using UTC and indicating a TZ offset (for EPG display) if it is using DVB standards, but some don't, which I think is the issue on occasions.

[el bandido]

Getting a debug log of this problem is not easy to do.The time loss only exists for me when tuning to a dead channel with the Ethernet or nic cable disconnected. This problem does not seem to exist if the Ethernet cable is connected to a router with the Internet disconnected.

A debug log is not generated within the receiver because there is no crash or exception. Modifications have to be made so the receiver can generate a log without using telnet because the Ethernet cable will be dead in order for the time problem to be seen.

Attached is a log showing this time issue. This log was made by turning On the receiver from a cold boot, waiting a few minutes, changing to a dead channel and removing the Ethernet cable, waiting for the time to crash, tuning to a channel that works, and finally replacing the Ethernet cable, then waiting until the time was eventually restored to the correct time.

I do not see what caused the time to crash by looking at the log, but someone else may. This time crash only exists under a certain set of circumstances, and may be more trouble than it is worth to fix.

[birdman]

A debug log is not generated within the receiver because there is no crash or exception.Debug logs are continuously created if you switch them on.
See #23 (https://www.world-of-satellite.com/showthread.php?61530-Wrong-Time&p=486894&viewfull=1#post486894).

But you've managed to post what was wanted anyway, thanks.

This bit looks interesting:

< 1953.839> [Console] finished: /usr/bin/ntpdate-sync
< 1953.839> [NetworkTime] NO TIME SET
< 1963.840> [NetworkTime] Updating
particularly the 10s gap between the last two lines.

As do, possibly:

< 1916.304> Unhandled error in Deferred:
and

< 140.794> [StbHardware] Set RTC to Tue 2019 Jul 09 22:37 (rtc_offset = -144$
< 140.794> [StbHardware] Error: setRTCtime failed!

[birdman]

Attached is a log showing this time issue. This log was made by turning On the receiver from a cold boot, waiting a few minutes, changing to a dead channel and removing the Ethernet cable, waiting for the time to crash...I've tried to reproduce this by unplugging my Ethernet cable and all aerial cables to tuners, then letting the box run for 50 mins (to ensure that an ntpdate-sync ran). This was ~20:20 to ~21:10.
The time progressed as normal through this.

My log shows:

< 1968.336> [Console] finished: /usr/bin/ntpdate-sync
< 1968.337> [NetworkTime] setting E2 time: 1562787745.97
< 1968.339> [StbHardware] Set RTC to Wed 10 Jul 2019 20:42 (rtc_offset = 3600 sec.)whereas yours showed that ntpdate-sync had reset the time to 0 (or at least <= 10000).

I can't see why it would do that on one system but not on another.

[birdman]

This bit looks interesting:
...
particularly the 10s gap between the last two lines.The 10s is because when the time isn't set it tries to set it every 10s.

[el bandido]

I've tried to reproduce this by unplugging my Ethernet cable and all aerial cables to tuners, then letting the box run for 50 mins (to ensure that an ntpdate-sync ran). This was ~20:20 to ~21:10.
The time progressed as normal through this.

My log shows:
whereas yours showed that ntpdate-sync had reset the time to 0 (or at least <= 10000).

I can't see why it would do that on one system but not on another.

Please post a log of your test to compare. Thanks.

[birdman]

As do, possibly:

< 1916.304> Unhandled error in Deferred:
This is a message from the Python Twisted code.

It might be related to:

< 26.598> [eDVBServicePlay] timeshift
< 26.599> [eDVBServicePlay] timeshift not enough diskspace for timeshift! (less than 1GB)
You should either configure the timeshift location to be somewhere that does have space, or switch it off.
(But then, if you don't have any space for recordings, why do you have 3 tuners - one of which looks like a USB one?).

[birdman]

whereas yours showed that ntpdate-sync had reset the time to 0 (or at least <= 10000).

I can't see why it would do that on one system but not on another.The ntpdate source code contains this at the start of clock_adjust() (which is the only entry to the code which changes the clock):


if (server == 0) {
msyslog(LOG_ERR,
"no server suitable for synchronization found");
return(1);
}
Leaving aside the fact that the check is against 0* this means that if no NTP server has been reachable then the code just returns without ever changing the clock. So I'm at a loss to see how your system gets past this if it has no network connexion.



*(it should be against NULL or , better, !server - on Unix systems these tests are all the same, but I've used systems where they are not...)

[birdman]

Please post a log of your test to compare. Thanks.

Here it is, but doubt it will show anything beyond what I've noted.
59074