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

[huyen82]

Not sure what’s wrong?
volumio@volumio:~$ systemctl status setdatetime-helper.service

systemctl status setdatetime-helper.timer

○ setdatetime-helper.service - Time Synchronization Helper Service

Loaded: loaded (/lib/systemd/system/setdatetime-helper.service; enabled; p>

Active: inactive (dead) since Fri 2025-09-26 16:56:20 +07; 1h 19min ago

Main PID: 918 (code=exited, status=0/SUCCESS)

CPU: 40ms

Sep 26 16:56:19 volumio systemd[1]: Starting setdatetime-helper.service - Time >

Sep 26 16:56:20 volumio bash[920]: Time is already synchronized.

Sep 26 16:56:20 volumio systemd[1]: setdatetime-helper.service: Deactivated suc>

Sep 26 16:56:20 volumio systemd[1]: Finished setdatetime-helper.service - Time >

lines 1-10/10 (END)…skipping…

○ setdatetime-helper.service - Time Synchronization Helper Service

Loaded: loaded (/lib/systemd/system/setdatetime-helper.service; enabled; p>

Active: inactive (dead) since Fri 2025-09-26 16:56:20 +07; 1h 19min ago

Main PID: 918 (code=exited, status=0/SUCCESS)

CPU: 40ms

Sep 26 16:56:19 volumio systemd[1]: Starting setdatetime-helper.service - Time >

Sep 26 16:56:20 volumio bash[920]: Time is already synchronized.

Sep 26 16:56:20 volumio systemd[1]: setdatetime-helper.service: Deactivated suc>

Sep 26 16:56:20 volumio systemd[1]: Finished setdatetime-helper.service - Time >

~

~

~

~

~

~

~

~

~

~

~

~

~

~

~

lines 1-10/10 (END)…skipping…

○ setdatetime-helper.service - Time Synchronization Helper Service

Loaded: loaded (/lib/systemd/system/setdatetime-helper.service; enabled; preset: enabled)

Active: inactive (dead) since Fri 2025-09-26 16:56:20 +07; 1h 19min ago

Main PID: 918 (code=exited, status=0/SUCCESS)

CPU: 40ms

Sep 26 16:56:19 volumio systemd[1]: Starting setdatetime-helper.service - Time Synchronization Helper Service…

Sep 26 16:56:20 volumio bash[920]: Time is already synchronized.

Sep 26 16:56:20 volumio systemd[1]: setdatetime-helper.service: Deactivated successfully.

Sep 26 16:56:20 volumio systemd[1]: Finished setdatetime-helper.service - Time Synchronization Helper Service.

volumio@volumio:~$ sudo timedatectl set-ntp true

Failed to set ntp: NTP not supported

[tweed77]

@nerd

Raspberry Pi 4/5 - Volumio 3.832 automatically recognizes the Fritzbox server (SMB) for access to the USB drive connected to this router.
It doesn’t provide any login credentials (username - password). I click the “Media Servers” option, and the Fritzbox router then has access to the music files on the USB drive.

Log:
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::volumioGetQueue
info: CoreStateMachine::getQueue
info: CorePlayQueue::getQueue
info: CoreCommandRouter::executeOnPlugin: system , getPrivacySettings
info: CALLMETHOD: system_controller my_volumio retreiveBackendEventStates undefined
info: CoreCommandRouter::executeOnPlugin: my_volumio , retreiveBackendEventStates
info: Received Get System Version
info: CoreCommandRouter::executeOnPlugin: system , getSystemVersion
info: Received Get System Info
info: CoreCommandRouter::executeOnPlugin: system , getSystemInfo
info: CoreCommandRouter::executeOnPlugin: volumiodiscovery , getThisDevice
info: Discovery: Getting this device information
info: CoreCommandRouter::volumioGetState
info: CoreCommandRouter::executeOnPlugin: network , getCachedIPAddresses
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared

Raspberry Pi 4/5 - Volumio 4.025 - after clicking the “Media Servers” option, I can’t access the Fritzbox router or music files.

info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared
info: CoreCommandRouter::executeOnPlugin: upnp_browser , handleBrowseUri
info: Preload queue cleared

As in the photo below:

[nerd]

Hey @tweed77,

Thank you for the screenshots and the extracted log snippets. This clarifies the situation.

• On Volumio 3.832 the Fritzbox server appears under Media Servers, and browsing continues correctly down to the USB contents. The log shows repeated handleBrowseUri calls with valid responses.
• On Volumio 4.025, selecting Media Servers still calls handleBrowseUri, but the result is empty. The Fritzbox server is not listed at all.

That means the problem is not with your Fritzbox or SMB credentials, but with UPnP/DLNA discovery in Volumio 4.x. In other words:

• Volumio 3.x: upmpdcli + upnp_browser detect Fritzbox fine.
• Volumio 4.x: upnp_browser plugin calls succeed but return no servers.

The missing piece now is a full system log link from Volumio 4.025 right after you reproduce this (click “Media Servers” so it fails, then go to http://<volumio-ip>/dev, press “Send log”, and paste the URL). The short snippet you shared shows the symptom but not the backend discovery messages, which are needed to see whether gmediarender/upmpdcli are running and responding.

As requested before - Could you generate and share that full log URL from the failing Volumio 4.025 case? That will allow a diagnosis.

Kind Regards,

[tweed77]

Post to be deleted

[nerd]

Hey @tweed77,

Thank you for sharing the screenshots and log fragments, but we really cannot move forward without a full system log taken right after reproducing the issue. Please follow this guide to generate and share the log link:
https://help.volumio.com/help/how-to-send-a-log-link-for-a-bug-report

Without that complete log, anything else would just be guesswork. If other community members have better crystal balls than I do, they are of course welcome to jump in - but for a technical diagnosis we need the hard evidence from a proper log.

Kind Regards,

[Josh2000]

for me everything is working - even the fritzbox wich i am not using but just for testing [quote=“nerd, post:1, topic:72576, full:true”]

Dear Volumionauts,

We are now entering the Public Beta Testing Phase of the next-generation Volumio - a major evolution built on Debian Bookworm.

This is not a simple OS upgrade. It reflects months of dedicated development: custom build systems, package refinement, and hardware enablement across all supported platforms.

Volumio Bookworm is designed for one purpose:

Bit-perfect playback, across modern and legacy hardware, without compromise.

Key Highlights:

• Complete audio path control - no detours, no conversions
• Bluetooth A2DP-only using BlueZ-ALSA - no HFP, no PulseAudio
• High-precision metadata transport across all interfaces
• Support for USB, I2S, and PCIe audio - whether local or networked
• Audiophile tuning for Bookworm-based builds, with minimal non-audio subsystems

Current Beta Targets:

• All Raspberry Pi models, including Raspberry Pi 5
• x86/AMD64 platforms (Intel NUCs, generic PCs)

Additional boards will follow during staged rollouts.

What to Test

System Hardware Support:

• I2C: DACs, displays, GPIO expanders
• SPI: OLEDs, rotary encoders
• GPIO: Buttons, IR, HATs, UART
• USB: Audio devices, CD drives, HID input
• Display: HDMI, DSI, MIPI, SPI (sleep/wake functionality)
• Boot: USB SSDs, NVMe, SD cards

Core Audio & Ecosystem:

• MPD Playback (FLAC, AAC, DSD via ALSA)
• CD Audio & Ripping (no GUI bloat)
• AirPlay
• Bluetooth Audio - Strict A2DP
• Multiroom Sync
• “Play Here” feature
• NAS Mounts via SMB/CIFS
• Casting to SONOS / Chromecast

Once stable, this Beta will replace the legacy system. Be sure to disable Test Mode when done.

Thank you for helping us validate this release and shape the future of Volumio for a new generation of hardware and listeners.

---

Release Channel Selector

Allowing you to easily choose which update stream your device follows:

• Stable – Default, production-grade releases
• Test – Pre-release builds with staging fixes (select for Beta OTA)
• Alpha – Experimental builds for early testing

You can find the selector at:
http://<volumio_ip>/dev

Nothing extra is needed – just visit /dev and select your preferred update channel.

---

WiFi diagnostics script

To help identify and support your WiFi hardware in Volumio, please follow these steps:

1. Download the script archive:

   • Download the attached wifi-info.zip file and extract it on your Volumio device.
   • It contains a script called wifi-info.sh.

2. Run the script with root permissions:

   sudo bash wifi-info.sh
   

3. View the output:
   The script writes detailed information to:

   /tmp/wifi-info.log
   

4. What to attach or paste:
   Please upload or paste the full contents of:

   /tmp/wifi-info.log
   

   This will help us identify:

   • Your WiFi interface type (USB, PCI, SDIO)
   • Vendor and device ID (VID:PID)
   • Active kernel module (e.g. brcmfmac, rtl8821ce)
   • Whether the driver is already supported or needs an out-of-tree module
   • Supported bands, PHY capabilities, and firmware details

---

Reporting a Bug

How to Report Bugs

We need clear, complete, and specific information to help you. We do not have a crystal ball.

When reporting bugs, always include:

• Your device model, storage type (SD, SSD, etc.), and Volumio version
• A log link from your device (see: How to send a log link for a bug report? )
• A clear explanation of the issue: what happened, what you expected, and how to reproduce it

If your report involves hardware, include:

• Full identification of the device:

  • Datasheet, product page, or supplier/manufacturer link
  • Photos of the hardware (top and bottom), clearly showing PCB silkscreen markings, version numbers, and labels
  • Output of lsusb, lspci, or relevant dmesg logs

• What is connected to what, and how (USB hub, GPIO pins, power source, etc.)

---

Requesting Support for New Hardware

If you’re requesting support for new hardware (e.g. Wi-Fi dongles, DACs, displays), please use the official format:

HARDWARE SUPPORT REQUEST

We require:

• A link to the GitHub repository (if drivers or code are needed)
• Output of lsusb or other identifier commands
• A datasheet or product page
• A clear use case (what it is, what it’s for, and why it’s needed in Volumio)

Simply stating the chipset name (e.g. “MTK7921AU”) is not sufficient. Without complete details, your request will be skipped.

---

Problems with Plugins

To keep the Bookworm Public Beta organized, please report all plugin-related issues, feedback, or migration status updates in this post:

Public Beta Test: Audio Without Compromise - Plugin Compatibility for Volumio on Bookworm

This helps us separate plugin concerns from core system functions and ensures your input reaches the right maintainers.

Kind Regards,
[/quote]

[tweed77]

@nerd

Thank you for sharing the screenshots and log fragments, but we really cannot move forward without a full system log taken right after reproducing the issue. Please follow this guide to generate and share the log link:
https://help.volumio.com/help/how-to-send-a-log-link-for-a-bug-report

Without that complete log, anything else would just be guesswork. If other community members have better crystal balls than I do, they are of course welcome to jump in - but for a technical diagnosis we need the hard evidence from a proper log.

Kind Regards,

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

Hey @tweed77, Thank you for the screenshots and the extracted log snippets. This clarifies the situation. On Volumio 3.832 the Fritzbox server appears under Media Servers, and browsing continues correctly down to the USB contents. The log shows repeated handleBrowseUri calls with valid responses. On Volumio 4.025, selecting Media Servers still calls handleBrowseUri, but the result is empty. The Fritzbox server is not listed at all. That means the problem is not with your Fritzbox or SMB cred…

Full log:
Play 80s - 80s Radio and 4 click Media Servers:

http://logs.volumio.org/volumio/S3e9M3Y.html

[nerd]

Hey @tweed77,

Thank you for the full log link. Here is what the evidence shows.

• Platform and network are healthy on Volumio 4.025 Bookworm. Version and build are correct, and the box has a valid IPv4 on eth0: 192.168.178.22.

• The UPnP renderer daemon is running and listening on its standard HTTP/OH ports (upmpdcli on 49149 and 49152). It is also talking to the Volumio backend on localhost, so the control stack itself is up.

• Each time you clicked Media Servers, the UI called the upnp_browser plugin, but no devices were enumerated and no follow-up browse or device lines appear. This repeats across multiple clicks and timestamps, always ending right after “handleBrowseUri” with “Preload queue cleared”. That is the crux of the issue.

• Separately, there were background SMB scans for network shares that failed against the FritzBox host. That is unrelated to DLNA browsing, but it does confirm that unauthenticated SMB to fritz.box did not succeed on this system.

Putting these together:

• The renderer and network are fine, but the UPnP browser is not seeing any SSDP responses or is not issuing M-SEARCH at all. That is why Media Servers shows empty. The log has no device discovery output after the browser calls, which strongly points to discovery not firing or replies not being received on 4.025.

• The SMB failure reinforces that guest or dialect negotiation toward fritz.box is not working under 4.x, but again, your Media Servers path uses DLNA/UPnP, not SMB.

What I still need to fully close this:

• A quick capture that proves whether SSDP packets are flowing during a Media Servers click. Please run these two, then click Media Servers once, wait 10 seconds, and grab a fresh log link.

  sudo ss -uanp | grep 1900 - to show any UDP 1900 sockets bound by the browser process.

Right now, based on the log, the failure is squarely in UPnP discovery on 4.025: calls are made, but no devices are surfaced, while the renderer and network stack are otherwise OK.

Kind Regards,

[tweed77]

@nerd

sudo ss -uanp | grep 1900

volumio@rotel:~$ sudo ss -uanp | grep 1900
UNCONN 0 0 0.0.0.0:1900 0.0.0.0:* users:((“upmpdcli”,pid=1764,fd=5))

http://logs.volumio.org/volumio/GWtniub.html

http://logs.volumio.org/volumio/mjx0IU3.html

http://logs.volumio.org/volumio/vKyEYpq.html

http://logs.volumio.org/volumio/d4fQkB4.html

[nerd]

Hey @tweed77,

Thank you for the detailed follow-up and logs so far. From what we see, Volumio 4.025 is sending the UPnP discovery calls but nothing comes back. To confirm whether your Fritzbox is actually replying on the network, we can send a manual SSDP probe and capture the responses.

Here is how to do it over SSH on the Pi running Volumio 4.025:

1. Install socat:

   sudo apt-get update
   sudo apt-get install socat
   

2. In one terminal, start listening and log replies:

   socat - UDP4-RECV:1900,ip-add-membership=239.255.255.250:0.0.0.0,so-reuseaddr > /home/volumio/ssdp-listen.log
   

   Leave this running.

3. In another terminal, send the discovery probe:

   echo -ne "M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nMAN:\"ssdp:discover\"\r\nMX:1\r\nST:upnp:rootdevice\r\n\r\n" | socat - UDP4-DATAGRAM:239.255.255.250:1900,so-broadcast
   

4. Stop the first command with Ctrl+C after a few seconds. Then show us the log file:

   cat /home/volumio/ssdp-listen.log
   

   or upload to your response.

If UPnP is working, that file should contain responses from your Fritzbox (look for FRITZ!Box and LOCATION: lines).

Please paste the content of that log here. That will tell us immediately if the Fritzbox is answering and whether the issue lies in the network or inside Volumio’s UPnP browser.

Kind Regards,

[rkorell]

@VictorDUA

could users please write which minimalist BT remote work OOB without having to reconnect

Dear @VictorDUA ,
I’m using successfullly a very minimalistic remote “control”.
This only have five buttons - but this is perfectly, what I need.

Warm regards,
Ralf

[nerd]

Hey @tweed77,

Good capture. Here is what it shows and what it does not show.

• I see many SSDP NOTIFY ssdp:alive messages, but every one is from your Volumio box itself.

• I do not see any replies or NOTIFY from a Fritzbox mediaserver:

  • No SERVER lines containing FRITZ!Box
  • No LOCATION pointing to the Fritzbox IP
  • No 200 OK replies to the M-SEARCH

Conclusion so far:

• UPnP multicast receive and send on the Pi work, but the Fritzbox mediaserver is not advertising or replying on IPv4 SSDP to this host. That explains why Browse → Media Servers in Volumio 4.x is empty.

Next two focused checks

A) Ask the Fritzbox to answer as a MediaServer and log it

• In one terminal:
  socat - UDP4-RECV:1900,ip-add-membership=239.255.255.250:0.0.0.0,so-reuseaddr > /home/volumio/ssdp-msrv.log
• In another terminal, send a MediaServer-specific probe:
  printf “M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nMAN:“ssdp:discover”\r\nMX:1\r\nST:urn:schemas-upnp-org:device:MediaServer:1\r\n\r\n” | socat - UDP4-DATAGRAM:239.255.255.250:1900,so-broadcast
• Stop the listener after 5 seconds and show:
  cat /home/volumio/ssdp-msrv.log

Expected if Fritz mediaserver is alive: lines with SERVER: FRITZ!Box and LOCATION: http:///…/desc.xml. If still nothing, the Fritz is not responding to your host on SSDP.

B) Fritzbox settings to verify

• FritzOS version.
• Home Network or USB/Storage page: Media Server enabled.
• If there is a setting for Home Network access vs Guest WLAN, ensure the Pi is on the main LAN, not guest.
• If there is an option to enable IPv4 UPnP AV announcement, keep it on. Some configs bias toward IPv6 only.
• If you use a managed switch, disable IGMP snooping temporarily to rule out multicast filtering.

What this means relative to your original report

• Volumio 3.832 saw the mediaserver, Volumio 4.025 does not. Your capture proves the Pi can send and receive multicast, but the Fritzbox is not visible via SSDP on this link. Either the mediaserver is not advertising, it is isolated by network policy, or it is only announcing on IPv6. Any of these will make the Media Servers list empty, regardless of Volumio version.

If A) shows Fritz replies, we will focus on Volumio upnp_browser. If A) shows no Fritz replies, we need to address FritzOS or network multicast first.

