[RPi4] NTP Problem

    Hi. New to LE. Moving from OSMC. I installed the latest stable LE (2025.11) to a brand-new fast and large SD card to use with my 2G Rpi 4. This issue with time not setting correctly is a real problem though and not a great introduction to the product, sadly.

    It took me hrs of searching and troubleshooting yesterday to realize why my device had no internet. Now I've...

    - Set the KODI 'Regional' settings to my proper 'Timezone country' and 'Timezone'
    - Turned on the 'Wait for network before starting KODI' LE option with a 'Maximum Wait Time (Sec.)' of two (2) minutes (120 secs)
    - Added three (3) NTP Servers in LE settings (ncnoc.ncren.net, time.nist.gov, time.google.com). The first is here in my state. Can't get much closer to me. :)

    ...and the thing still only gets the proper time on reboot maybe 50% of the time!

    It's really frustrating to say the least and with all the complaints going back more than 10 years I'm frankly amazed nothing's ever been done in the product to resolve this. Maybe there's nothing that *can* be done? The suggestion to add an RTC to the RPi feels like a cop-out as well (found that multiple times).

    I suppose there might be some sort of startup script that could help, but Ive never found one in all the threads I discovered around this. Does anyone have anything that works, 100% of the time, or any other constructive suggestions (besides getting an RTC or just going back to OSMC)?

    I really want to join this cool kids club with y'all, but this is souring my milk boys, to say the least. Appreciate any and all help.

  • Go to Best Answer

    Oh, forgot to mention: this is hard-wired. Not using wi-fi. Also, exact same devices and hardware work fine with OSMC and rPi OS. I just swapped the SD cards and made no other changes. This is not a hardware issue on the Pis or with my cables or my network.

    Pick a current LE13 nightly and set the timezone in the LE settings addon (as it moved from Kodi in K22); not that timezone has anything to do with NTP and set wait for network. There is no need to set manual NTP servers unless your network or ISP blocks the ntp.org servers that we default to. “Nothing has been done” about NTP issues because there aren’t any issues to do anything about. NTP works fine for 99.999999% of users; the odd problem with ISP blocks or weird routers is seen but that’s all, and a rare event. Yes there are odd posts in the forum, but over a large userbase (and 80% RPi boards) that’s just statistics.

    Thanks for the help. I put LibreElec Version 13 nightly from 2026-AUG-05 on my 2G Pi4 and set the time zone during the boot up wizard. Time is off by over 4hrs and DATE is off by just under 2 weeks. It thinks it's AUG 18. :(

    I have a pfSense device on my network acting as an NTP server. I know it's working because I set my Win 11 PC to use it and then checked the results (w32tm /config /manualpeerlist...., /query /source, and /query /status) but setting the same IP in the KODI LibreELEC settings (Network\NTP servers) doesn't change anything after a device reboot. Is there anything else I can do to force LibreELEC to use 10.0.0.1 for NTP? SSH commands or file modifications, perhaps? I should think this would eliminate ISP (ATT Fiber) as the issue since LibreELEC wouldn't even leave the house for NTP, presumably. :)

    ACK! I just found the method to set my ethernet connection to manual instead of DHCP in the LibreELEC KODI settings, and that has an NTP Servers section too. I changed to manual, set the NTP there to 10.0.0.1 and saved. All fixed!

    Should the Kodi>LibreELEC>Network>NTP Servers values override every other, including DHCP? Doesn't seem so.

    Code
    # List of Fallback timeservers separated by ",".
