Hi David
Torben
Thank you, Rick!
Current response from Linn for those who are interested (and who might help explain “IGMP join messages” to me…)
I got the same response from Linn:
A full reboot router/switch etc. did not solve the problem.
Torben
@Torben, do you understand what any of this means? Or whether we can expect a solution?
My query to Grok and Grok’s reply:
Can you please explain in layman terms what “IGMP join messages” are in the context of digital hifi company Linn in its explanation of a problem that one of its devices, the Linn Selekt DSM music streamer, in connecting with a Roon Nucleus digital music server?
“When the DS starts up it sends out IGMP join messages which indicates to the network to open the relevant multicast routes, as does Roon server.
This route will later expire unless it has been renewed by receipt of an IGMP query from the querier, which is some other device on the network
It appears that after Roon server updates, some of these messages are conflicting with the previously cached network setup
After much trial and error the engineer did a full network reset on 2 test networks used for Roon testing (both using macminis as Roon servers), but with different routers, and the problem was resolved and did not return.”
Here’s an explanation in layman’s terms:
IGMP Join Messages: Imagine you’re hosting a big party (the network) where people (devices) want to join different interest groups (multicast groups). When someone wants to join a group, they send out a message saying, “Hey, I want to join this group!” That’s what an IGMP (Internet Group Management Protocol) join message does. It tells the network, “Open up this conversation so I can listen in.”
- In the Linn Selekt DSM scenario: When the Linn streamer (DS) turns on, it sends these IGMP join messages to say, “I want to listen to the music stream from Roon Nucleus!” This action tells the network to make sure the path for this stream is open.
Expiration and Renewal: Like at a party where someone might leave if they’re not reminded the group is still active, the network path (or “route”) for the multicast group can close if it’s not used or confirmed. This renewal is done by something called an “IGMP query,” which checks if anyone still wants to be in that group.
- The Problem: After a Roon server update, it seems like some of these messages got mixed up or didn’t match with what was previously set up on the network, causing confusion (like if two party hosts were sending out conflicting invites).
Resolution: After trying various fixes, the engineer did what’s akin to shutting down the party and starting fresh. They reset the network completely on two test setups. This cleared out all the old, conflicting information, and when everything was set up again, the problem didn’t come back because the network now had a clean slate to work with.
In essence, IGMP join messages are about managing who gets to listen to what on a network, and in this case, there was a temporary mismatch after software updates that needed a network reset to fix.
And Google Gemini:
Imagine your Linn Selekt DSM (think of it as a fancy radio) wants to listen to music from your Roon Nucleus (think of it as a huge music library). They talk to each other through your home’s network (like roads connecting houses).
“IGMP join messages” are like the Linn Selekt DSM shouting, “Hey network! I want to listen to music from the Roon Nucleus!” It’s telling the network to create a special, direct “road” (a multicast route) between the music library and the player. The Roon Nucleus also shouts similar messages, saying “I have music to share!”.
This “road” isn’t permanent. It’s like a temporary permit. Someone (a “querier” - maybe your router) needs to periodically check if the Linn Selekt DSM is still listening. This check is like asking, “Are you still there? Do you still need this road?” This check is done by sending out “IGMP query” messages. If the Linn Selekt DSM is still listening, it responds, and the “road” stays open. If it doesn’t respond, the “road” closes.
The problem Linn was having was that sometimes, when the Roon Nucleus updated its software, it would send out new “Hey, I have music!” messages that clashed with the old “roads” that were already set up (the “previously cached network setup”). It’s like the road signs got mixed up, and the Linn Selekt DSM got confused about where to find the music.
By doing a full network reset, they basically cleared all the old “road” information and rebuilt the “roads” from scratch. This fixed the problem because everything was fresh and consistent again. It’s like wiping the slate clean and redrawing the map.
I got the same message from the Linn support, with additional info that Linn devices don’t send these IGMP join messages while in sleep, which does explain my case of endpoint disappearing over the night while in sleep. More on that later.
AFAIK Roon is using multicast and mDNS (IGMP) for endpoint discovery only.
See more here:
This post states that IGMP is not needed, however that it can affect the multicast traffic that is needed for discovery process. It also states that Roon is not using multicast for streaming but unicast direct to endpoint streaming. The mDNS is only used for endpoint discovery.
However, my understanding of mDSN is that it is actually using IP Multicast Groups, specifically this one:
224.0.0.251: mDNS for Device Discovery (also known as Bonjour)
For the IP multicast groups to function properly, we need the IGMP functioning properly on our switches/routers. Or we need to disable IGMP all together not to interfere. When IGMP is off, multicast messages should be flooded to all ethernet ports by the switch/router, which would give us no problems.
In my case, I need IGMP enabled on my router to control IPTV multicast streams, so I don’t have an option to disable it. Actually, I’m not even sure if IGMP is a problem in my situation, or we have a problem with mDNS.
On that note, Linn support says that the device is sending IGMP join messages, but that Roon has problems with cached entries. That would mean that Roon has a cache of endpoint devices (names and IP addresses) which it collected via mDNS discovery process. I’m not sure on the lifetime of these cached entries, but we can only presume that there’s a conflict with old and new entries when my Linn device boots up from sleep and starts sending join messages.
I would then absolutely recommend pinning an IP address for Linn device on your DHCP server (router). Weird thing happened on my last Linn firmware update, even though I had a static IP address for my Selekt in the DHCP, my Selekt DSM got a new IP address when updated with new firmware. I cannot be 100% sure that the new firmware made that, but it was very strange. Do double check your static IP assignments even if you’ve set them up before.
Also, I would recommend updating/shutdown of your Roon server and then shutdown of your network chain including any routers and switches. To hopefully clean IGMP group memberships and Roon mDNS cache.
From my last hard shutdown of the entire network chain and Selekt endpoint, I did not have any cases of Selekt endpoint disappearing. That was 3 days ago, fingers crossed it stays that way. 
Done that - no impact. Did not fix the problem!
Torben
Sorry to hear that Torben. Honestly, I’m keeping my fingers crossed that it will now work for me, but I’m not fully convinced myself that it will not repeat again.
From what I see on this thread and from what Linn support told me, the issue is widespread.
What we can conclude from that is that it is a Roon/Linn bug and not our network misconfiguration.
This is the stance I’m holding and as that will press the matter with Linn support.
Obviously, we cannot press Roon support as benjamin said:
We don’t have any immediate next steps to test, we’re hoping to gain more insight from Linn directly and while we don’t have any specific information to share yet, we’ll certainly keep you updated as we learn more.
Thank you for the patience in the meantime
I had another support thread open for Roon HiRes Tidal issues which was also immediately closed with a comment that I’m spamming the Roon support. This was presumed just because Linn Selekt was stated as an endpoint device even though it happens for other endpoints.
This shows that Linn is not a word that Roon support wants to hear or deal with. Given the amount I’m paying for Roon I find this unacceptable and will probably investigate other Roon alternatives.
One more observation: the dropout of Roon from the Linn occurs quite often when I move from the Roon Home page or a specific album page to the Roon Composers or Artists pages. I speculate that these pages may present more complex multicasting issues because they require the software to reorient the page to pull together data in a more complicated way than, for example, a particular Album page. I further speculate that my senate large library of digital files (as many as 70,000 tracks), may play a role. @Torben and @Jozo_Slejko (and anyone else who is interested), what do you think?
Hey @David_Bissinger , that is strange.
Like I said, my Selekt stays visible as long as I’m using it.
You have a much bigger problem and I’d say that this is not likely a networking issue. It looks like it’s a Roon issue. It would be interesting to see CPU/memory consumption of your Nucleus One. You have a 70K large library and Nucleus One supports up to 100K if I’m not mistaken?
For a test, could you try setting up a Roon server on a Windows PC? I hear the Win OS can handle the largest libraries. Just to rule out any Roon server issues.
Btw thanks for the link, just saw your earlier reply.
@Jozo_Slejko, I think that’s my next step. I have an old PC laptop that I could make a Roon server or even use my current one since I take it everywhere. I had heard from a friend about the Roon Nucleus not really being all that great. I didn’t see many complaints online but did not research it in much depth. I bought it because it seemed like a nifty package and discounted the warning. Linn’s help desk noted that they used Mac Minis. That may suggest an issue. And super high-end products like the Grimm MU1 have added to my concerns about the Nucleus. I see this with some sympathy to everyone involved in manufacturing these products because I recognize they are doing some amazing things. I do wish that there was more clarity about that, however.
Do you have a link handy to the best guide as to how to set up a PC as a Roon server? I suspect if I use Google Gemini, Grok, or ChatGPT that I will find an answer pretty quickly but if you have suggestions, I am all ears. Thanks for all your thoughts!!
The usual Windows OS installation for Roon and then manual or automated optimisations. There are also some paid optimisation tools like Audiophile Optimizer and Fidelizer. I’ve seen one post on Facebook where the guy was speaking about pros of running Roon on Windows. The point was that Roon on Windows would handle large libraries with so much more ease.
I’ve never used any of those as I never used Windows or Linux as Roon production server, only ROCK.
Given my recent issues with Roon and the general opinion that Audirvana offers better SQ, I’m now thinking on moving from Roon ROCK OS to Windows OS on my NUC for Roon. I could then install and run Audirvana or anything else in parallel to Roon Server to compare.
Today I installed Audirvana on a Linux VM and did a quick listening session sans any DSP. I’d need to do a few more session, but my initial feeling is that Audirvana has better SQ. And that’s running from a VMware ESX server which is far worse than NUC in terms of galvanic and other noise. Still need to compare the UI and other features.
I guess it’s experimentation time for both of us. 
Edit - removed assumptions around Roon running on old .NET
Completely wrong. First of all, Microsoft has an official .NET release for Linux, and C# and .NET isn’t more emulated on Linux than it is on Windows.
I’m not sure if the server even uses any of this or if it’s just the client apps. You can read a bit about their environment here:
Thanks for your comment.
Not sure what is that you’re referring to completely wrong?
Regarding .NET, Microsoft has .NET Core Framework which is platform agnostic. .NET Framework isn’t, it’s only supported on Windows.
Not sure I understand what you mean by C# emulated on Windows?
Btw, I work for Microsoft.
As for the details of Roon ROCK under the hood, I didn’t state this for a fact, but this post gives some insight into it:
Let’s exam Roon Rock OS – Windows emulator in Linux clothing | What’s Best Audio and Video Forum. The Best High End Audio Forum on the planet!
Feel free to correct my understanding of Roon ROCK.
What I quoted, this emulation claim.
Well, you referred to it without any substantiation and seemed to draw on it for support.
Sadly, this doesn’t mean much these days. I continually work with Microsoft developers.
It’s not, that’s my point. Neither is it on Linux.
It’s not my job really, maybe you should educate yourself before claiming stuff.
This post is 5 years old and many things changed. It’s also poor and superficial even then. It’s not an analysis and there is no insight, it’s just the most simple poke into the system, reading some file names, and jumping to conclusions.
He mentions Mono. First of all, Mono is a reimplementation of .NET, not an emulator, at least if used with care:
It is, nevertheless, certainly not ideal für performance compared to Microsoft’s .NET, which is why they switched to the .NET runtime for the Linux server, and later on Mac.
I have no insight into why there were Mono references in Roon OS in 2018, I’m sure there are reasons, but note this (my bolding):
Thank you for your comments and corrections.
And thanks for the compliment. I’m sure you’re better than everyone in Microsoft.
You could’ve given the information in a more mannered way, but I’ll accept anything.
I’m not, but this doesn’t change that it means little these days without knowing more.
Can’t see where my manners were lacking. You made a statement, I called it out as factually wrong. There was zero personal stuff in that post.
I agree that the article is nonsense, but more importantly, we haven’t used Mono in many years.
“.NET Framework” and “.NET Core” are both obsolete things.
Since 2020, all reasonable releases of this thing are an open source project called “.NET”.
.NET Framework died at 4.x over a decade ago. It’s still around, but only gets security updates. While it is included with Windows, it is recommended by Microsoft that no one use it,
.NET Core was the new thing and restarted the versioning at 1.0. It died with 3.1, when “.NET 5” was introduced in 2020.
Since then, there has been a unified project under this open source '.NET" branding: .NET 6, 7, 8, and recently, .NET 9. If anyone is using .NET in modern times, they are using this.