Kind Regards,

[tweed77]

I send log to you inbox.

The Fritzbox is the main router. Fritzbox 5590 Fiber - FritzOS 8.02
Home Network or USB/Storage page: Media Server enabled - yes
A Raspberry Pi 5 with Volumio 4.025 is connected directly to this router via LAN.
A Raspberry Pi 4 with Volumio 3.832 is also connected to the Fritzbox router via LAN.

[VictorDUA]

@rkorell

very minimalistic

It’s not quite a standard shape and a bit pricey for such a controversial shape, but it’s worth considering. Thank you.

[jajao555]

I updated to 4.025 yesterday and had no issues with the OTA update.

I have a Rasberry Pi 5 with a HiFi Berry DAC

Tested web radio and NFS share both worked fine. I do have a randomly reoccurring issue playing a playlist though. I have posted before about an issue where a playlist I created using the NFS share as a source will randomly stop outputting sound when it starts a new song. If I refresh the page I’ll see the time still increment and even when a new song starts there will still be no sound. If I hit play again or skip the sound will start working again.

I just had it happen again and was able to catch it and create a log on 4.025 so its still an issue.
https://logs.volumio.org/volumio/kfRFVes.html
It happened between playing “Alice in Chains - Dirt - 00 - Would” at 09:01 and then going to “Chicago - Chicago Transit Authority - 06 - Poem” then I noticed the music stop. Poem had no sound but I saw the time increment when refreshing the page. Then hit play and music started but it starts from the beginning of the song as expected.