# These timeservers are used for NTP sync when there are
# no timeservers set by the user or by the service, and
# when UseGatewaysAsTimeservers = false. These can contain
# mixed combination of fully qualified domain names, IPv4
# and IPv6 addresses.
FallbackTimeservers = 0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org

    This is our default config ^ and we don't set UseGatewaysAsTimeservers anywhere in /etc/connman/main.conf

    On boot (cold or warm) the initial datetime value in the kernel on any device with no RTC chip starts from the libc release date. Once the network is up and NTP runs the initial datetime value is corrected. This approach works fine unless something either blocks or manipulates NTP requests. Most consumer routers with a firewall don't support NTP in the DHCP scope, but pfsense has a deeper featureset and might be setting itself as an NTP source which would override defaults. When you set entries in the LE settings add-on you customise the defaults, but defaults will still be overridden by anything received in the DHCP scope.

    Check the clock on the pfsense box; if this is incorrect (has drifted) it would result in propagation of wrong datetime via DHCP and that might explain future dates appearing. It's also possible that pfsense intercepts and responds to NTP requests traversing the firewall regardless of what you configure locally; except for the manual IP configuration use-case where you explicitly tell ConnMan to use a local subnet source; and since DHCP is not used it is not overridden through the scope.

    ConnMan events (sources, corrections, etc.) should all be logged and visible in the systemd journal.

    NB: The only way to guarantee correct time from the start of boot with an RPi board that has no RTC chip; is adding an RTC chip. As those are cheap and simple to add it's always a valid answer for some people's use-cases (esp. with offline usage).

    Thank you for the continued assistance chewitt!

    • My pfSense device time and date are correct on the main page, the NTP server is syncing with internet time servers properly per logs, and the pfSense DHCP server is telling clients to use that device only (10.0.0.1) for NTP (single NTP entry in pfSense DHCP Server page).
    • Looking at my network connection in the LE add-on (Connections>eth0 (online)>Edit>NTP Servers), which is set to DHCP and "Connect automatically", I see this list below. WiFi connection is off, BTW.
      • 10.0.0.1 (my pfSense)
      • 0.pool.ntp.org (added by LE?)
      • 1.pool.ntp.org (added by LE?)
    • LE add-on>Network has one NTP entry: 10.0.0.1
    • LE add-on>Network>Wait for network.... is enabled and set to 120
    • On reboot, connmanctl clock returns this below which is correct (epochconverter.com says 1787237407 is "Thursday, August 6, 2026 at 12:02:20 PM UTC-04:00 DST" which is correct at time of writing).

    Time = 1787237407
    TimeUpdates = auto
    Timezone = America/New_York
    TimezoneUpdates = auto
    Timeservers = [ 10.0.0.1 ]
    TimeserverSynced = True


    Despite all this, the time displayed inside KODI is ~ 2 weeks ahead (time is ~1 hr behind (it varies) and date in Interface>Regional is AUG 20, 2026 (constant)).


    ===Troubleshooting===

    • I copied /etc/connman/main.conf to /storage/.config/connman_main.conf and set UseGatewaysAsTimeservers=true to see if that would help. It did not.
    • Using static IP settings instead of DHCP in LE add-on settings also does not work.
    • I tried changing the timezone inside LE addon to something else, then back to mine. Nope; KODI timedate did not refresh.
    • systemctl restart kodi didn't make KODI refresh

    The only 100% reliable way I've found so far to get the datetime to update to the correct values in KODI is to enter LE add-on settings post-reboot and Disconnect\Connect eth0 ("refresh" doesn't do it). Then the datetime in KODI is instantly updated.

    I hear you and understand RE RTC, but I'm hoping for a software solution. Any more thoughts or suggestions given the above? It's starting to feel like a KODI problem now rather than anything else.

    1787237407 is 2026-08-20 16:50:07 CEST, so KODI is correct.

    Unix Time Stamp - Epoch Converter
    Epoch and unix timestamp converter for developers. Date and time function syntax reference for various programming languages.
    www.unixtimestamp.com

    Perhaps I shouldn't pass up this opportunity. Can you install a Kodi add-on that lists the lucky numbers from the past 14 days and sends them to me? ;)

    Edited once, last by HarryH (August 6, 2026 at 10:05 PM).

    I posted a reply to HarryH here yesterday, acknowledging he was correct about the Epoch time in my previous post. My bad. Sorry about that. I know he read it because he replied to me about it directly in "conversations", but the post is not here.

    Are my posts getting deleted?

    Confirmed buy another user (below). My posts were here... for a time anyway. I really hope that was just a glitch in the system.

    Quote

    "Yes, I saw your 2 comments for a short time within the thread. But then they disappeared.."

    Anyway, I just wanted to emphasize that the values shown by connmanctl clock and that shown inside KODI are always different for me following a reboot. The first is correct, and the latter is two weeks in the future.

    Also, the only 100% fix I've found is to change eth0 using LE add-on from DHCP to Manual, save, and then set it back to DHCP and save (not disconn/conn as earlier stated). Brain fart there 🧠💥. Apologies.

    connmand is adjusting twice:

    Code
    Jul 23 13:07:11.494065 KODI-BED connmand[565]: Interface eth0 [ ethernet ] state is configuration
Jul 23 13:07:11.506966 KODI-BED connmand[565]: ipconfig state 3 ipconfig method 1
Jul 23 13:07:11.521631 KODI-BED connmand[565]: Interface eth0 [ ethernet ] state is ready
Jul 23 13:07:11.521689 KODI-BED connmand[565]: Interface eth0 [ ethernet ] is the default
Jul 23 13:07:11.521706 KODI-BED connmand[565]: Setting domainname to NewfieNet.home
Jul 23 13:07:11.556887 KODI-BED connmand[565]: eth0 {add} address 10.0.0.82/24 label eth0 family 2
Jul 23 13:07:11.557778 KODI-BED connmand[565]: Skipping server 10.0.0.1 KoD code RATE
Jul 23 13:07:11.593121 KODI-BED connmand[565]: ntp: adjust (jump): +1282755.551565 sec
Aug 07 09:26:27.146046 KODI-BED connmand[565]: ntp: adjust (jump): +1282755.552203 sec
Aug 22 05:45:42.790749 KODI-BED systemd[1]: Finished wait-time-sync.service.

    I scrolled through the log as far as the piracy add-ons, then I lost all interest in this problem. NB: the add-ons are not technically on the Kodi banned list at the current time, but I've flagged them to be added.