Public Beta Test: Audio Without Compromise - Refining the Future of Volumio on Bookworm

[HeadGeek]

@nerd
FYI inline upgrade from 4.0.17 to 4.0.18 bricked both my units - don’t know why
Re-flash to clean 4.017 and upgrade (no plugins installed) gave me same results. Both units are now back in operation with re-flashed 4.0.17.
System Information
OS info
Version of Volumio: 4.017
Hostname: musicbox
Kernel: 6.12.34-v7+
Governor: performance
Uptime: 0 days, 0 Hrs, 2 Minutes, 43 Seconds
Audio info
Hw audio configured: Innomaker Dac
Mixer type: Hardware
Number of channels: 2
Supported sample rate: 22050 44100 48000 88200 96000 176400 192000 384000
Board info
Manufacturer: Raspberry Pi Foundation
Model: Raspberry Pi 3 Model B Plus Rev 1.3 Raspberry Pi
Version: a020d3
Firmware Version: May 14 2025 12:25:02 Copyright (c) 2012 Broadcom

System Information
OS info
Version of Volumio: 4.017
Hostname: musicbox2
Kernel: 6.12.34-v7l+
Governor: performance
Uptime: 0 days, 0 Hrs, 8 Minutes, 55 Seconds
Audio info
Hw audio configured: IQaudIO DAC Plus
Mixer type: Hardware
Number of channels: 2
Supported sample rate: 22050 44100 48000 88200 96000 176400 192000 384000
Board info
Manufacturer: Raspberry Pi Foundation
Model: Raspberry Pi 4 Model B Rev 1.5 Raspberry Pi
Version: b03115
Firmware Version: 2025/05/08 16:21:35 version 69471177ba7e4cb7597cb2496f2a0b23f19c1113 (release)

Regards,

[nerd]

Hey @HeadGeek,

I don’t think 4.018 is released in the BETA channel yet.

Is it listed in Direct Downloads?

Kind Regards,

[Raw]

I also have, When updating from version 4.017 to version 4.018, the device does not load and does not respond in any way. I did the update through the System - update 4.018 appeared there and I agreed
Rpi 5 8GB, SD 32Gb

[HeadGeek]

Not listed in direct downloads but it was offered as an update on the beta channel:

Too eager to update ?
Regards,

[nerd]

Dear Volumionauts,

I have identified a critical issue affecting the current Volumio Beta build, particularly related to the latest kernel updates sourced via rpi-update. Recent upstream changes have introduced non-standard kernel version suffixes (e.g. +rpt-rpi-2712, +rpt-rpi-v6, etc.), which are causing depmod to fail and break the boot process. Systems may get stuck at the init /dev/loop stage and become unbootable.

Action Required:
Please hold off on updating Beta systems until this situation is fully resolved. If you are already on the affected update and encountering boot issues, do not proceed with further updates or reflash to previous version until we provide a stable recovery path.

We are actively investigating and will post an update as soon as a fix is confirmed.

Kind Regards,

[Gelo5]

Same goes for the official version!! (3.xxx —> 3.828)

[balbuze]

I saw your message too late…

[B505]

I should know better and checked here first before I clicked upgrade. F__k.

[nerd]

Dear Volumionauts,

I want to acknowledge a critical issue affecting some Raspberry Pi-based systems running the Volumio BETA 4.018 kernel series (6.12.34). Specifically, several unintended kernel module directories such as:

• 6.12.34+rpt-rpi-2712
• 6.12.34+rpt-rpi-v6
• 6.12.34+rpt-rpi-v7
• 6.12.34+rpt-rpi-v7l
• 6.12.34+rpt-rpi-v8

…were introduced during the upstream kernel packaging process. These directories are incomplete (missing modules.builtin, modules.order, and modules.builtin.modinfo), resulting in depmod warnings and in some cases causing broken boots, particularly on Raspberry Pi 5.

My working theory is that this is an unintended effect of Trixie rollout.

This was not present in builds prior to Volumio 4.017 and appeared during packaging changes over the past few days.

Root cause:
The build process was unintentionally retaining module directories created by kernel Makefiles targeting INSTALL_MOD_PATH variations not required in Volumio. These stray folders were not cleaned before the final packaging stage, leading to unnecessary kernel variants appearing under /lib/modules.

Fix status:
We have implemented a clean-up mechanism that explicitly removes these +rpt-rpi-* folders before depmod and initramfs stages. This resolves the boot issue on affected devices. Devices that were stuck in boot due to this will now complete successfully once updated.

Next steps:

• A fixed build has been confirmed on Raspberry Pi 4B/5/CM5 and will be deployed shortly.
• If your device is affected and unable to boot, manual intervention may be required to re-flash 4.017 or 4.019 directly.
• A full OTA-safe update with this fix will be released as Volumio BETA 4.019.

We thank our community for their patience while we addressed this under time pressure.

Kind Regards,

[nerd]

Dear Volumionauts,

I am pleased to confirm that the critical kernel module issue affecting some Raspberry Pi devices has now been fully resolved in Volumio BETA v4.020.

This build includes the following fix:

• All stray +rpt-rpi-* kernel module directories are now removed during finalization
• depmod warnings are cleared
• Clean boot is restored on all tested Raspberry Pi 4, 5, and CM5 units

