Roon "loses control" of Linn Selekt DSM when forwarding tracks

Roon Core Machine

Synology RS1221+ (Rack Mount)
AMD Ryzen V1500B / 2.2 GHz

Roon runs in a docker container with no CPU throttling. Docker image is the latest steefdebrujn/docker-roonserver.

Current Roon server version is today’s production build (1148) but this has been happening for a while. Today’s build did not introduce or fix the issue.

Networking Gear & Setup Details

UniFi gear end to end. All relevant devices are wired. Path WAN to the Selekt devices (there are 2, both exhibit the issue) is:

Netgear Cable Modem (gigabit cable) →
UniFi UDM Pro →
UniFi USW-24-PoE →
Linn Selekt DSM

The UAP-IW-HD is an in-wall access point and 4-port switch. The Linn is connected to a switch port. Path is wired end to end.

All devices are on the subnet and Roon’s “Subnet for Linn Streaming” setting is correctly set to

Connected Audio Devices

7 Sonos zones all enabled for Sonos Streaming (one wired, the rest on SonosNet)
2 KEF zones (one wired, one wireless)
2 Linn Selekt DMS - one with Katalyst, one without (both wired)

Linn Selekt DSMs are both on the latest firmware which is Dakar 96 Build 470 (4.96.470) from 19 Oct 2022.

Number of Tracks in Library

7078 local tracks

Description of Issue

I have a very reproducible issue in which fast forwarding through tracks when playing to a Linn Selekt DSM causes playback to stop and a message to be displayed saying “Roon lost control of the Audio device.” I can reproduce it by playing music (playlist, radio, album, whatever) and hitting the forward button in the Roon app several times quickly. In normal use, it seems possible for it to happen when just forwarding two or more times.

The release notes for today’s release (1148) say “Resolved an issue where RoonServer could crash when certain Linn products are in use”. That got me wondering if that fix addressed the issue I see. I’ve now verified that it does not.

Here’s an image of the iOS app displaying the problem. This is an iPhone 14 Pro running today’s release (1148) of the iOS app.

Thank you for your help!

Yep - I can vouch for this using a Klimax DS. I have no idea how long this issue has existed as I’m not in the habit of skipping tracks quickly but I can reproduce it from both iPhone 13 Pro and iPad Pro.


EDIT: While using the iPad as Remote I’ve just tried changing endpoint from the DS to the iPad itself, and that copes fine, so it seems to be due to the way Roon and the DS converse.

1 Like

Thanks for confirming!

This is helpful. I should have noted in my report that the issue doesn’t occur with Sonos or KEF endpoints, either.

1 Like

@Michael_Curtis - I have a question for you about your firmware state.

I use the iOS “Linn” app to monitor and install firmware updates to my Selekts. That app shows me Davaar updates and I’ve been on Davaar 96 Build 470 since its release.

Davaar updates are detailed here : ReleaseNotes - LinnDocs

Something I read elsewhere got me wondering if I should poke around in the Konfig app, which I don’t have installed or use. Konfig showed me “Exakt” updates were available. I did not know that my devices could take Exakt updates and I guess I falsely assumed that all updates were available in the Linn app.

I installed the Exakt updates.

Exakt updates are here : Exakt Release Notes - LinnDocs

After installing the Exakt updates, the problem seems quite a bit harder to reproduce. I can still get it to happen but it takes many attempts where, previously, it was fairly easy to get it to happen.

Do you happen to know if your Klimax’s firmware is up to date across both firmware modules? I believe Konfig is the only way to tell but I might be misunderstanding something. If you haven’t updated to the latest Exakt release, and it’s available for you, mind giving it a shot?

Thank you!

