Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 32

Thread: Wrong Time

  1. #16
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by el bandido View Post
    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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  2. #17

    Title
    Senior Member
    Join Date
    Dec 2013
    Posts
    138
    Thanks
    237
    Thanked 40 Times in 35 Posts
    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.

  3. #18
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by el bandido View Post
    I did not say I wanted that.
    Well, not exactly. In post #12 you said, "I see it as a preference", which implies you want it as a possibility.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  4. The Following User Says Thank You to birdman For This Useful Post:

    el bandido (08-07-19)

  5. #19
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by dondyall View Post
    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'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?
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  6. The Following 3 Users Say Thank You to birdman For This Useful Post:

    abu baniaz (08-07-19),deltec (14-07-19),el bandido (08-07-19)

  7. #20
    Joe_90's Avatar
    Title
    Moderator
    Join Date
    Mar 2014
    Location
    Wicklow, Ireland
    Posts
    4,244
    Thanks
    1,315
    Thanked 1,148 Times in 908 Posts
    @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...
    GB Quad Plus, Mut@nt HD51, AX HD61, 80cm dish and Supreme Dark motor. Sony TA-AN1000, Sony UBP-X800M2 Bluray, Odroid N2+ (CoreElec), Monitor Audio Bronze 5.1 speakers

  8. #21
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,541
    Thanks
    6,517
    Thanked 9,224 Times in 6,287 Posts
    I used to get this too when I had a motorised dish.

  9. #22
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by fat-tony View Post
    @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 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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  10. #23
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,541
    Thanks
    6,517
    Thanked 9,224 Times in 6,287 Posts
    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.

  11. #24
    Joe_90's Avatar
    Title
    Moderator
    Join Date
    Mar 2014
    Location
    Wicklow, Ireland
    Posts
    4,244
    Thanks
    1,315
    Thanked 1,148 Times in 908 Posts
    Quote Originally Posted by birdman View Post
    On re-reading post #5 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.
    GB Quad Plus, Mut@nt HD51, AX HD61, 80cm dish and Supreme Dark motor. Sony TA-AN1000, Sony UBP-X800M2 Bluray, Odroid N2+ (CoreElec), Monitor Audio Bronze 5.1 speakers

  12. #25

    Title
    Senior Member
    Join Date
    Dec 2013
    Posts
    138
    Thanks
    237
    Thanked 40 Times in 35 Posts
    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.
    Attached Files Attached Files

  13. #26
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by el bandido View Post
    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.

    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!
    Last edited by birdman; 10-07-19 at 11:45.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  14. The Following User Says Thank You to birdman For This Useful Post:

    el bandido (10-07-19)

  15. #27
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by el bandido View Post
    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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  16. #28
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by birdman View Post
    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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  17. #29

    Title
    Senior Member
    Join Date
    Dec 2013
    Posts
    138
    Thanks
    237
    Thanked 40 Times in 35 Posts
    Quote Originally Posted by birdman View Post
    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.

  18. #30
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,858
    Thanks
    239
    Thanked 1,673 Times in 1,318 Posts
    Quote Originally Posted by birdman View Post
    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?).
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.