If you experienced a boot failure in versions 4.018, please upgrade directly to v4.020 or re-flash using the latest image.

This fix ensures stability ahead of wider Bookworm rollout. Thank you for your continued support during this phase.

Kind Regards,

[RedEyeNinja]

OTA-updated a PC based and a Pi5 Volumio from 4.017 to 4.020. No issues.

[Wheaten]

OTA form V4.017 to V4.20, all went OK (Besides Spotify)

• Model: Raspberry Pi 4 Model B Rev 1.4 Raspberry Pi
• Innomaker DAC Mini
• Touch Display
• Argon V2 (+ Fan/Power button script)
• Custom based Pyhton3 scripts for OLED
• NAS NFS and CIFS mount
• Qobuz
• Tidal
• Spotify (needs re-authentication after every reboot approx. since V4.014)
• FusionDSP
• IR Controller
• Peppy Spectrum
• IR Controller
• Rotary Encoders
• System Info
• Touch Display (DSI)

[DungLD]

I haven’t seen the 4.020 update via OTA yet.

[Wheaten]

you have set the update channel to test?

[DungLD]

Thanks a lot.
I’m updating.
. . . . . . . . . . .

I updated successfully.
However, there is still a problem with the FunsionDsp Plugin (I don’t use it - just turned it on to test).
Only DSD music can be played if FunsionDsp plugin is disabled.

[Wheaten]

That is correct see:

FusionDsp : the complete Dsp center for Volumio3!

Hello. Dsd can’t be equalise without conversion. This is not a FusionDsp (or CamillaDsp) limitation but DSD bu design.

[Raw]

Version 4.020 scanning Music from a mounted NVME M2 SSD does not work.
In Detail.

My settings NVME M2 SSD

sudo mkdir -p /mnt/NVME
sudo mount -t auto /dev/nvme0n1p1 /mnt/NVME (nvme0n1p1 is my M2 SSD with Music)

sudo blkid

---

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
`-nvme0n1p1 ext4 1.0 nvme xxxxx 390.9G 9% /mnt/NVME

---

this /mnt/NVME simlinked to /var/lib/mpd/music
and
sudo nano /etc/fstab
LABEL=nvme /mnt/NVME ext4 defaults,nofail 0 2

This settings working in 4.017 - Scanning /mnt/NVME to Music Library - OK
But in 4.020 updated from 4.017 System/System Updates (test channel) Scanning Music Librery not working.
In Log 4.020 by start Scanning Music Librery this records:

info: CoreCommandRouter::executeOnPlugin: mpd , updateDb

info: CoreCommandRouter::executeOnPlugin: mpd , getMyCollectionStats
error: MPD error: The expression evaluated to a falsy value:
  assert.ok(self.idling)
error: The expression evaluated to a falsy value:
  assert.ok(self.idling)
  ....

HW: Rpi5 8Gb, SD 32gb (OS Volumio), NVME M2 SSD(Music files)
Installed Plugin: TouchDisplay, NowPlaying

[nerd]

Hey @Raw,

Thanks for your detailed report. You’ve provided a solid breakdown of the OTA from version 4.017 to 4.020. After reviewing both your setup and the Volumio backend source, the issue appears to stem from a mismatch between your manual mounting method and the supported automount logic used by Volumio.

You mentioned:

sudo mkdir -p /mnt/NVME
sudo mount -t auto /dev/nvme0n1p1 /mnt/NVME (nvme0n1p1 is my M2 SSD with Music)
...
LABEL=nvme /mnt/NVME ext4 defaults,nofail 0 2

And:

• /mnt/NVME is symlinked to /var/lib/mpd/music
• This setup worked fine in 4.017, but in 4.020 the log shows:

info: CoreCommandRouter::executeOnPlugin: mpd , updateDb
info: CoreCommandRouter::executeOnPlugin: mpd , getMyCollectionStats
error: MPD error: The expression evaluated to a falsy value:
  assert.ok(self.idling)

This error typically means MPD’s event loop is out of sync, possibly due to attempting a scan while the backend believes the database or files are still loading.

The deeper issue is likely this: manual fstab entries are not guaranteed to persist across OTA updates, and even when present, may not be evaluated early enough to populate the directory before Volumio initiates its scan.

Volumio provides an official way to mount internal storage automatically by using a supported disk label. As seen in the backend code:

var internalMemoryAllowedLabelsArray = ['issd', 'ihdd', 'Internal SSD', 'Internal HDD'];

If you label your SSD using one of those values (e.g. issd), Volumio will treat the device as internal storage and mount it automatically without needing /etc/fstab. This ensures proper integration into the startup and library scan flow.

To align with the supported method:

1. Change your disk label:

   sudo e2label /dev/nvme0n1p1 issd
   

2. Remove your /etc/fstab entry for this mount.

3. Remove the manual symlink to /var/lib/mpd/music if it still exists.

Volumio should then detect the internal SSD, mount it under its managed location, and index it properly into the Music Library during startup.

If you still encounter the same assert.ok(self.idling) error after adopting the supported method, it may indicate a misconfiguration introduced in 4.020 affecting MPD idle state tracking. Please confirm and we can escalate accordingly.

Kind Regards,