Volumio 4 Feedback Thread

I must admin, I did not check every and single post from over 500+ returned from search. However every and single one I checked reported a problem as well as warning to be very cautious.

This leads me to a logical conclusion - a single exception does not invalidate a pattern. Still it is an exception worth noting.

Furthermore, every community user reporting an issue is required to provide the details as outlined here, no exceptions.

Kind Regards,

Maybe its enough to not use customization during preparing image. Nevermind.
If 3.874 will be available for downloading it won’t be need to use pi imager :slight_smile:
Kind regards

Hey @Kampf_Keks_3000,

It took me a moment to understand what is the time factor being reported. Checked this five times to be sure:

From your diagnostic output:

Server: delta_sec=66588 Client: delta_sec=66562

Converting seconds to hours:

Server: 66588 seconds ÷ 3600 seconds/hour = 18.496 hours = 18 hours 30 minutes

Client: 66562 seconds ÷ 3600 seconds/hour = 18.489 hours = 18 hours 29 minutes

What this means:

The delta_sec value is calculated as: (real_time) - (system_time)

  • Positive delta = system is behind real time
  • Negative delta = system is ahead of real time

Your systems are 18.5 hours behind real time.

Example timeline:

If you ran the diagnostic on Nov 18 at approximately 13:00 real time:

  • Real time: Nov 18, 13:00:00 UTC
  • Server shows: Nov 17, 18:30:00 UTC (18.5 hours behind)
  • Client shows: Nov 17, 18:31:00 UTC (18.5 hours behind)

The systems are nearly synchronized with each other (only 26 seconds apart), but both are 18.5 hours behind actual time.

When system times are wrong:

  • Server timestamps chunk: “Play this at 18:30:00”
  • Client receives chunk at its time: “18:30:26” (26 seconds ahead)
  • Client thinks: “This chunk is 26 seconds late, skip ahead!”
  • Result: gaps, stuttering, buffer chaos

Your 2000ms buffer setting is meaningless when the time offset is 26000ms (26 seconds).

Snapcast will continuously try to “catch up” or “slow down” based on the timestamp mismatch, causing the stuttering you’re experiencing.

This is not a minor drift - this is fundamental system time failure. Snapcast cannot function with this level of desynchronization. Manual sync with setdatetime-helper failed because something is blocking the watchdog from reaching external time sources.

Check network connectivity to time sources:

SSH to both devices and test:

curl -sI --max-time 3 https://time.is
curl -sI --max-time 3 https://cloudflare.com
curl -sI --max-time 3 https://google.com

If these commands fail or timeout, your FritzBox is blocking HTTPS access to external time sources, preventing the watchdog from syncing.

If curl commands work, manually set time:

sudo date -s "2025-11-19 19:30:00"

(Adjust the date/time string to current actual time when you run it)

Verify:

date

Do this on both server and client. Without a hardware RTC, Raspberry Pi relies entirely on network time sync on every boot.

After setting correct time:

  1. Reboot both devices
  2. Wait 5 minutes for time sync to stabilize
  3. Verify time is still correct on both
  4. Test multiroom
  5. Submit new logs if still stuttering

The 18.5-hour time offset is why multiroom cannot work. If network access to time sources is blocked by your FritzBox, you’ll need to configure your router to allow NTP/HTTPS time sync, or this problem will persist across reboots.

Kind Regards,

Hi @nerd
I’m not sure what I’m doing wrong. I wanted to try a fresh install using this method, but I don’t see the Install to disk option in Settings > System.

I’m on v4.071 on a Pi5. Here are screenshots of my System options.



Hey @SimonE,

Perhaps you did not boot from MicroSD (boot priorities). As such, install to disk whilst running from disk…
As a precaution - can you double check your Raspberry Pi revision code and share for inspection?

Kind Regards,

Hi @nerd ,
That’s it. I was not booting from SD. I see the option now.
My board is a c04170 (Pi 5B 4GB rev 1.0).
Many thanks!

Hi @nerd ,

you are my hero :slight_smile: :metal:

I just added port 443 in the FritzBox and restarted the Pi’s
Now i got a time delta of 0 !!!

