I haven’t done the cold start and provoke failure yet, but I can answer your baseline questions.
After a restart;
playback of files from the USB drive works
web radio works
the unit I’m getting the logs from was a fresh install of 4.071 I think
(if not it was the previous V4 release
the trigger for the problem is changing which web radio station I’m listening to a few times. Maybe start with Bagel Radio, change to SOMA, then change to BBC 6, then back to Bagel.
It will then show the controls, but not respond to the radio selection. If I go to the Artists view to play music from the USB drive, it will take a long time with a green progress bar, then show a blank page.
From there, I have to restart.
It seems like swapping between web radio stations always causes this issue.
Assuming SQ means Sound Quality rather than square meters.
Looking at the official changelog, the only change between 4.072 and 4.073 is Node.js version pinning with a static package fallback. This is a backend dependency management fix - it does not touch MPD, ALSA, audio drivers, buffering, resampling, or any component in the audio signal path. From a technical standpoint, both versions should produce bit-identical audio output given identical playback settings.
To answer your direct question: No, there is no security reason preventing you from staying on 4.072. The 4.073 release contains no security patches. It is purely a stability fix for package management. You are not exposing yourself to any known vulnerability by remaining on 4.072.
That said, if you genuinely perceive a difference, I would be curious to know your setup details - hardware platform, DAC, output configuration, and playback settings. Without controlled blind A/B testing with matched levels, perceived differences between versions with identical audio paths are difficult to attribute to the software itself. But if something did change in your configuration during the update process (playback options, resampling settings, buffer size), that could explain it.
If you want to stay on 4.072 for now, that is a perfectly valid choice. You can disable automatic updates and remain there until you are satisfied that a future release addresses your concerns.
Thanks for the detailed reproduction and log - this captures the failure clearly.
What the log shows:
MPD hit its connection limit:
2025-12-07T06:44:52 client: Max connections reached
2025-12-07T06:44:55 client: Max connections reached
The backend opens connections to MPD but they are not being released properly when switching stations. Once the limit (20) is reached, all commands fail.
This is a localhost issue - not network related. Your WiFi signal is excellent (-41 dBm) and all remote endpoints test OK.
Why this may affect your setup specifically:
Your Pi 3B+ shows high CPU load from wireless.js (74%) and albumart processing. Under CPU pressure, connection cleanup may be delayed, causing faster accumulation than release.
To isolate the trigger:
Can you test with ethernet connected and WiFi disabled in Volumio settings? This would eliminate wireless.js load entirely.
After cold boot and 5 minute settle, try ONLY switching webradio stations - do not browse or play from USB first. Does the problem still occur?
How many station switches does it typically take before failure? Roughly 3-4, or more like 10-15?
This will help determine if CPU contention is the trigger or if the connection leak happens regardless of system load.
OK, this is a bit weird;
cold start, wait 5 mins, played a heap of web radio stations in a row, maybe 15-30 secs each. This would have usually resulted in the problem occurring, this time it didn’t. This was with just a wi-fi connection (not Ethernet).
3RRR
Bagel Radio
DKFM Classic
NME 1
SOMA FM Underground 80s
SOMA FM Indie Pop Rocks
Delta Radio Alternative
Delta Radio Indie
3PBS
3RRR
Andys 80s Rare 80s
Bagel Radio
and about three more quicker swaps with no failure.
I updated to V 4.073 after the above testing, that triggered a restart.
Tested again and played a flac tune from the USB drive for around 30 seconds, then swapped between web radio stations again, after maybe 6 swaps the failure occurred.
Now no Artist list, no web radio, etc.
Will restest with Ethernet in place of wi-fi.
I’ve ordered a R Pi 5B and a new case, it seems like V4 exceeds the R Pi 3’s performance.
Hmmmm, not the expected results on Ethernet.
Cold start with Ethernet cable in
Ping volumio, returns: Reply from 192.168.20.151: bytes=32 time=6ms TTL=64
(reserved IP address for WLAN is 192.168.20.76), so we know it’s on Ethernet
Swapped through web radio stations, 10-30 secs each
After about 8 swaps it failed to play any more web radio stations
Artist page blank again
Excellent systematic testing. The ethernet result is valuable - it demonstrates the problem is not WiFi-specific.
Test summary
Test 1 (WiFi, 4.072): Success - many station switches without failure Test 2 (WiFi + USB first, 4.073): Failure after approximately 6 swaps Test 3 (Ethernet, 4.073): Failure after approximately 8 swaps
Reproducibility status
I have attempted to reproduce this on my test systems spanning Pi Zero 2W through CM5 - the entire current lineup - without success. Your report is currently the only instance of this behavior.
After MPD restart, netstat shows the backend process (PID 1105) has no established connections to MPD port 6600. Compare to the successful WiFi test (PnfuFZ9) where backend maintained active MPD connections throughout.
Backend does not properly re-establish connection after restart
Playback and library functions fail
This remains unverified theory. The fact that I cannot reproduce it on other Pi models suggests either:
Something specific to Pi 3B+ timing or resource constraints
Something specific to your hardware combination (Allo Boss DAC, USB drive, SD card)
An intermittent condition that requires particular circumstances to trigger
Next steps
I am interrogating a Pi 3 in isolated testing to match your hardware class. Your continued testing is valuable - if you can identify any pattern that reliably triggers the failure, that would significantly help narrow down the cause.
A fresh SD card install on your current Pi 3B+ (without restoring settings) would also help determine whether this is tied to accumulated state versus base system behavior.
Hi, I downloaded the new version of Volume 4.073, but I still can’t connect to my Raspberry Pi 4 4GB Wi-Fi. I was hoping this new release would solve the problem. I can still only connect to LAN.
Last night, I formatted a micro SD card, and imaged it with V 4.073, booted, did the basic configuration, then left it overnight to build the music database.
This morning, I added the web radio stations to My Web Radios (that may be a point of difference to your test setup).
Then I shut it down and did a cold start, and waited five minutes.
I went straight to web radio and played;
3PBS, 3RRR, Andy’s 80s (error as it’s offline), Bagel Radio, BBC 6 Music (error as they keep changing the stream URL), Delta Radio - Alternative, Delta Radio - Indie, DKFM Classic, DKFM Edge, New Wave Radio, NME 1, NME 1 (forgot what I was up to), NME 2, then it failed and would not respond to more web radio selections.
When I use my Pi4 4GB with HifiBerry DAC and 7" touchscreen with version 4.073 it’s always a gamble to guess whether playback with the Autostart plugin will start correctly or not. More than 50% it doesn’t happen and I have to reboot the device 1 or 2 times. I often get the error ‘Failed to open "default detected output (sndio); Requested audio params cannot be satisfied’. After a few reboots, without changing anything, the device starts playing the song that is in the queue.
Below is the pointer to the log during an unsuccessful session with that error. http://logs.volumio.org/volumio/e2Y5pNh.html
May I have some indications as to how to overcome the inconvenience, as I have never detected this defect on version 3 ?
I also wasn’t able to use the WLAN, it asks me for the password then doesn’t connect to Volumio without reporting an error on the graphic interface.
Thank you for downloading Volumio (not volume) 4.073. As every other community member you have in fact studied this thread and of course you paid attention especially to these posts - correct?
Naturally, having read every single word of your post with the attention it deserves, two separate matters emerge here - one involving a community plugin, the other a networking situation that has already been addressed elsewhere.
The Autostart plugin is a community-maintained plugin. The appropriate place to report issues, request troubleshooting, or discuss problems with it is in the corresponding plugin thread within the Plugins category - not general Feedback thread. Plugin maintainers and users who actually run the plugin monitor those threads. Posting autostart issues in here means the people who can actually help may never see it.
As for WLAN not connecting after entering the password - this exact scenario has been discussed in this thread already. You will find relevant context and a solution reference at:
The post there describes WiFi connection failures on Pi4/Pi5 after power cycling, slow startup times, and the fix that resolved it. Reading that thread would be considerably more productive than waiting for someone to repeat the same information here.
Regarding the audio error itself - “Failed to open default detected output (sndio)” on intermittent basis suggests a race condition between DAC initialization and playback start. Without knowing your exact HifiBerry model, Autostart plugin version and delay settings, and full log analysis, speculation would be premature. That said - this investigation belongs in the plugin thread where the autostart maintainer can evaluate it properly.
For autostart, you need to adjust the delays. It looks like your script starts before Volumio has fully booted. Begin with a high value, such as 80000, and then gradually work your way down.
Thank you, I already tried to increase the delay, but not more than 35000. I will try with more time. The strange thing is that sometimes, in good cases, the sound starts before the end of the GUI completion