Max2Play Home › Forums › Max2Play on Raspberry PI › [SOLVED] Stuck at A start job is running for network time synchronization
- This topic has 17 replies, 4 voices, and was last updated 6 years, 2 months ago by Heiner premium.
-
Posted in: Max2Play on Raspberry PI
-
9. April 2018 at 21:54 #35090
Hello, just installed a 245 stretch version of M2P on a RPI 3 Model B+. More often than not, system startup gets stuck at a continuous loop of:
- A start job is running for Network Time Synchronization
- Failed Starting Network Time Synchronization
- Stopped Network Time Synchronization
- Starting Network Time Synchronization
No matter how long I wait, it never ends. I have to restart and pray that next time it goes further (which it sometimes does not).
Does anyone have a similar issue (and a solution)?
BTW, I just purchased a premium license, but had to register again to be able to post in the forums. Is this normal?
Kind regards
10. April 2018 at 11:09 #35102Hi air_ii,
Do you use a sound card or any other periphery on your Pi?
10. April 2018 at 11:19 #35103Hi, Heiner, yes, I have a Justboom Amp + Raspberry Pi 3 model B+, powered by a 19V 90W power supply.
10. April 2018 at 13:47 #35105I will just add that I am experiencing the same behaviour on two different sets of hardware.
10. April 2018 at 14:52 #35107We are currently looking into this and hope to have a fix very soon. Thank you for sharing this issue.
10. April 2018 at 17:19 #35110Sure. Let me know, if there is anything I can do to help you (logs, additional debugging, etc)
11. April 2018 at 9:53 #35117Hi airlii,
Please try renaming the Pi. This fixed the issue for us and it did not come back.
11. April 2018 at 18:02 #35132It seems to be related to the router’s device list. If you find your pi there, remove the entry and try rebooting the pi.
11. April 2018 at 18:12 #35133No luck. I’ve actually had mine already renamed (Settings / Reboot menu). Renamed it again, but to no avail.
11. April 2018 at 22:52 #35136Nothing there. I’ve gone through all possible settings within my managed switch (HP1920) that does all the routing (internal) in my network. But it appears that the issue is there even when the LAN cable is disconnected (wifi off).
12. April 2018 at 9:23 #35138Hi air_lii,
Do you have an overview of the device’s recognized in your network and can you manually delete them?
Please also try updating your system if you have not yet.
13. April 2018 at 22:42 #35172I have a list of devices in my DHCP server client list and there is ARP cache on my switch. I flushed ARP cache (although there was no reference there to the system) and deleted my Pi from DHCP client list.
However, I do not think it is related to my particular network setup, as it also happens when the Pi is disconnected from the network and also, it hangs in a place long before any DHCP request is sent (if it boots correctly).
- This reply was modified 6 years, 8 months ago by air_ii.
13. April 2018 at 22:44 #35173What is also interesting is that if I boot the system from PXE/iSCSI, it never happens – most likely due to the network being up already. Too bad PXE boot is riddled with bugs on Pi, so it’s not an option, sadly.
- This reply was modified 6 years, 8 months ago by air_ii.
15. April 2018 at 23:25 #35195I think I figured it out. It happened due to two different overlay audio drivers being loaded in config.txt:
dtoverlay=iqaudio-dacplus disable_overscan=1 dtoverlay=justboom-dac
By disabling
dtoverlay=iqaudio-dacplus
I got rid of the issue.4. Oktober 2018 at 12:43 #38383Hi Alex,
The config.txt is listed in the main folder of the boot partition.
7. Oktober 2018 at 0:22 #38409Thanks, commenting out dtoverlay=iqaudio-dacplus did the job for me too.
8. Oktober 2018 at 12:24 #38426We will have a look at this issue and inform you of the changes we might make to the JustBoom integration to fix it. Thank you for sharing your results.
-
You must be logged in to reply to this topic.