volumio@volumio:~$ hdr=“$(curl -sI --max-time 3 https://time.is | sed -n ‘s/[1]ate:[[:space:]]*//p’)”
echo “hdr: $hdr”
echo “sys: $(date -u)”
echo “delta_sec=$(( $(date -u +%s) - $(date -ud “$hdr” +%s) ))”
hdr: Thu, 20 Nov 2025 18:41:37 GMT
sys: Thu Nov 20 18:41:37 UTC 2025
delta_sec=0
volumio@volumio:~$

After a few test everything seems to work smoothly… awesome.

Thank you so so much :slight_smile:


  1. Dd ↩︎

1 Like

Okay, booted up Qobuz 4.071. Now I don’t see Qobuz in the sources list at all, Qobuz on my computer doesn’t see Volumio, and when I go to plug-ins it tells me I have to login to My Volumio, but when I click the Login button it takes me to the account page where it shows that I’m already logged in and have been logged in the whole time (as it also showed when I started up). I tried logging out and logging back in again and everything was the same. I’m, um, not enthused with the update here.

I think your date/time is not synced yet. You can wait a couple of minutes or set it manually via a ssh command.
sudo /usr/bin/setdatetime-helper.sh --force --verbose

Please look here:

this piece:
Check network connectivity to time sources:

Looks like something is blocking your connection.

If it still fails, please provide info as requested here:

Some updates: I restarted Volumio. After it processed for a bit and told me it’d updated the configuration, I finally have access to plug-ins and see the option for Qobuz Connect in the Sources settings. Great! Even better, I’m now able to actually pause and unpause music! Super great! However, when I play music it sounds like when someone places a hand repeatedly over their mouth so that the sound comes in and out rapidly, just constantly stuttering all the sound. Which makes it unusable. Not so great! However, it seems I was able to solve this by turning off all the sources except for Qobuz Connect. And now it seems to be playing normally! It’s weird that it had all these hiccups along the way but now at least it’s working.

never had those „hickups“ but fine it is iworking for you now

Updated to 4.071 over OTA with no issues.

Raspberry 5
HiFiBerry DAC+ Pro
NFS share over Wifi

I use web radio, bandcamp, and NFS playlist mostly. No issues with any except and issue with the NFS playlist randomly will stop playing. Its been happening since I tested the alpha I’ve posted a few times about it. I had cleaned up files that had various errors and still no change. I just caught it happening again and figured I’d post another log.

It happened after this song:
Nov 20 18:47:19 volumio volumio[1275]: verbose: ControllerMpd::sendMpdCommand add “NAS/proxmox-share/Music/Hawkwind/Space Ritual/Hawkwind - Space Ritual - 00 - Time We Left This World Today(1).mp3”

Going into: Led Zeppelin - Presence - 04 - Nobody’s Fault But Mine. I see it come up on the player just no sound until I hit play again.

https://logs.volumio.org/volumio/AqQiva6.html

Hey @jajao555,

I’ve analyzed your log in detail. The pattern you’re observing is consistent with a state synchronization issue between MPD and Volumio’s playback state machine during track transitions over network shares.

What’s happening in your log:

At 18:53:06-18:53:07, during the transition from Hawkwind to Led Zeppelin:

  • Line 39279: Volumio prefetches Led Zeppelin track from NFS (normal behavior)
  • Line 39304: The add command takes 579ms to complete (network latency from NFS)
  • Lines 39319-39322: State machine reports “stop” status while currentStatus still shows “play” - they’re out of sync
  • Position jumps between track 932 and 1118 before settling on 1118 with stop status

The state machine loses synchronization during the transition window. When MPD announces state updates, Volumio’s internal state doesn’t match what MPD is reporting, causing playback to halt instead of continuing to the next track.

Why NFS matters:

The 579ms delay adding the Led Zeppelin track to MPD’s queue creates a wider timing window where this desynchronization can occur. Local storage would complete in under 10ms, giving less opportunity for the race condition to manifest.

Historical context:

This specific pattern has appeared intermittently across Volumio versions, typically triggered by network share latency during track transitions. The timing behavior changed between Node 14 (Volumio 3) and Node 20 (Volumio 4), which may have reintroduced susceptibility to this condition.

I’m escalating this to the development team with your log and the technical analysis. Since you’ve observed this consistently since alpha testing, your feedback is valuable for tracking down the root cause.

In the meantime, you can work around it by hitting play when it stops, but I understand that’s not a solution - just a temporary measure until this gets proper attention.

Thanks for the detailed report.

@volumio - statemachine.js syncState and playback timer logic

Kind Regards,

1 Like

Hi
I upgraded to version 4 and I can’t set the Kiosk mode anywhere…can someone help?

@kawusia31
Maybe try venturing beyond the comfort zone and actually provide some data, wild idea, I know.
On x86 it’s standard, but on rPi you’ll need to install the “Touch Display” plugin.

Thanks @nerd!

Let me know if there’s anything I can do with my NFS setup to test further. It is hosted on a VM with a HDD storing the music and over Wifi but the router and Pi are in the same room so not sure its a wifi signal issue.

I did have it originally setup as SMB but had read about NFS having better performance when I started having the issue and switched to NFS to see if it would help but still had the same issue.

I sporadically face a similar issue (but for me it’s with Tidal): It’s that Tidal sometimes is unavailable after the start, i.e. the tile for Tidal is missing and also Tidal does no show up as option in the list of sources. When I try to play a playlist with a track from Tidal, I get a message telling me that I first need to log in to my Volumio. But I am already logged in. Logging out and logging back in or reboot this usually solves the problem. However, this is not specific to Volumio 4; I have also experienced this with version 3. Also it’s not only that Tidal is missing, also other premium features, so I guess it has to do with that somehow the login fails (just my guessing).

Is there an issue with the Pi5, and Volumio 4 and 5g? I cant seem to connect to my 5g network but it connects to the lesser networks but then i cant be fully integrated?