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 6 of 19 FirstFirst ... 4567816 ... LastLast
Results 76 to 90 of 273

Thread: Vix 5.1.006. Time wrong

  1. #76
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,769
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by SpaceRat View Post
    Lets agree on agreeing that I'm right about my/E2 changes.
    Possibly the end product. But not the method of getting there.
    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. #77
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    Quote Originally Posted by birdman View Post
    ntpdate-sync will (by default on OpenVix at least) try to set the front-panel hardware clock on the box when it runs.
    Yepp.
    In genuine yocto it would try to store the time into the real RTC (Through hwclock).


    Quote Originally Posted by birdman View Post
    /sbin/stb-hwclock. This script has the interesting feature that if you use it to read the FP clock and that clock is ahead of the system time it will set the system time to the FP clock time, which strikes me as an unusual thing to do.
    Simple:
    The only situation where this script is ever getting called in order to read the pseudo-RTC is at boot.
    At that time the system time can only be behind real time. System time will be either shortly after build time (First run) or shortly after the last shutdown/reboot.
    The real time will always, even after a quick reboot, be a bit further than that recorded and continued time, not even the fastest arm boxes can finish the shutdown and go through initrd in negative times ...

    So the RTC must be ahead or it is wrong ... The only cases where the RTC can be behind system time during early boot are:
    - Even the pseudo-RTC is just a fake and always returns 0 (= 1970-01-01 0:00 UTC)
    - It has lost track of time (= after power off), then it will be at 0 or slightly after.
    In either case it would be an invalid time.

    So the check for a (ridicilously) low time in the RTC needs to be there in order to prevent setting the time to 1970 again, which is what all the work is about ...
    ... it could only be relaxed, e.g. by comparing against image build time or 2018-01-01 0:00 (until it's done that will become a good date ).

    But again: As long as NTP or DVB/E2 have done their job, the RTC can not be behind and be right at the same time.
    No, not even right after switching from silly time to normal time in fall (spring forward, fall back ), as the time is stored/maintained in UTC.


    Quote Originally Posted by birdman View Post
    Probably. Except that this is not what Abu is seeing. So we need to concentrate on that....
    There is no truely reproducable problem there ...
    ... so all I can do as shoot at all possible quirks.

    If he's using oscam, starting the box without oscam once could help, according to posts in the OpenPLi forum.
    Last edited by SpaceRat; 30-12-17 at 05:22.
    Receiver/TV:
    • Vu+ Duo² 4*S2+2*C / 1.8TB HDD / OpenATV 6.1@Samsung 50" Plasma
    • AX Quadbox 2400 / 2*S2/2*C / 930GB HDD / OpenATV 6.1@Samsung 32" LCD
    • Vu+ Solo² / 465GB HDD / OpenATV 6.1
    • Vu+ Solo² / 230GB HDD / OpenATV 6.1
    • DVBSky S2-Twin-Tuner PCIe@Samsung SyncMaster T240HD (PC)
    Pay TV: Redlight Mega, Brazzers TV Europe, XXL, HD-, Sky
    Internet: Unitymedia 1play 100 / Cisco EPC3212 + Linksys WRT1900ACS + Fritz!Box 7390 / IPv4 (UM) + IPv6 (HE)

  3. #78
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,335
    Thanks
    6,421
    Thanked 9,146 Times in 6,224 Posts
    Quote Originally Posted by SpaceRat View Post
    If he's using oscam, starting the box without oscam once could help, according to posts in the OpenPLi forum.
    The screenshots I have posted are so far of an image just after flashing. The latest one just shows the First Install Wizard. On the the previous ones, I exited out of all menus during the FIW. On one test, I restored a previous image backup and that also had a date and time in the future.

    We do not pre-install any cams on our image. In any case, you would need to set them up to start. So that rules out oscam. It is an "off the shelf" image.

    If I flash an older image before these latest batch of changes, the date and time is correct at FIW.

    You can insist as much as you like that time is being set, but my screenshots show otherwise. This has happened for me on the TM Nano SE M2, MB Micro premium and Solo 4K. So whatever is wrong, it is wrong on all three of them. The IP addresses on my router are reserved.

    We need to find a solution instead of insisting everything is fine.

  4. #79
    Sicilian's Avatar
    Title
    The Boss
    Join Date
    Mar 2010
    Posts
    29,645
    Thanks
    23,575
    Thanked 26,044 Times in 7,633 Posts
    @ Spacerat, I've just spent hours testing our release 5.1.002 (before your OE-A changes) and 5.1.007 (includes your OE-A changes) using a GB UHD Quad 4K for these time issues.

    1) Our release 5.1.002 shows correct time on first boot after many flashes connecting network cable only or both network cable and satellite coax.



    2) Our release 5.1.007 does not consistently show correct time on with network cable only or with both network cable and satellite coax. Two of three flashes might show correct time on first boot. If time is wrong on first boot boxes need to be physically powered off after flashes for the time to correct itself or user must connect coax and achieve a satellite signal in order for the time to correct itself.



    3) Flashing our release 5.1.002 with no network and with satellite, terrestrial or cable coax connected shows a 1970 date on first boot. Physically powering off and rebooting does not correct the date, only way to correct the date and time is to connect network cable and reboot or tune to a satellite, terrestrial or cable channel.

    4) Flashing our release 5.1.007 with no network and with satellite coax connected shows date image was built on, in this case Thursday 28th December on first boot. Physically powering off and rebooting does not correct the date, only way to correct the date and time is to connect network cable and reboot or tune to a satellite, terrestrial or cable channel.

    In plain english please explain what you are trying to achieve with your changes? Sorry but i'm struggling to understand what your changes are supposed to achieve and this thread has lost me.

    All I can see that's been achieved here is first boot inconsistencies and instead of showing the 1970 date on first boot with no network cable the image build date is shown on SOME first boot's with no network cable connected. Many boots a 2018 date was shown, box had to be physically powered of to show the image build date.

    We've also had a lot of reports of boxes waking after deep standby with the wrong date/time.

    I respectfully ask that your changes are reverted until fixed for all OE-A teams. We've had no issues with date/time until now.
    D I S C L A I M E R

    My right to post information is protected under the rights for freedom act. In all instances, information discussed here on my posts are either hypothetical in nature, out of general curiosity, common knowledge, public knowledge, or role-play. Any use of the collective descriptions and shared knowledge from any of my posts are at the sole discretion of the reader. I am not responsible for what you do with it!

    Follow us on Twitter 0penViX
    Rules can be found
    HERE
    Support our sponsor World-Of-Satellite
    HERE
    GIGABLUE UHD QUAD 4K, VU+ DUO 4K SE, ZGEMMA H7S, VU+ UNO 4K SE
    Triax 1.1m Powered by TM2600, Fixed 28.2 Zone 2 dish with GT-SAT Unicable





  5. #80
    Huevos's Avatar
    Title
    Administrator
    Join Date
    Jun 2010
    Location
    38.5N, 0.5W
    Posts
    13,574
    Thanks
    2,004
    Thanked 4,925 Times in 3,259 Posts
    These changes are worse to E2 than these errors show. In various places E2 and several plugins use 2004 as a date to prove the clock is correctly set. If we just use some "wrong" time that is after 2004 that breaks code in other places. With respect these changes should be reverted until such a time there is compatibility for all team's E2.

    If we can't recognize when the clock is not correctly set we are knackered for schedules.
    Last edited by Huevos; 30-12-17 at 10:35.
    Help keep OpenViX servers online.Please donate!

  6. The Following User Says Thank You to Huevos For This Useful Post:

    Sicilian (30-12-17)

  7. #81
    Huevos's Avatar
    Title
    Administrator
    Join Date
    Jun 2010
    Location
    38.5N, 0.5W
    Posts
    13,574
    Thanks
    2,004
    Thanked 4,925 Times in 3,259 Posts
    Here is just one example of 2004 used in an important e2 file.

    https://github.com/OpenViX/enigma2/b....cpp#L315-L319
    Help keep OpenViX servers online.Please donate!

  8. The Following User Says Thank You to Huevos For This Useful Post:

    Sicilian (30-12-17)

  9. #82

    Title
    Forum Supporter
    Donated Member
    Join Date
    Jun 2014
    Posts
    1,321
    Thanks
    610
    Thanked 418 Times in 270 Posts
    I see @SpaceRat is making making changes to OE-A now regarding the time issues.

  10. #83
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    They are just beautification.
    The core issue was https://github.com/OpenViX/enigma2/c...0df6e5d431d7ae

    That old quirk call to ntpdate simply rarely but still sometimes happened at the very same time as the call to ntpdate-sync on boot.
    In that case, both instances of ntpdate got returned the same offset and both adjusted the time accordingly ... so the difference between 28.12. and "now" was applied twice, thus the time in the future.

    The quirk in enigma2.sh is a double ugly workaround:
    a.) # perform a NTP update sync, before starting Enigma2, as it is broke in OE.
    If you know it's broken in yocto (OE), fix it there, rather than packing ugly workarounds on top!
    I just did exactly that and now that the one-shot NTP in yocto works, the workaround kicked you into the ass ...
    b.) Don't ever call ntpdate directly.
    It doesn't check if another instance of ntpdate is already running ... ntpdate-sync however does

    So
    1. Bad workaround instead of a fix.
    2. Call to a wrong binary which allows collisions.

    Could easily be seen in /var/log/messages:
    Code:
    Dec 30 10:38:13 gbquad4k daemon.notice ntpdate[*1822*]: step time server 85.199.214.101 offset 202264.724341 sec
    Jan  1 18:49:22 gbquad4k daemon.notice ntpdate[*1824*]: step time server 85.199.214.101 offset 202264.725832 sec
    Two instances (different PIDs) of ntpdate running at the very same time, getting almost the very same offset to adjust -> double adjustment.

    The first instance of ntpdate was adjusting by 2 days, 8 hours, 11 minutes and 4 seconds. from 2017-12-28 2:27 to 2017-12-30 10:38, the second one another 2 days, 8 hours, 11 minutes and 4 seconds to 2018-01-01 18:49 ...


    The latest changes of mine just beautify the log output ...
    Code:
    Dec 30 15:30:07 duo2 daemon.notice ntpdate[13240]: adjust time server 192.168.75.1 offset -0.007456 sec
    Dec 30 15:30:07 duo2 daemon.notice stb-hwclock: Current system time has been written into FP pseudo RTC.
    ... the second line previously polluted stdout, now it gets sent to syslog / /var/log/messages ...

    ... and they allow the box to learn NTP servers by DHCPv4 (E.g. the router).

    In addition, the delay for ntpdate-sync on ifup was turned from a fixed delay by 5 sec to a loop that ends as soon as google.com can be pinged (or 5 turns through the loop), so the NTP sync should now happen a little bit earlier even.
    Receiver/TV:
    • Vu+ Duo² 4*S2+2*C / 1.8TB HDD / OpenATV 6.1@Samsung 50" Plasma
    • AX Quadbox 2400 / 2*S2/2*C / 930GB HDD / OpenATV 6.1@Samsung 32" LCD
    • Vu+ Solo² / 465GB HDD / OpenATV 6.1
    • Vu+ Solo² / 230GB HDD / OpenATV 6.1
    • DVBSky S2-Twin-Tuner PCIe@Samsung SyncMaster T240HD (PC)
    Pay TV: Redlight Mega, Brazzers TV Europe, XXL, HD-, Sky
    Internet: Unitymedia 1play 100 / Cisco EPC3212 + Linksys WRT1900ACS + Fritz!Box 7390 / IPv4 (UM) + IPv6 (HE)

  11. The Following User Says Thank You to SpaceRat For This Useful Post:

    bbbuk (30-12-17)

  12. #84

    Title
    Forum Supporter
    Donated Member
    Join Date
    Jun 2014
    Posts
    1,321
    Thanks
    610
    Thanked 418 Times in 270 Posts
    Will these latest changes hopefully solve potential issue with likes of certs in OpenVPN that was mentioned in an earlier post of yours?

    I ask only because using vix 5.1 007, OpenVPN said it had started but I couldn't get any channel on IPTV to work but when I had openVPN off the IPTV channels worked ok.

    During half-time then, I quickly went back to 5.1 002 (before all these changes) with a restore of settings and IPTV now works with openVPN.

    Or was this just all coincidental?

  13. #85
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    Quote Originally Posted by bbbuk View Post
    Will these latest changes hopefully solve potential issue with likes of certs in OpenVPN that was mentioned in an earlier post of yours?
    Yes.

    It's meant to address errors like these:
    Quote Originally Posted by openvpn
    Wed Oct 15 03:03:44 2014 TLS: Initial packet from [AF_INET6]2001:db8:4063:dead:beef:1fff:fe12:3456:53667, sid=b0b81bb4 36d599a0
    Wed Oct 15 03:03:46 2014 VERIFY ERROR: depth=1, error=certificate is not yet valid: C=GDR, ST=SomeState, L=Somewhere, O=mocowolf, OU=CA Cert, CN=mocowolf CA, name=Root CA, emailAddress=foo@bar.org
    Wed Oct 15 03:03:46 2014 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
    Quote Originally Posted by rclone
    root@quadbox ~ # mount -a
    root@quadbox ~ # 2014/10/15 03:06:01 Failed to create file system for "ACD:": failed to get endpoints: Get https://drive.amazonaws.com/drive/v1/account/endpoint: x509: certificate has expired or is not yet valid
    The same applies for davfs2 (For WebDAV, which is HTTPS) or if you just want to wget/curl something during from https during boot (e.g. in rc.local or some E2 startup script).
    Receiver/TV:
    • Vu+ Duo² 4*S2+2*C / 1.8TB HDD / OpenATV 6.1@Samsung 50" Plasma
    • AX Quadbox 2400 / 2*S2/2*C / 930GB HDD / OpenATV 6.1@Samsung 32" LCD
    • Vu+ Solo² / 465GB HDD / OpenATV 6.1
    • Vu+ Solo² / 230GB HDD / OpenATV 6.1
    • DVBSky S2-Twin-Tuner PCIe@Samsung SyncMaster T240HD (PC)
    Pay TV: Redlight Mega, Brazzers TV Europe, XXL, HD-, Sky
    Internet: Unitymedia 1play 100 / Cisco EPC3212 + Linksys WRT1900ACS + Fritz!Box 7390 / IPv4 (UM) + IPv6 (HE)

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

    bbbuk (30-12-17)

  15. #86
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,769
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by SpaceRat View Post
    It's meant to address errors like these:
    But all that seems to have happened is that you've replaced one set of problems, which have always been there, with a different set of problems, which have never been problems before.
    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. #87
    abu baniaz's Avatar
    Title
    Moderator
    Join Date
    Sep 2010
    Location
    East London
    Posts
    23,335
    Thanks
    6,421
    Thanked 9,146 Times in 6,224 Posts

    Vix 5.1.006. Time wrong

    @Birdman, I believe the latest changes have fixed the knock-on effects that were caused.

    Edit:
    This should be available in 5.1 009

  17. #88
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,769
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by SpaceRat View Post
    It's meant to address errors like these:
    But it won't.

    The ntpdate-sync script (which is ntpdate under ntpd in meta-openembedded) is firing off ntpdate in the background, which means the rest of the boot process (including starting enigma2) goes on before the time is set. The ntpdate call must be done in the foreground to ensure that it has completed before the rest of the boot process continues.
    If anything else wishes to background this then it can just background the call to the script.

    Also, the check_online()function in the script is pinging www.google.com. That means it has to resolve www.google.com (meaning it has network access) before it can do the ping, which rather means the ping is pointless.
    I'd suggest using the IP address of Googles nameservers instead (8.8.8.8 and 2001:4860:4860::8888).
    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

  18. #89
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    Quote Originally Posted by birdman View Post
    Also, the check_online()function in the script is pinging www.google.com. That means it has to resolve www.google.com (meaning it has network access) before it can do the ping, which rather means the ping is pointless.
    I'd suggest using the IP address of Googles nameservers instead (8.8.8.8 and 2001:4860:4860::8888).
    No, vice versa:

    As the time servers are usually also specified as an URL (pool.ntp.org), name resolution has to work too for it to work.
    udhcpc-Scripts set the routing first, then DNS, so there is a tiny moment at which the interface is already up (IPs are routable) but names can not be resolved yet.
    Receiver/TV:
    • Vu+ Duo² 4*S2+2*C / 1.8TB HDD / OpenATV 6.1@Samsung 50" Plasma
    • AX Quadbox 2400 / 2*S2/2*C / 930GB HDD / OpenATV 6.1@Samsung 32" LCD
    • Vu+ Solo² / 465GB HDD / OpenATV 6.1
    • Vu+ Solo² / 230GB HDD / OpenATV 6.1
    • DVBSky S2-Twin-Tuner PCIe@Samsung SyncMaster T240HD (PC)
    Pay TV: Redlight Mega, Brazzers TV Europe, XXL, HD-, Sky
    Internet: Unitymedia 1play 100 / Cisco EPC3212 + Linksys WRT1900ACS + Fritz!Box 7390 / IPv4 (UM) + IPv6 (HE)

  19. #90
    birdman's Avatar
    Title
    Moderator
    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    7,769
    Thanks
    235
    Thanked 1,656 Times in 1,305 Posts
    Quote Originally Posted by SpaceRat View Post
    As the time servers are usually also specified as an URL (pool.ntp.org), name resolution has to work too for it to work.
    udhcpc-Scripts set the routing first, then DNS, so there is a tiny moment at which the interface is already up (IPs are routable) but names can not be resolved yet.
    OK, but if name resolution is failing because the network isn't up isn't there a possibility that the loop over 5 attempts will actually get run very quickly (since ping won't be running with its 4s timeout)?
    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 6 of 19 FirstFirst ... 4567816 ... 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.