· I'd like to report a reproducible bug in the Roon app on macOS.
Setup: - RoonServer runs in a Debian LXC container on my own Proxmox server (self-hosted, not a NUC/ROCK). The container has 4 vCPUs (usage stays around 0.3-0.5%), 8GB RAM (about 43% used), and has been up for 15 days straight with no crashes or restarts. Resources are clearly not the bottleneck.
The bug: After listening to a few tracks in a row, the "Now Playing" information shown in the Roon app on macOS stops matching what is actually playing out loud. The display shows a different track/artist than what I'm actually hearing.
The clearest proof this is a pure display/UI desync, not an actual playback issue: if I seek to the beginning of the track that is (incorrectly) shown as playing, the transport actually seeks the position of the track that is REALLY playing - not the one displayed. So the underlying playback engine has the correct state; only the on-screen "Now Playing" label in the macOS app is wrong/stale.
Important data point: I have NOT been able to reproduce this on the Roon app on iOS, connected to the exact same RoonServer at the exact same time. Only the macOS client shows this desync. This strongly suggests the bug is in the macOS client itself, not in RoonServer, my network, or my container setup.
I believe this may be the same issue (or closely related to) a bug already reported by another user in the community: ref#L9DWSY ("Desync between iOS app display and actual playback with Roon server on Mac Mini"), which is currently marked "Ticket In." I wanted to add my report since my case narrows it down further - it points specifically at the macOS client rather than RoonServer or the network, since iOS stays correct against the same server.
Happy to send full diagnostics (Settings > About > Send Diagnostics) if that helps investigate.
Tell us about your home network
· There isn't vlan or any complex infrastructure and i am using wifi 6 Access Points without any issue
Hey @firat, welcome to the community, and thanks for the detailed report.
What you’re describing sounds like a stale macOS Remote display state rather than a playback engine problem, especially since seeking still follows the track that is actually playing and iOS stays in sync on the same Roon Server.
Could you please note the exact local time, date, and the track that was showing incorrectly. That gives us a clean window to compare against the server-side state. If you haven’t already, it would also help to know whether the macOS app is on the same WiFi network as the server or connecting through anything unusual.
For a related reference on playback-state display issues, see Signal Path.
Once you have a timestamp, post it here and we’ll enable diagnostics mode for your account and look at the matching diagnostics.
On the network question: the Mac and RoonServer are on the same local WiFi/LAN (both on the 192.168.10.0/24 subnet). RoonServer runs in a self-hosted Debian LXC container with a static LAN IP, and is discovered normally over the local network - nothing unusual in the connection path for this. I do have Tailscale installed on the server, but that’s used exclusively for Roon ARC (remote access when away from home); it’s not involved in this local listening session at all, so I don’t believe it’s a factor here.
Here’s a fresh occurrence with a timestamp, screenshot attached:
Date/time: September 5, 2026, around 18:55 local time (UTC+3, Istanbul)
What was actually playing: a remix track by Mor ve Ötesi
What the macOS app displayed: a different track
Extra detail that might help narrow this down: the progress bar/timeline on the (incorrectly) displayed track was visibly advancing much faster than normal playback speed - clearly not just a stale label, but a timeline that’s also running at the wrong rate.
One more thing I’d like to flag, for context on why this particular bug is so disruptive in practice: this is basically how I discover music day to day - I have it playing in the background, and when something catches my ear I want to check what it is and save/like it. Right now I can’t trust what’s on screen to do that, which defeats the purpose entirely. This is made worse by a few gaps in the macOS app that would otherwise make it easier to work around in the meantime - there’s no compact/mini player mode, no system notification when a track changes, and no desktop widget showing what’s currently playing. Any one of these would at least let me sanity-check against the audio without needing the full window open and trusting a display that’s currently unreliable.
Let me know if you need anything else to match this against the server-side diagnostics.