I mostly use Youtube Music and Bandcamp plugins both of those have not worked previously since going to bookworm no change there. I have posted in those threads already they still have same issues.

[nerd]

Hey @tweed77,

Thank you again for all the logs so far. At this point we need to check if the Fritzbox Media Server is actually exposing its UPnP HTTP service on the LAN and whether both Volumio versions can reach it directly. This avoids relying on SSDP discovery and tells us if the port is blocked or if the service is missing.

Please run these checks on both systems (Volumio 3.832 and Volumio 4.025) and compare the results:

1. Replace <fritzbox-ip> with your router’s LAN IP (usually 192.168.178.1).

2. From the Pi:

   telnet <fritzbox-ip> 49152
   

• If it connects and shows Connected, the port is open.
• If it fails, the Media Server service is not reachable on that port.

3. Then try fetching the device description:

   curl http://<fritzbox-ip>:49152/description.xml
   

   or, depending on Fritzbox firmware:

   curl http://<fritzbox-ip>:49152/upnp/desc.xml
   

• A working Media Server will return XML starting with <root xmlns="urn:schemas-upnp-org:device-1-0">.
• If you get Connection refused or 404 Not Found, then either the service is not running or it is on another port.

Important: some FritzOS versions may use a different port than 49152 for UPnP. If the tests above fail, please scan which ports are open by running (install nmap first if needed):

