· If I pause a track then close the Roon client, when I reopen it, the track will start at the beginning as far as the audio goes, but the progress bar (both the waveform and the time) still act as if it’s playing in the middle.
Roon version is 2.67 Roon server is 2.67 Both are running on Arch Linux; the client is running inside Bottles.
Tell us about your home network
· Router: Unifi Dream Machine Switch: Unifi USW Lite 8 PoE AP with Ethernet: Unifi AP IW
I tried playing in another zone (one of my two Google Home/Nest speakers) but nothing started. I then tried using Roon on my phone to control my desktop, and saw the same behavior, even with a different track. So far it’s happened with “Evil” by Interpol and “White Wedding” by Billy Idol.
Thanks for the detailed report, the reproduction steps are clear.
A few questions to help us narrow down where the mismatch is coming from:
Does this happen with every track and album, or only some?
If you restart Roon Server itself (not just the client), does the position display correct itself, or does the mismatch persist?
If you control the same core from a different Roon remote while this is happening (a phone or tablet, for example), does that remote also show the wrong position, or only the Arch Linux client?
Does it still happen if you close the client mid-playback without pausing first?
One thing worth flagging: running the Roon client inside Bottles is not an environment we officially support, since it goes through a Windows compatibility layer rather than running natively on Linux. That doesn’t rule out a real issue on our end, but it does affect how we can investigate, so knowing whether this reproduces on a native client (phone, tablet, or a native Linux/Windows/Mac install) would help us figure out whether it’s Bottles-specific or something in Roon Server’s state handling.
Are Roon and Roon Server both still on 2.70 as of today?
Restarting the Roon server didn’t have any effect on the issue.
I’m new to Roon, so let me make sure I understand the 3rd question correctly. I think you mean “if you use e.g. your phone to control the audio on the Arch desktop”. If that’s a correct understanding, then no, the remote doesn’t matter.
Surprisingly, closing the client did not stop the music! (Restarting the client did allow me to pause, luckily.)
I checked Roon ARC on my Android phone and it correctly resumed where it had left off.
The server is on 2.70; the client seems to be unable to check for an update.
One question from before didn’t quite get answered: does the mismatch still happen if you close the client mid-playback without pausing first, rather than pausing and then closing? That’s a different test from what you described, and it’ll tell us whether pausing first is part of what triggers this.
Could you please also check your Roon Remote’s exact version and build number under About, rather than relying on the in-app update checker, since that’s failing for you right now.
Next time this happens, could you please fully quit any Roon-related processes from a terminal (not just close the window) before reopening, rather than relaunching normally? Since closing the client didn’t stop the music but a full restart did let you pause, we want to confirm whether killing the process entirely is what clears it.
Last thing, could you please share the exact Linux details for the Arch machine: kernel version and any relevant system info (uname -a output works). Since the wrong position shows up the same way regardless of which remote is looking at that zone, this points at Roon Server’s zone state rather than the client rendering, so we’re passing this to QA to attempt a reproduction on a native Linux Roon Server and official client.
Thanks for bearing with the back and forth on this one.
I couldn’t do this test since the music kept playing. I’m now unable to start the Roon client in Bottles; I get a Windows error box saying “Can not find a suitable tmpPixelFormat.”
Here’s the output from uname -a: Linux ben-desktop 7.1.3-2-cachyos #1 SMP PREEMPT_DYNAMIC Wed, 08 Jul 2026 06:14:22 +0000 x86_64 GNU/Linux
Thanks for hanging in there while we tested this. Here’s where we landed:
We ran the exact scenario (pause a track, close the client, reopen) on Windows, Android, and Mac Roon Remotes, and couldn’t reproduce the mismatch on any of them. We also set up a native Arch Linux system on the same kernel and configuration as yours (CachyOS 7.1.3-2), connected directly to a Roon Server, no Bottles involved. Playback position tracked correctly there too.
That points to this being specific to running the Roon client through Bottles, rather than something in Roon Server’s zone state or Arch Linux itself. Bottles runs the client through a Windows compatibility layer, so we don’t have visibility into how it handles position updates there, and it isn’t an environment we can support or fix on our side.
Given the “tmpPixelFormat” error you’re now hitting on top of this, it sounds like the Bottles setup has become unstable on its own. Our suggestion at this point would be to check Bottles’ own troubleshooting channels for that error, since we don’t currently offer a native Linux Roon Remote as an alternative.
We’ll close this out unless you’re able to reproduce the position mismatch outside of Bottles. Let us know if that changes.
Apologies, that screenshot was misleading. We didn’t install anything on Arch without Bottles, that was a Windows client screenshot, not a Linux one. There’s no native Linux Roon Remote to install in the first place, so your Bottles setup was the right (and only) way to get a GUI on Arch.
What we actually confirmed: the pause-then-reopen mismatch doesn’t reproduce on Windows, Mac, or Android/iOS Roon Remotes, all officially supported clients. Bottles, Wine, and similar compatibility layers aren’t something we support or can investigate further, regardless of the underlying OS, so that’s as far as we can take it on our side.
Given the “tmpPixelFormat” error you’re now hitting too, that Bottles setup sounds like it’s become unstable independent of the original issue. Worth checking Bottles’ own troubleshooting channels for that one.
