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 9 of 19 FirstFirst ... 7891011 ... LastLast
Results 121 to 135 of 273

Thread: Vix 5.1.006. Time wrong

  1. #121
    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 SpaceRat View Post
    If the initial ntpdate-sync fails (or takes long), E2 will start with the fake-hwclock time, just like you said.
    That's absolutely no problem at all though, as it will later do some own time sync (Either DVB or NTP) anyways and previously E2 sometimes even started on 1970-01-01 and had no problem with it.

    The only problem is that currently two sync can happen at the very same time.
    Which appears to be what is happening. And that is a bug.
    The simple fix is to ensure that the first ntpdate is run synchronously. Then concurrent ntpdate syncs will not occur, and services will start with the correct time set and the enigma2 log will have a sensible time-stamp in its name(unless ntp isn't working because of network connectivity failure, in which case ntpdate-sync isn't going to do anything and this whole discussion becomes moot).
    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. #122
    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
    EDIT - I've noticed that the ntpdate updates are not being logged in "messages" for some reason (so I can't tell which NTP server is being used). The E2 log is reporting ntpdate-sync at the 30 minute intervals as follows:
    I'm not sure that they are meant to be.
    Hence the debug version of my script which does log when it runs - except the the initial calls are before syslogd start up, so they don't get logged either, which is why I added the log file in /var/tmp.
    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

  3. #123
    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
    This may be a WiFi - specific issue.
    Probably. But it's related to timings at start-up. And running the ntpdate in the background loses all control of timing.
    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. #124
    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
    I'm not sure that they are meant to be.
    Hence the debug version of my script which does log when it runs - except the the initial calls are before syslogd start up, so they don't get logged either, which is why I added the log file in /var/tmp.
    The ntpdate updates were being logged in syslog (messages) up to several days ago - that is what I pasted onto the posts to show the double updates. Now I don't see anything logged in syslog in regard to ntpdate. There are just the entries in the normal debug log showing ntpdate-sync being run every 30 minutes and updating the system clock.

    Since I've uncommented the second line in /etc/default/fake-hwclock so that it now reads

    Code:
    # Uncomment to set clock even if saved value appears to be in the past
    FORCE=force
    what is happening is that the file /etc/fake-hwclock.data is no longer being updated on shutdown and the system now boots with the epoch start date of 1/1/1970 which means that the system now forces a time update from the transponder if the initial ntpdate-sync doesn't work for any reason. So, normal service (of a sort) has been resumed in that the system clock is set correctly and then ntpdate-sync works at 30 minute intervals thereafter and further transponder syncs are disabled.

    Now, the way I interpreted the wording in the first line of /etc/default/fake-hwclock was that removing the comment in the second line "Force=force" would force the update of /etc/fake-hwclock.data on each shutdown. Instead, what appears to happen is that there are no further updates to /etc/fake-hwclock.data, no further usage of stored time data and the system reverts to the old method of starting from epoch zero. Is this the intended behaviour, SpaceRat?
    Last edited by Joe_90; 19-01-18 at 12:46.
    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

  5. #125
    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
    Since I've uncommented the second line in /etc/default/fake-hwclock so that it now reads

    Code:
    # Uncomment to set clock even if saved value appears to be in the past
    FORCE=force
    There's a bug in that config fie....
    Having read the script that uses it that line should be:
    Code:
    FORCE=true
    The current setting mean that the script aborts, being unable to find a command "force", hence the lack of any update to /etc/fake-hwclock.data.
    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. #126
    ccs's Avatar
    Title
    ViX Beta Tester
    Join Date
    Sep 2014
    Posts
    5,836
    Thanks
    554
    Thanked 1,277 Times in 1,089 Posts
    ..... isn't FORCE simply a parameter passed onto fake-hwclock. eg fake-hwclock load FORCE

    fake-hwclock [ command ] [ force ]

    edit:

    Just moved onto 5.1.012, so can now see /bin/fake-hwclock

    ...
    FORCE=false
    if [ "$2"x = "force"x ] ; then
    FORCE=true
    fi
    ...
    Last edited by ccs; 19-01-18 at 16:19.

  7. #127
    ccs's Avatar
    Title
    ViX Beta Tester
    Join Date
    Sep 2014
    Posts
    5,836
    Thanks
    554
    Thanked 1,277 Times in 1,089 Posts
    ... fake-hwclock load FORCE should read fake-hwclock load force

  8. #128
    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
    So the setting is correct - "force", not "true". However, setting "force" seems to stop the process using the saved time at all, either on boot or on shutdown on my Mutant HD51, so maybe there is another issue?
    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

  9. #129
    ccs's Avatar
    Title
    ViX Beta Tester
    Join Date
    Sep 2014
    Posts
    5,836
    Thanks
    554
    Thanked 1,277 Times in 1,089 Posts
    .... I'm not so sure anymore, Birdman refers to a script which uses /etc/default/fake-hwclock, /bin/fake-hwclock doesn't.

  10. #130
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    Quote Originally Posted by fat-tony View Post
    So the setting is correct - "force", not "true". However, setting "force" seems to stop the process using the saved time at all, either on boot or on shutdown on my Mutant HD51, so maybe there is another issue?
    The Mutant HD51 is one of the boxes that appears to have no or no Linux access to the FP-RTC.

    The proc entry always reports "0" and by setting "force" you are enforcing setting the box to that value ... which is exactly the reason why you need a special parameter to also restore bad times from RTC.
    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. #131
    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
    @SpaceRat - I recall seeing "0" reports on FP-RTC accesses on my HD51 as you say.

    Here is an example:
    Code:
    <   940.143> [eDVBLocalTimerHandler] no transponder tuned... or no TDT/TOT avail .. try to use RTC :)
    <   940.143> [eDVBLocalTimerHandler]    getRTC returned time=0. RTC problem?
    What do you mean by this, please - "which is exactly the reason why you need a special parameter to also restore bad times from RTC" ?
    Last edited by Joe_90; 19-01-18 at 18:08.
    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. #132
    SpaceRat's Avatar
    Title
    Senior Member
    Join Date
    Apr 2015
    Posts
    206
    Thanks
    25
    Thanked 79 Times in 52 Posts
    Quote Originally Posted by fat-tony View Post
    What do you mean by this, please - "which is exactly the reason why you need a special parameter to also restore bad times from RTC" ?
    It's the reason why "FORCE" exists:
    As I said, the FP-RTC can not be behind the fake-hwclock, only ahead.

    You simply can't flash the image before it was built and you can not boot the box before the previous shutdown ... impossible, that's why the script simply doesn't do that ... unless you set the FORCE option.
    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)

  13. #133
    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
    Ok - I think I see

    However, on my HD51 I have had several instances where the time has advanced due to the ntpdate-sync running twice on Vix. This seems to be a Vix feature/bug due to the lock file not being created. Then, because of timing issues on WiFi (or some other reason), the clock is not being set correctly on startup and I end up continually running a future date which messes up my PowerTimers and recording timers and EPG etc. The only way for me to resolve this at the moment is to use the "force" parameter which is forcing the system to use the start of the epoch and messes with the filename of the Vix debug log.

    Before any these changes were made my HD51 was running fine on NTP setting by WiFi and the debug logs had proper current dated filenames. I think if the double start of ntpdate-sync was eliminated it would remove the "future date" issue, but there is obviously some other difference as to how my box is setting NTP date and time now versus how it was doing it in the past. I think the significant difference is that previously enigma.sh was running ntpdate directly at system start. That has been removed now and ntpdate-sync is doing it instead but I think it's happening too early in the boot sequence in my particular case. I know that @birdman posted an amended script (and I have used it) but it doesn't seem to work for me.
    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

  14. #134
    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 SpaceRat View Post
    The Mutant HD51 is one of the boxes that appears to have no or no Linux access to the FP-RTC.
    Both of my boxes (an Xtrend et800 and a Miraclebox MBtwin) also have a /proc/stb/fp/rtc that always return 0.

    The proc entry always reports "0" and by setting "force" you are enforcing setting the box to that value ... which is exactly the reason why you need a special parameter to also restore bad times from RTC.
    You can try to set any value you wish on these systems (including the current time) and that rtc device file will still return 0. Setting "force" makes no difference to that.
    This is why fake-hwclock writes the current (== latest) time to a file, precisely because there is no valid RTC n the system.

    But since, by definition, that restores an incorrect time at boot up, then any system that is able to use NTP should do so before any other processes are started.

    This would mean that if enigma2 is used to set time internally using NTP then it could skip the immediate one (just set up the every 30min ones) as it would know that the NTP time has just been set, if it is settable at all.
    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

  15. #135
    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 SpaceRat View Post
    It's the reason why "FORCE" exists:
    As I said, the FP-RTC can not be behind the fake-hwclock, only ahead.

    You simply can't flash the image before it was built and you can not boot the box before the previous shutdown ... impossible, that's why the script simply doesn't do that ... unless you set the FORCE option.
    The FORCE setting is only used to force a load at start-up. It isn't used when saving any clock value.
    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 9 of 19 FirstFirst ... 7891011 ... 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.