nmap -p 49000-50000 <fritzbox-ip>

This will show if the Media Server is listening on a different port in that range.

By comparing the results from 3.832 and 4.025 we can see whether the service is equally reachable from both, or if the Fritzbox is only exposing it in a way that Volumio 3.832 happened to pick up.

Kind Regards,

[rkorell]

I found pricing acceptable and I love the form factor.
I’ve even considered to glue it below the monitor (but haven’t done) …

I’ve put it in the drawer and use it “sometimes” - I’ve connected rotary switches as well - this is way faster

At least it connects without any problem (I’ve tried several others without success, including an old Apple-TV and Amazon Fire remote and some other bigger ones…).

It re-connects as well without any problem (with some lag for sure, but this is OK, one or two seconds after pressing a remote button, this piece re-connects and works,
Regards,
Ralf

[nerd]

Hey @tweed77,

Thanks for the additional testing and the screenshot. It shows clearly what is happening:

• On both 3.832 and 4.025 the connection to port 49152 fails - the Fritzbox is not listening there.
• An nmap scan confirms that the Fritzbox exposes its UPnP/MediaServer service on different ports: 49000, 49200 and 49443.
• This means the Fritzbox is advertising its mediaserver correctly, but Volumio 4.025 is not following through to the right port after discovery, while 3.832 apparently did.

To confirm which of these ports the mediaserver is actually serving its description from, please run on both 3.832 and 4.025:

curl http://<fritzbox_ip>:49000/description.xml
curl http://<fritzbox_ip>:49200/description.xml
curl http://<fritzbox_ip>:49443/description.xml

Replace <fritzbox_ip> with the IP of your Fritzbox router.
At least one of these should return an XML document starting with <root> and <device>.

With this we will know if the Fritzbox side is fully functional, and can narrow the issue down to not parsing the SSDP advertisement correctly.

Kind Regards,

[Nathan_Centofanti]

Running Volumio for Raspberry Pi (3B+). Audio across a cheap plug-in USB speaker.

Updated via command line to 4.025 with no problem yesterday.

This morning YouTube Music playback borked (probably a plugin issue, not too worried) but also Radio playback is now messed up. It will play a stream for about 30 seconds, meanwhile I’ll get the spinning dots icon on the screen and htop shows higher than average load on the machine. Once the spinning dots disappear the load goes back to average, the audio stops and Volumio show the following notification: “Player Successfully restarted”.

Log file: http://logs.volumio.org/volumio/9dYD83X.html

[VictorDUA]

@rkorell

love the form factor

I’m (for now) hoping to find a more classic look RC, but rescanning my every hour (plus at startup) gets annoying pretty quickly. We’ll see. Thanx.