Just installed 4.025 RC (coming from 4.023) via OTA - went without problems.
Reboot from installer/GUI disappeared again.
.
Actually all of the system is working as excepted.
Really NICE, great job! Thanks a LOT!
(HW) Config:
Pi5,
Raspi 2 Display (DSI),
Two rotary encoders on several GPIOs
BT remote
Testing:
Spotify plugin, works (my only use case).
Touch display (and corresponding plugin) works
“Now Playing” plugin works
Bluetooth_remote plugin works
Rotary encoders are both working
WiFi is working (can access from laptop / phone).
BT remote working
CORRD link now only leads to corrd-webpage , no intergrations as far as I can see.
OK, Volumio has no operating problems, however it is full of things that can be improved, and not from a technical department. Maybe it’s better to postpone them.
I connected a Kingrex T20U via the Burr Brown PCM2702E integrated DAC (which is different from the DSD1702), and it works too well to be true.
I played a DSD64 in DSD direct mode and this should not be technically possible, not even knowing that other models from the same manufacturer can be switched from DSD mode to PCM or vice versa.
Are you sure that the interface declares that it can do what the manufacturer’s data book completely omits?
These things undermine confidence as much as the installation that continues to enable profiling in default mode, how many doubts do we still have to raise to change register?
I would prefer your software, which I love, to really do what it says to the user.
Good catch on the PCM2702E - according to the TI datasheet this DAC only supports 16-bit PCM up to 48 kHz and has no DSD mode at all. So if you hear playback of a DSD64 file, it must be going through conversion somewhere in the chain. The UI can still display “DSD Direct” depending on how the state is reported, but the easiest way to verify what is really happening is:
Run cat /proc/asound/card*/stream0 while playing your DSD file. This shows the formats the DAC is actually receiving. For a PCM2702E you will only ever see S16_LE at 32/44.1/48 kHz.
Enable verbose logging in MPD and check whether it prints a conversion step when opening the stream.
Compare CPU usage between a FLAC track and a DSD64 track on the same hardware - if you see a noticeable spike, that indicates software conversion is taking place.
These are straightforward checks that will confirm what the device is really being fed, independent of what the UI says.
If the DAC does not support DSD Direct Mode, and DSD Direct is enabled, audio is automatically resampled to PCM. This is explained in the setting (i) icon
New install 4.025 on Raspberry 4, 5inch DSI display IPS 800*480 touch screen error when installing Plugin Touch Screen “An error occurred while installing Plugin Error”
This plugin still works fine on version 3.832
Sorry I had to use google translate
Log: https://logs.volumio.org/volumio/sVzaFXV.html
Since the Bluetooth remote “works”, could users please write which minimalist BT remote work OOB without having to reconnect (on start and after remote sleeps) and rescan repeatedly? Thank you.
Sep 25 00:35:34 volumio volumio[1081]: [sudo] password for volumio: E: Release file for http://raspbian.raspberrypi.com/raspbian/dists/bookworm/InRelease is not valid yet (invalid for another 1d 4h 46min 20s). Updates for this repository will not be applied.
Sep 25 00:35:34 volumio volumio[1081]: E: Release file for http://archive.raspberrypi.com/debian/dists/bookworm/InRelease is not valid yet (invalid for another 23h 57min 32s). Updates for this repository will not be applied.
This causes an issue for the plugin to download the required software packages. You could try installing the plugin again later and see if the error has disappeared.
Raspberry PI 4B - Volumio 3.832 - Fritzbox 5590 is playing music files from the Fritzbox router’s media server ( SMB ). A USB drive is connected to the Fritzbox.
Raspberry PI 5 - Volumio 3.832 - Fritzbox 5590 is playing music files from the Fritzbox router’s media server ( SMB ). A USB drive is connected to the Fritzbox.
Raspberry PI 4B - Volumio 4.023 / 4.025 - Fritzbox 5590 is not playing files. Volumio does not recognize the media server from this router. A USB drive is connected to the Fritzbox.
Raspberry PI 5 - Volumio 4.023 / 4.025 - Fritzbox 5590 is not playing files. Volumio does not recognize the media server from this router. A USB drive is connected to the Fritzbox.
Thanks. I tried restarting and reinstalling the plugin, even rewriting the memory card but still the same error.
Sorry for having to use google translate
Looking at the log @gvolt pulled.
Check your dates on the rPi’s. Seems they have not synchronized.
Open a ssh connection and type: date
The result should be your local date and time if not run: /bin/bash -c "sleep 1; /usr/bin/sudo /bin/date -s \"$(/usr/bin/curl -s --head http://google.com | grep ^Date: | sed 's/Date: //g')\""
Thank you for your detailed comparison. At this stage we cannot determine the root cause without logs that capture the failing case. What we need is a log taken immediately after you try to add the Fritzbox drive through the Volumio UI:
Go to Settings → Sources → Network Drives → Add network drive.
Attempt to access your Fritzbox share exactly as you normally would.
Once it fails or the server is not recognized, immediately open http://<volumio-ip>/dev, click “Send log”, and paste the resulting URL here.
This log will show us what happens at the moment Volumio 4.025 attempts to discover or mount the SMB share, which is the only way we can see whether the failure is in discovery, negotiation, or mounting.
I have set the time zone correctly. volumio@volumio:~$ timedatectl show
Timezone=Asia/Ho_Chi_Minh
LocalRTC=no
CanNTP=no
NTP=no
NTPSynchronized=yes
TimeUSec=Fri 2025-09-26 16:43:19 +07
This is interesting indeed. Need to locate my thinking head…
… found it - yes, this points directly to NTP not being enabled, despite NTPSynchronized=yes being shown. The line
CanNTP=no
NTP=no
means systemd-timesyncd is not actually allowed to do its job. In Volumio Bookworm the helper scripts are supposed to switch it on at boot, but clearly in this case it did not.
Next steps I would suggest:
Confirm that the helper is present and enabled:
systemctl status setdatetime-helper.service
systemctl status setdatetime-helper.timer
If the timer is missing or inactive, you can temporarily enable NTP manually for testing:
sudo timedatectl set-ntp true
Recheck with:
timedatectl show
This time you should see CanNTP=yes and NTP=yes.
If that works, we know it is a failing setdatetime-helper component at boot, which needs some rethinking.
