Here you are
volumio@volumiopc:~$ for ep in
http://www.taobao.com
http://www.jd.com
http://www.qq.com
http://www.sina.com.cn
http://www.aliyun.com
do
d=$(curl -sI -L --max-time 5 “$ep” | sed -n ‘s/[1]ate:[[:space:]]*//p’)
printf “%-28s → %s\n” “$ep” “${d:-}”
done
http://www.taobao.com →
http://www.jd.com →
http://www.qq.com →
http://www.sina.com.cn →
http://www.aliyun.com →
Dd ↩︎
All → no Date header>
Hey @huyen82,
Let’s run a few very simple checks to see if your PC can reach the internet and resolve names. Please copy the commands exactly as shown. They use only plain ASCII and one command per line.
ip addr
ip route
getent hosts www.baidu.com
getent hosts www.taobao.com
getent hosts time.is
If getent says command not found, use:
ping -c1 www.baidu.com
ping -c1 www.taobao.com
ping -c1 time.is
cat /etc/resolv.conf
curl -sI -L --max-time 5 http://www.baidu.com | awk 'NR==1 || /^Date:/'
curl -sI -L --max-time 5 http://www.taobao.com | awk 'NR==1 || /^Date:/'
curl -4 -sI -L --max-time 5 http://www.baidu.com | awk 'NR==1 || /^Date:/'
curl -4 -sI -L --max-time 5 http://www.taobao.com | awk 'NR==1 || /^Date:/'
curl -sI -L --max-time 5 http://example.com | head -5
curl -V
env | egrep -i 'http_proxy|https_proxy|no_proxy'
ping -c1 223.5.5.5
ping -c1 114.114.114.114
Please paste the outputs from all of the above. Based on those results we will suggest the next step, including endpoints that work best in your network.
Kind Regards,
I am in Vietnam not China
Thanks for clarifying @huyen82, Vietnam not China - good to know.
In that case the same checks I listed above still apply.
Kind Regards,
Not sure if this is correct
Sorry for having to use google translate.
volumio@volumiopc:~$ ip addr
ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fc:3f:db:0c:f0:c2 brd ff:ff:ff:ff:ff:ff
altname eno1
altname enp0s31f6
inet 192.168.1.14/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 1130sec preferred_lft 905sec
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.14 metric 1002
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.14 metric 1002
volumio@volumiopc:~$ getent hosts www.baidu.com
getent hosts www.taobao.com
getent hosts time.is
volumio@volumiopc:~$ ping -c1 www.baidu.com
ping -c1 www.taobao.com
ping -c1 time.is
ping: www.baidu.com: System error
ping: www.taobao.com: System error
ping: time.is: System error
volumio@volumiopc:~$ cat /etc/resolv.conf
nameserver 210.245.1.254
nameserver 210.245.1.253
nameserver 208.67.222.222
nameserver 208.67.220.220
volumio@volumiopc:~$ curl -sI -L --max-time 5 http://www.baidu.com | awk ‘NR==1 || /^Date:/’
curl -sI -L --max-time 5 http://www.taobao.com | awk ‘NR==1 || /^Date:/’
volumio@volumiopc:~$ curl -4 -sI -L --max-time 5 http://www.baidu.com | awk ‘NR==1 || /^Date:/’
curl -4 -sI -L --max-time 5 http://www.taobao.com | awk ‘NR==1 || /^Date:/’
volumio@volumiopc:~$ curl -sI -L --max-time 5 http://example.com | head -5
curl -V
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.17 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u14
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
volumio@volumiopc:~$ env | egrep -i ‘http_proxy|https_proxy|no_proxy’
volumio@volumiopc:~$ ping -c1 223.5.5.5
ping -c1 114.114.114.114
PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.
— 223.5.5.5 ping statistics —
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING 114.114.114.114 (114.114.114.114) 56(84) bytes of data.
— 114.114.114.114 ping statistics —
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Hey @huyen82,
Thank you for sharing the logs. From what you posted, your Volumio box is not reaching the outside network at all:
getent hosts is empty).curl tests returned any headers.This points to a network connectivity problem on the Volumio PC itself or at the router/ISP level, not the time sync script. To confirm, please run just these two commands and copy-paste the full output:
curl -v --max-time 5 http://example.com
curl -v --max-time 5 http://1.1.1.1
The first test shows if DNS resolution is working. The second test bypasses DNS and checks if you can reach a raw IP.
Once we see those results we can tell whether it is DNS, routing, or a firewall issue.
Kind Regards,
Maybe it’s my router configuration.
volumio@volumiopc:~$ curl -v --max-time 5 http://example.com
Resolving timed out after 5000 milliseconds
Closing connection 0
curl: (28) Resolving timed out after 5000 milliseconds
volumio@volumiopc:~$ curl -v --max-time 5 http://1.1.1.1
Trying 1.1.1.1:80…
Connection timed out after 5002 milliseconds
Closing connection 0
curl: (28) Connection timed out after 5002 milliseconds
Hey @huyen82,
Perfect, now we have the smoking gun. Both tests failed:
example.com timed out on DNS resolution.1.1.1.1 timed out on a direct IP connection (so even bypassing DNS, it cannot connect).That rules out the helper script entirely. The issue is with your network path: router firewall rules, outbound filtering, or possibly ISP-level restrictions.
Your Volumio PC has no working route to the internet right now. Both DNS and direct IP access fail. This is not a Volumio problem, but a network one. Please check:
ping -c1 192.168.1.1).Once your network allows normal outbound traffic, the time sync helper will work automatically.
Kind Regards,
Thanks.
Let me try to check my router configuration and get back to you.
Sorry to you and everyone for wasting everyone’s time.
It was true that this computer had a misconfiguration in the router, I fixed it and the time sync helper worked fine.
Hey @huyen82,
Thanks for confirming. This is a good reminder that if setdatetime-helper fails, the first step is always to verify outbound network and DNS reachability - otherwise the helper has no way to fetch time. Glad you got it resolved.
Kind Regards,
Here is the latest log: http://logs.volumio.org/volumio/yM9yJ8D.html
I followed your instructions. The problem is that after I click update and then it fails, there is no way to prevent the reboot. It automatically reboots on it’s own. I waited 5 seconds into the 15 second countdown to click send logs.
Installed 4.028 and boot time from startup to discovery on my Android tablet has significantly increased.
I may have fixed it. I disabled wireless networking.
Raspberry pi 5 with Argon one V5 case (integrated USB audio in the case) +
M.2 NVME drive
Volumio 4.027 installed onto m.2 drive with :
sudo dd if=volumio.img of=/dev/nvme0n1 bs=4M status=progress conv=fsync;sync
directly from raspberry 5, booted from sdcard.
It is neccessary to add dtoverlay=dwc2, dr_mode=host to /boot/userconfig.txt as per Argon documentation in order to enable USB audio device and get audio output on 3.5mm jack and mic input on pi5. (Argon suggest adding this lines to /boot/config.txt but since that file is managed by volumio it’s better to add it to /boot/userconfig.txt
# Use userconfig.txt because /boot/config.txt is managed by Volumio
CFG="/boot/userconfig.txt"
sudo sed -i '/^dtoverlay=dwc2/d;/^dr_mode=/d' "$CFG" 2>/dev/null || true
echo 'dtoverlay=dwc2,dr_mode=host' | sudo tee -a "$CFG"
After reboot volumio displays usb output device in Playback options → Output device right below HDMI output. You can verify if usb device is recognized with lsusb command or aplay -l
bash-5.2# lsusb
Bus 001 Device 003: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)
Bus 001 Device 002: ID 1a86:8091 QinHeng Electronics USB HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bash-5.2# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 5: Device [USB Audio Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
bash-5.2#
It is important NOT to use ethernet (wired) and wifi at the same time since this will crash Volumio 4.027 during initial setup.
Don’t select I2S interface as volumio output device since Argon One v5 has USB DAC and NOT I2S.
I am experiencing a recurring issue that I can finally pin down. On my Pi5 booting on NVME and 4.0.28, and going back to maybe as far as 4.0.21, I would have intermittent loss of library. I’ve cleaned up non-audio files using “ignore file” and the issue persists. In the midst of troubleshooting this, I’ve gone thru a number of things such as power supply, cabling and OTA and fresh install direct on the NVME and everytime I rebooted on 4.0.28, I’d lose all my track listings but the NFS shares still showed. I ran the log thru ChatGPT and it suggested that the way the mounts are being done wasn’t to NFS format, but that isn’t issue as I have the same format for NFS shares on a Pi4 and PC and both of those have no issues with their libraries and reboot. However, ChatGPT gave me a few commands to run and when I ran them after deleting the shares, I saw no results. This was after an OTA update.
Afterthat I flashed 4.0.28 fresh onto the NVME direct and the issue persists, but I didn’t delete the shares, and instead ran these commands and the tracks listings popped back up.
Fix: SSH into Volumio and run:
volumio vstop
rm -rf /data/library/*
volumio vstart
I really have no idea what’s going and why it is isolated to my Pi5, as well as why these commands bring up my track listings again…but I have duplicated the situation exactly a few times now before reporting. Here’s a log after the track listings were brought back up after running those commands so I’m not sure how helpful it’ll be.
http://logs.volumio.org/volumio/gyYzcgI.html
[See edit below]
Here’s a log I’ve found from an earlier instance of the issue this evening but I believe it was from the OTA update:
http://logs.volumio.org/volumio/tb47Ik9.html
EDIT: I’ve ran the log thru ChatGPT and referencing the 3 commands that worked to bring it back up and this is what it says…specifically for #3 tho, it is something I am familar with [hard mounting shares] but I think I read somewhere, maybe this thread that it is not the recommended way. Sharing my my findings and hoping to hear from @nerd before I start applying fixes that won’t work:
That sequence lines up with what you see: after a reboot, your NAS shares mount a bit after MPD/Volumio starts, so MPD boots with empty / missing music directories and prunes the DB. When you run:
volumio vstop
rm -rf /data/library/*
volumio vstart
you force a clean rescan after the shares are already mounted, so everything reappears.
A boot-order / race condition: MPD (and Volumio’s library service) start before your NFS mounts are up, so the library is emptied on boot. Afterward, a manual restart + rescan fixes it because the mounts are finally available.
In Settings → Network, enable “Wait for network” and set a delay (start with 15–20 s).
This alone often solves it.
Create a small systemd “drop-in” for MPD so it only starts once the mounts exist.
sudo systemctl edit mpd.service
Paste this, replacing the example mount paths with yours:
[Unit]
Wants=network-online.target remote-fs.target
After=network-online.target remote-fs.target
# Ensure these mount points exist before MPD starts:
RequiresMountsFor=/mnt/NAS/DSD_Music /mnt/NAS/FLAC_Music /mnt/NAS/MP3_Music /mnt/NAS/NOW_FLAC
Then:
sudo systemctl daemon-reload
sudo systemctl restart mpd
If you use different mount paths, list those exact directories in
RequiresMountsFor=.
If you’re mounting via /etc/fstab (instead of only through the Volumio UI), add _netdev and x-systemd.automount so systemd understands the dependency and auto-mounts on first access.
EDIT2: I have taken a short vid of the boot up sequence where I’ve been noticing errors before botoup, it’s a little hazy, but I think I got 2 lines of it and I believe I have seen instances where 3 lines came up but it’d continue with bootup regardless:
[FAILED] Failed to listen on Music Player Daemon Socket
[FAILED] Failed to on - Music Player Daemon
Found an older pic, sorry for haziness:
Hey @RedEyeNinja,
Thanks again for the thorough breakdown and logs. You’ve done the right kind of testing here, and I’ve reviewed everything you shared - including the logs, boot behavior, and the reasoning behind the recovery steps.
At a high level, the symptoms do suggest a boot-time race condition: the music library appears empty after startup, yet is recoverable once the system is fully up. This strongly implies that the backend attempts to index or validate the music sources before the NFS shares are properly available. That much aligns with your findings.
However, let’s clarify a few key points based on how Volumio is designed:
While on general-purpose Linux systems, using systemctl edit mpd.service or RequiresMountsFor= might be standard practice, that logic does not apply to Volumio.
/etc/fstab, autofs, or systemd.mount units. Volumio mounts shares dynamically through its own logic based on configuration JSON files and backend triggers.So while the workaround you found may temporarily resolve the symptom, any changes to systemd unit files or fstab will:
Here lies the core problem: the backend is still shared between the Buster-based Volumio 3 and the Bookworm-based Volumio 4 builds. This design limits what we can cleanly change right now.
systemd boot).This is why we’re not yet able to restructure the mount and library service startup order. Any fix at this stage has to wait until we complete the ongoing networking rework, which is a required prerequisite for touching anything that depends on online state, including remote mounts.
I’ve added this to the backend rework backlog. Once networking is fully decoupled and Bookworm-specific behavior can be targeted independently, we’ll revisit:
In the meantime, your current recovery approach although works, is unsafe, I recommend avoiding any persistent systemd or fstab overrides - they will not interact with Volumio’s backend in a reliable or update-safe way.
@volumio - FYI
Kind Regards,
Literally the last point. The router had been knocked over onto its side!
I followed this with interest, and there is a report from a customer having the same issue. I think I’ve pinpointed the issue. I will follow up privately on this. We can do a new build with a proposed fix and see if that works