This comment caught my attention.
I can’t comment on 4.072 to 4.073, but going from the last version 3 to 4.073, there is a slight edginess to the mids/highs, maybe a small tilt ‘forward’ in the overall sound. This seems to be the same on a couple of radio stations and Qobuz (via a USB DAC). I realize this may be highly context/system specific 
Hey @pwstereo,
This is significant. Fresh install reproduction eliminates accumulated state and configuration drift as factors.
Log analysis confirms identical failure pattern:
Timeline from: k0hc0iU.html:
Netstat at failure:
tcp 0 0 127.0.0.1:59176 127.0.0.1:6600 CLOSE_WAIT 1451/upmpdcli
tcp 15 0 127.0.0.1:42338 127.0.0.1:6600 CLOSE_WAIT 1451/upmpdcli
tcp 0 0 127.0.0.1:38000 127.0.0.1:6600 ESTABLISHED 1451/upmpdcli
tcp 1 0 127.0.0.1:38002 127.0.0.1:6600 CLOSE_WAIT 1451/upmpdcli
Node backend (PID 1702) shows ZERO connections to MPD port 6600. This matches your ethernet test exactly - after MPD restart, the backend does not reconnect.
Secondary observation: MPD log shows “No such playlist” exception after nearly every successful playback. This may contribute to connection churn, though root cause remains the reconnection failure.
Pattern:
You mentioned adding stations to My Web Radios before testing. My tests used only the built-in radio directory. This could be relevant if custom stations trigger different code paths - though I suspect it is not the differentiator since the failure mechanism is backend reconnection, not stream handling.
Current status:
This meets the threshold for serious investigation. The evidence points to a backend issue with MPD connection management. Before suggesting a GitHub issue, I want to attempt reproduction on a Pi 3 to match your hardware class. Still dealing with priorities.
One request: after your next failure, before restarting, could you SSH in and run:
cat /proc/$(pgrep -f "node /volumio/index.js")/fd/* 2>/dev/null | head -100
This would show what file descriptors the backend process has open, which might reveal whether it is attempting connections that are stuck.
Kind Regards,
Hey @mogelsvs,
V3 to V4 is a major architectural jump - Debian Buster to Bookworm, kernel upgrade to 6.12.x, updated MPD version, ALSA library changes, potentially different default buffer and resampling settings. Unlike the 4.072 to 4.073 comparison, there is actual technical substance here that could theoretically produce different behavior.
However, without verified identical playback settings between your V3 and V4 installations, logs showing MPD configuration from both, and level-matched blind A/B comparisons, we cannot isolate variables. This is subjective audiophile territory which is difficult to address with technical evidence alone. Perceived differences without controlled testing cannot be reliably attributed to software changes versus expectation bias.
If you want to dig deeper, provide logs and playback settings screenshots from both versions and we can compare configurations for actual measurable differences.
Alternatively you can remain on v3 if this is your preference:
Kind Regards,
OK, I used the volumio account to login with Putty, created the issue by changing web radio stations, then ran the command. It produced no output in the Putty terminal session. Had to Ctrl-c to get the command prompt back, tried it a couple of times, same result.
Then ran a log upload in case the cat output is there (seems unlikely).
http://logs.volumio.org/volumio/ku1YnqK.html
Hi @nerd,
Thanks for taking time for the thoughtful reply!
My “OCD” would not do well with rolling back to V3 so the ears/imagination will have to adjust 
I am a lifetime subscriber and can’t imagine listening to V3 in year 2050 
Cheers, Soren