For as long as I’ve been using DSs (since 2008?) I’ve used Konfig. Even now I use it in preference to the iOS Linn app when checking for updates.
As I don’t have a full Exakt system (the only Exakt connection I use is the input from the Urika 2) I only tend to see updates for Urika on top of the regular firmware ones. There are no updates of any kind available.
This is my main screen (firmware level may be different to yours as I had the Organik update some months back:-


Thanks, Michael.

You clearly understand your equipment far better than I do mine :slight_smile:

I’m not so sure! :grin:

1 Like

I have also seen this intermittently with a Selekt DSM, across multiple versions over at least the last half year or so. The core is on a Mac Mini without significant other CPU load, and LAN is wired without performance issues.

The problem is trivially repeatable using my current versions:

  • Roon v2.0 (build 1148) on MacOS, iPhone and iPad
  • Davaar Beta 4.97.473, and also the Exakt update mentioned above

I cannot recover from this state from within the Roon context, but have to resort to the Linn app.

Sorry to hear this.

I spent days going back and forth with Linn support on this issue. I provided many logs. They gave me many assignments and pointed fingers in many directions (Roon, my specific core, other software running on my network, my network, UPnP, a supposed firewall that I don’t have, my network again). I did a lot on my end including network / UPnP analysis and temporarily standing up a new core.

They weren’t really serious about debugging the issue. In the end, they said this:

The engineers will continue to check the code for the DSM and try to replicate the issue using Linn hardware and software, as if there is an issue with the DSM itself, it should be reproduceable using only the Linn software.

That is a direct quote from a support mail. Their point was “If it doesn’t happen when you use the Linn or Kazoo app, then it’s not a bug.”

They also said that Roon is sending too many UPnP requests - there may be some validity to this (I saw more than expected M-Search requests when doing analysis) but the volume wasn’t as extreme as they claimed and any UPnP element listening and responding to M-Search requests should obviously be resilient to that and not go into an unresponsive state.

There was nothing left for me to do. Reaching out to them for help wasn’t a great experience. Sort of put me off the brand.

If you do reach out to them, please let us know!

Hey @gTunes,

Thanks for your patience here! The team just took a closer look at your issue, and we’ve just now enabled a debug flag for your account specifically targeted to your Linn. With this, if you could please reproduce the issue, grab the date and time of the issue, and share it here, this should provide a more detailed breakdown into what’s going wrong.

I’ll be on standby for your reply :+1:

Hi, @benjamin.

Thanks for looking at this!

I was just now able to reproduce the issue.

8:20 PM GMT. 12:20 PM PST.

Reproduced by advancing tracks repeatedly. After a number of these, the Roon app (on iOS) shows “Roon lost control of the Audio Device” or something like that.

Hope that helps!

1 Like

@Benjamin - I’ve been waiting for today’s release to cut over from my current core to a ROCK. Do you need me to postpone that until you’ve done additional debugging or do you have what you need?


Hey @gTunes,

We should be good to go with the logging we need. You are fine to make the swap!

1 Like

Hey @gTunes,

Thanks for your continued patience here! After reviewing your logs, it’s still tough to pin down specifically what might be causing this hiccup of losing control on your Linn.

I am seeing a reoccurring connection issue in regards to your RAATserver, so I’d like to refresh this database to see if that may be the culprit. Steps to follow below:

  • Create a Backup of your current Roon database
  • Exit out of Roon
  • Navigate to your Roon’s Database Location
  • Find the folder that says “Roon” and “RAATServer”
  • Rename “Roon” to “Roon_old” and “RAATServer” to “RAATServer_old”
  • Reinstall Roon from our Downloads Page

I’ll be on standby for your reply :+1:

@Benjamin - I’m not sure this is a Roon issue vs. a Linn issue. Sometimes, when the issue occurs, it’s just sort of a hiccup in Roon and after some time elapses, Roon can control it again. Sometimes I need to go into one of the Linn apps and switch the inputs around to kick it to kick out of whatever issue it’s having. Sometimes the Linn goes completely and permanently out to lunch - the control knob goes red and nothing short of a power cycle can fix it.

I think we may be chasing a DSM (Linn) issue that Linn is uninterested in hunting down - at least not interested when it’s me contacting them.

In my opinion, there’s no scenario in which Roon should be able to put DMS into the sorts of states that it gets into. I suppose maybe a seriously corrupt bitstream but this feels more like control commands causing the Linn to get into a weird state.

I did switch over to a ROCK. The core that I reproduced the issue on was called roonCore. My current core is called roonROCK. I’m not sure how to do what you’re asking on my ROCK core and I’m also wondering if perhaps the issue you’re seeing (whatever it was) was occurring on my previous core and trying to fix it on the new one doesn’t make sense.

Can you advise? I can also try to reproduce again on the new core if you’d like.

Hey @gTunes,

Thanks for your patience here. Yes please reproduce the issue on your new core and share a timestamp of when the issue occurs.

I’ll be on standby for your reply :+1:

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.