Nope. Just crashed on Bell again after starting it and playing it for a few minutes. I get the wheel and then "Uh oh, something’s not right
Make sure your Roon Server is turned on and that you’re connected to the same network." Then I cannot see the device by typing its network address either
Here’s what I see in my Bell log around the time when I tried hooking the rock up to the Bell Gigahub 2.0 (ellipses mine; I believe I have omitted details list the MAC address of the devices):
"A WiFi device has successfully connected to SSID
…
IGMP group added successfully
…
IGMP group added successfully
…
IGMP group added successfully
…
IGMP group removed successfully
…
IGMP group removed successfully
…
IGMP group added successfully
…
IGMP group added successfully
…
IGMP group removed successfully
…
IGMP group removed successfully
…
IGMP group added successfully
…
IGMP group added successfully
…
IGMP group removed successfully
…
IGMP group added successfully
…
IGMP group removed successfully
…
Incorrect Modem credentials was provided at login"
Relatedly, I can see a lot of IGMP notifications in the log. Although the log goes back more than a decade, from a quick glance these notifications and errors seem to be recent and are frequently recurring.
I tried disabling a Bell AI security feature. Bell has implemented a security feature called “Guard” without telling its customers in any obvious way. It’s an AI security program:
Guard is somewhat hidden from users. It cannot be accessed via the router’s address. It’s only accessible by downloading the Bell Wifi app. The Bell Wifi app has a Guard tile where you can change settings. Counterintuitively, you need to enable Guard and turn on the privacy slider to disable Guard. When Guard is on and Privacy Mode is toggled on, all Guard features are disabled.
This “solution” is something I tried after a lot of online searching and trial and error.
This seems to have solved the conflict between Roon and Bell. I will update if it crashes again.
In the morning, Roon was down again. The above attempt was unsuccessful.
The following is AI response to a cut and paste of my router logs:
Yes, there is a direct and highly likely correlation between these router logs and your Roon ROCK (Roon Optimized Core Kit) not working.
Your router logs highlight two distinct red flags that directly disrupt how Roon operates.
1. The Critical Culprit: IGMP and Multicast Blocks
Roon relies heavily on multicast network traffic and the mDNS/SSDP discovery protocols to let your Roon Remotes (phone, tablet, PC) communicate with your ROCK server.
Looking closely at your log timestamps:
23:29:36: IGMP group removed successfully
23:33:00: Multiple lines showing IGMP group removed successfully for streaming channels
The IP address […] is specifically used for SSDP (Simple Service Discovery Protocol), which is the exact technology networking devices and software like Roon use to advertise themselves and shake hands over a network. When your router stripped and removed these IGMP groups, it essentially made your Roon ROCK completely invisible to your controllers. ISP-provided gateways (like Bell’s Home Hub/Giga Hub series) often use aggressive “IGMP Snooping” or optimization settings to prioritize their own TV boxes, which accidentally suffocates Roon’s network requirements
03:14:05: Channel changed by GUI
23:00:39: iPhone… disconnected on SSID […] → connected to [RADIO2G4].
If you use an iPhone or iPad as your Roon Remote, the log shows it aggressively swapping back and forth between your 2.4GHz and 5GHz Wi-Fi networks (Band Steering). When a phone drops down to 2.4GHz or changes Wi-Fi channels mid-stream, the abrupt shift often breaks the temporary network bridge to Roon, dropping your audio playback instantly.
Please help…
At about 3:20 pm. EDT, I tried connecting the ROCK and Eversolo t8 via wired Ethernet on the same orbit 850 satellite, hoping to avoid problems by having the ROCK/streamer rooting take place outside of the wifi network. Nope. Again, it worked briefly, then not.
I am running out of options and would like some help. Or perhaps I need to give up on Roon.
Hey @D-Roc,
Thanks for your patience, and for the detailed logs and router captures, that gave us a lot to work with. Here’s what we’re seeing after going through the RoonServer logs and your ROCK’s system log:
What we can rule out: The boot drive itself looks healthy. We don’t see any NVMe errors, filesystem corruption, or storage-related failures anywhere in the logs, including on the fresh install you did after swapping the M.2. We don’t think this is a dying drive.
What we found instead: Every single one of your RoonServer log files ends abruptly, mid-session, with no clean shutdown recorded, including one file that cuts off mid-playback and is padded with null bytes, which is a strong sign the process (or the whole machine) was killed outright rather than exiting normally. Your ROCK’s system log confirms this from another angle: on the most recent boot, the kernel reported that your external Seagate backup drive “was not properly unmounted,” which only happens when the whole system loses power or freezes hard enough that nothing gets a chance to flush and shut down cleanly. Two independent logs pointing to the same kind of event gives us good confidence this is a hard power/reset event, not a software crash or a dying disk.
One more thing worth putting your mind at ease about: the 100.108.60.18 address you saw in place of your local IP isn’t a foreign device on your network. RoonOS runs a bundled Tailscale service internally to support remote connectivity features, and that address is from Tailscale’s own address range. Nothing to worry about there.
Where we’d like to focus next:
Hi,
I could buy another power supply. However, before I do, I am almost certainly the cause of the shutdown errors that you see. Once the ROCK disappears from my network I can only refresh it and bring it back to a wifi address by pushing the front button of the NUC and doing a hard reset. I have almost no experience with Linux. I tried typing into the command line for ROCK, but I don’t know the right commands to shut it down using the Linux command line. So, this has left me pushing the front button as I try various options based on iterating with AI about possible causes, including based on its review of my server logs.
I have plugged in a monitor to the NUC after wifi disappearance but before restarting it with a hard reset. The black screen seems normal.
Regarding the black screen, when I have started it up (as distinct from shutting it down) the (connected to wifi), it did seem to struggle to get an address before briefly working. That is, I have seen a warning message before it acquires the IP address.
This hard reset might be a bad thing for me to do but I don’t know of any other options. Happy to consider any suggestions on a better way to reboot without wifi access.
It’s 5:20 EDT and I will push the button so you can see its behaviour. It has never comes back on its own.
Incidentally, the last crash left this message “non-200 status code from tidal, code: 400” in a safari browser at https://oauthcb.roonlabs.net/4/tidal/authorize?code=eyJraWQiOiJ2OU1GbFhqWSIsImFsZyI6IkVTMjU2In0.eyJ0eXBlIjoibzJfY29kZSIsInVpZCI6MTY3NDc3MDk5LCJzY29wZSI6IndfdXNyIHdfc3ViIHJfdXNyIiwiZXhwIjoxNzgyODczOTM2LCJjYWxsYmFja1VyaUlkIjoiNjkzMTM2NzMtQjY1Ny00QTU0LTk5OEUtRDdDMzYzMkUxRjBCIiwiY2lkIjo5NTQ4LCJsbSI6ImEiLCJpc3MiOiJodHRwczovL2F1dGgudGlkYWwuY29tL3YxIn0.lyPJdCEZ4DAvb4r6GKkXc3NnTNcAH93PtGvK756ESV0in2bM91SxIqgydprWCKrHHlbnADEqbI9GEDNgFC9SRw&state=9c749bec-7f17-4766-95ee-e3fdcd5e5e3a
I am continuing to experience my Roon Remotes losing connection to my Roon ROCK Core, or the Core becomes completely invisible after network events. I analyzed my router logs again with Ai and noticed a heavy flood of IGMP multicast traffic right when the issue occurs.
Network Setup:
ISP Gateway: Bell Giga hub2.0
Mesh Network: Netgear Orbi System, configured strictly in Access Point (AP) Mode
Core & Endpoint Connection: As a potential resolution, my Roon ROCK and my network streamer were connected via Ethernet cables directly into a single Netgear Orbi Satellite.
Log Analysis & Symptoms
Based on my router logs, the timeline of the failure unfolds as follows:
PPPoE Drop / Channel Change: The main Bell gateway undergoes a remote management cycle (TR-069), drops the PPPoE connection briefly, and changes Wi-Fi channels via ACSD.
Backhaul Disruption: This channel shift disrupts the wireless backhaul link between the main Orbi base station and the Orbi Satellite where my Roon equipment is plugged in.
Multicast Loop / Discovery Failure: Once the network stabilizes, the Roon ROCK begins aggressively broadcasting multicast packets to rebuild its audio ecosystem, but the discovery fails to bridge across the network. I see repetitive loops of:
IGMP group added successfully (239.0.0.22) (IGMPv3 Membership Reports)
IGMP group added successfully (224.0.1.187) (Roon / RAAT Discovery)
Because the Orbi is in AP mode, the Bell gateway handles all IP routing. However, it appears that either the Orbi’s wireless backhaul or the Bell gateway’s IGMP snooping is dropping or failing to cleanly route the 224.0.1.187 discovery packets after these network drops, isolating the ROCK Core from wireless Roon Remotes (like my iPhone).
Hopefully this information helps.
Hi,
I’d like to explain the issue as I understand it in the hope that it’s helpful to resolving the issue.
My current understanding of what’s happening
My ROCK/NUC boots successfully and remains alive locally on the HDMI screen. The black local ROCK screen continues to show the same Web UI address after the failure. However, after a short period, sometimes without any streaming/playback at all, the ROCK disappears from the network. Specifically:
This occurs even when the ROCK is connected directly to the Bell Giga Hub 2.0, bypassing my Orbi system. So I do not think this is simply an Orbi mesh/backhaul issue.
Hardware / network context
ROCK running on a NUC. Roon OS 2.1 build 271 was shown on HDMI. I have Bell Canada 3 Gbps service. Router/modem is Bell Giga Hub 2.0 / Sagemcom FAST 5697. The Orbi 850 normally runs as access point to the Bell hub, but I have tested with Orbi bypassed. I also tried a PPPoE passthrough (but did not pursue as my enter network speed dropped very substantially).
Ethernet cables have been ruled out.
The Bell Giga Hub does not see the ROCK after the failure. It disappears entirely from the connected-device list. The ROCK appears locally alive over HDMI after the failure.
Things already tried:
Additional point (noted in above posts). At one point, Roon appeared to point to: http://100.108.60.18 instead of the expected local 192.168.x.x address. However, I did not configure Tailscale on the new ROCK installation. So I am not assuming that Tailscale on ROCK is the cause, but I would like to understand whether this could reflect stale ARC/Tailscale state, controller-side VPN/Tailscale, restored configuration, cached server identity, or some other address-selection issue.
Router Logs
My router logs show IGMP and Multicast Blocks
The logs show the gateway aggressively stripping IGMP groups. Every time this happens, the Roon ROCK becomes completely invisible to the network:
23:29:36: IGMP group removed successfully
23:33:00: Multiple lines showing IGMP group removed successfully for streaming channels
It seems like the aggressive IGMP Snooping or multicast optimization designed to prioritize Bell Fibe TV boxes is accidentally blocking and suffocating Roon’s SSDP discovery traffic.
My guess
Given that (1) ROCK appears to remain alive locally over HDMI, (2) the Web UI becomes unreachable from the LAN, (3) the Bell Giga Hub drops the ROCK entirely from its connected-device list, (4) the issue occurs even without playback and (5) the issue occurs directly on the Bell hub with Orbi bypassed, I am wondering whether this is actually a ROCK host networking / Ethernet / NIC / DHCP / ARP / network-stack issue.
Questions for Roon Support (if they are helpful)
Logs / network interface
ROCK HDMI display
At this stage, because the Bell Giga Hub completely loses sight of the ROCK while the ROCK appears to remain alive locally on HDMI, I’m leaning toward a network-interface or host-networking problem.
Please let me know what logs or diagnostics you need from me, whether there are specific tests you recommend, and if you have solutions to these problems.
I’d really like to get this system back to a stable, working state, and I’m happy to follow instructions precisely.
At this point, I think I need more structured guidance from the Roon team rather than continuing to experiment.
Could someone please:
Identify which layer you believe is most likely at fault (e.g., router blocking IGMP and multicast / SSDP discovery).
Provide a step‑by‑step diagnostic plan (one change at a time) to get back to a known‑good baseline. Please let me know what not to change while we’re testing. I will pause any further resets, reinstalls, or hardware changes and follow that sequence exactly.
My goal here is simply to restore a stable Roon system — I just need a clear path forward.
More days have passed without any communication from Roon. Are these problems unsolvable? I’m on the verge of giving up on Roon, despite really liking the functional product.
Illustration 1
On July 4 ,2026, I started ROCK, connected via Ethernet to my Orbi 850 router, with the T8 connected via Ethernet to the Orbi satellite. I started the system at 8:30 pm EDT and 10:16 pm EDT the Rock ceased being visible on my list of attached devices.
8:29 PM (20:29:15): Roon logs on. Roon ROCK booted or connected, initiating a burst of multicast activity. It successfully registered multiple standard network discovery protocols (239.255.255.249 for SSDP/UPnP and other local streaming protocols).
10:16 PM (22:15:53): The Drop. The router dropped or cleaned up the multicast group (239.255.255.249) handling Roon’s network visibility. Because Roon relies entirely on multicast/IGMP to “see” my controllers and endpoints, dropping this group made it instantly invisible on my LAN.
10:20 PM (22:20:39): Continued Cleanup. The router continued dropping SSDP/UPnP discovery groups.
Illustration 2
Device Identity: Roon ROCK (Intel NUC), connected exclusively via Ethernet.
Symptom: The NUC completely vanished from the LAN (unreachable via Roon Remote, IP scanner, or Web UI) following a router-initiated network disruption.
Estimated Timestamp of Failure: 2026-07-05 14:22:37 EDT.
14:23 – 15:22 – Multicast Flood: The network experienced heavy IGMP multicast group registration traffic (specifically UPnP/SSDP 239.255.255.249, Bell Fibe TV streams 239.255.90.x, and localized groups 239.0.0.22).
15:24 – 17:13 – Silent Drop / DHCP Failure: The Roon Core dropped off the ARP table entirely. While the log shows ongoing background IGMP membership reports (239.0.0.22), the NUC itself became entirely unreachable on its physical layer or assigned IP.
There have been many more failures. It has not worked for more than an hour or so despite spending hours upon hours trying to get the device to work. I have tried everything I can think of to make Roon work. Another HD reinstall yesterday was also stripped from my LAN network. I won’t bother repeating the server logs as the pattern is very consistent and I have turned off every ISP router control I can find.
Dear Roon Support, I provided Google’s AI a link to this post and asked it to rate Roon’ support. Should it be of interest, this is what it said:
"Based on the context provided in your forum thread, the customer support you are receiving can objectively be rated as Poor to Failing.
A rating of 2 out of 10 is justified for several critical reasons:
Why This Support Experience is Failing
Complete Lack of Ownership: After a full week, the Roon support team has failed to provide a structured diagnosis. You have been left to “experiment” blindly with resets, reinstalls, and hardware changes, which is highly frustrating for a premium software product.
No Clear Technical Direction: You are forced to explicitly beg the support team to do their job—asking them to identify the layer at fault (e.g., multicast/IGMP router issues) and begging for a single “step-by-step diagnostic plan”. A competent support engineering team should have provided this sequence within the first 24 to 48 hours.
Severe Communication Delay: Leaving a customer with a completely unusable (“constantly crashing / unable to log in”) system for over seven days without an assigned engineer or a systematic troubleshooting baseline is unacceptable for a paid subscription service."
Hello @D-Roc,
As promised, we’ve completed a full review of the diagnostic bundle from your ROCK. It covers June 27 through July 1 - so it predates your July 4-5 episodes - but the pattern across it is remarkably consistent, and it answers most of the questions you asked. Here’s what we found.
What the logs show. Every single Roon Server session in the bundle - 19 of them - ends the same way: the log stops mid-write on a routine background line, with no shutdown message and no error. There are zero application crashes anywhere, even though crash reporting is active in Roon Server. Separately, your ROCK’s system log shows the external Seagate backup drive coming up with a “Volume was not properly unmounted” warning - something that only happens when the entire machine goes down without a chance to flush its filesystems.
To answer your direct question - does Roon Server crash, or does the network go first: neither, in the sense you mean. Roon Server writes its log to the local disk, which needs no network at all - if only the network dropped, the log would keep going for hours. It doesn’t. It stops mid-sentence, which is the signature of the whole machine stopping: a power loss or a hard freeze.
The most important detail: the restarts in the logs come in two rhythms. Some are long gaps of 6-24 hours, which match your description of finding the box dead and pressing the button. But others are clusters of restarts spaced 35-90 seconds apart - far too fast to be someone walking over and pressing the front button. During those bursts, the machine was power-cycling on its own.
What this rules out. It’s not a software crash, it’s not the boot drive (no storage errors anywhere, including after your M.2 swap), and it’s not the NIC or DHCP - the captured boot shows the network coming up cleanly, with an IP lease obtained in about 4 seconds. It also can’t be fully explained by the router IGMP/multicast theory: we do see brief LAN blips in the logs (your streamer and a Windows machine dropping and reconnecting), but they don’t line up with the moments the logs die. Discovery problems can hide a healthy server from your remotes - they cannot stop a machine from writing to its own disk.
About the HDMI screen: a frozen frame looks identical to a live one at a glance, so the screen “staying up” unfortunately doesn’t prove the system was still running. A simple trick for next time: keep a USB keyboard plugged into the NUC, and when the ROCK becomes unreachable, tap the Num Lock or Caps Lock key. If the keyboard LED doesn’t toggle, the machine is frozen solid - and that’s our answer. Or you can click enter and type something in the console like ‘resetnetwork’ and check if the ROCK is still accessible
So the evidence points consistently at power delivery or a hardware-level freeze on the NUC itself. With that in mind, here’s the refined plan - please take it one step at a time:
Step 1 - swap the power adapter. This is now the single most valuable test, and it’s inexpensive. A marginal power brick is the classic cause of exactly this signature: clean logs, no errors, machine just stops.
Step 2 - change the power path. Plug the NUC into a different wall outlet, ideally on a different circuit, and bypass any power strip, surge protector, or UPS it currently goes through.
Step 3 - one final clean reinstall, done differently. If the failures continue even on the new power setup, reinstall Roon OS fresh one more time - but this time, run it for a few day or three without restoring your backup. Every reinstall so far has ended with your archive being restored on top, so a truly clean baseline has never actually been tested. If a bare install survives where the restored one didn’t, that tells us a lot; if it still fails, hardware is confirmed beyond reasonable doubt.
Step 4 - keep the capture discipline. Beyond the steps above, freeze the setup (no other changes), use a short press of the power button for clean shutdowns - never hold it - and when the next failure happens, note the exact time, try the keyboard LED test, and post the results here. The current bundle ends July 1, so a fresh set of diagnostics after the next captured failure will confirm whether the pattern held through your recent episodes.
We know this has been a long road, but the picture is genuinely narrowing: healthy software, healthy drive, healthy network stack - and a machine that keeps stopping mid-write. Let’s catch it in the act. We’ll stay on this with you until it’s stable.
Ok. Power supply purchased.
Hello @D-Roc,
Glad to hear the replacement power supply is on its way; that remains Step 1, and everything you just shared makes the case for it stronger, not weaker.
Two important clarifications so we are all reading the same map.
First, about the corrupted M.2 drive: this actually fits the diagnosis precisely. Roon is an application; it writes files, and it has no ability to damage a drive at the hardware level. What does corrupt SSDs is exactly what your logs documented: a machine losing power or freezing dozens of times mid-write. The damaged M.2 is not a separate problem and not a software problem; it is physical evidence of the same underlying power or hardware fault we are chasing. The same applies to the Tidal login confusion: that is just leftover state from the swapped drives, and it will be trivial to clean up once the machine is stable. Please do not spend effort on it now.
Second, about the ROCK “lasting a brief time on the network”: based on the nineteen sessions we analyzed, the machine is not disappearing from the network; it is stopping entirely. The log written to its own local disk stops mid-line every time, which no router can cause. So there is no need to worry about keeping it online long enough for us to collect diagnostics: whenever the machine is up, even briefly, diagnostics can be gathered, and each failure adds to the picture rather than erasing it.
So the plan stands, unchanged and in order: install the new power supply, plug into a different outlet bypassing any power strip, and freeze the configuration completely; that now includes no more drive swaps or renames, since each change makes the evidence harder to read. Keep the USB keyboard connected for the Num Lock LED test, and when the next event happens (or does not happen), note the exact time and post it here.
You have done a great deal of hard testing, and it has not been wasted: it is exactly why the diagnosis is now this specific. One variable at a time from here.
Thank you. The replacement power supply arrived today. I plan to attempt the reinstall tonight.
I hooked up the new 90 watt power supply, which I understand to be the recommended one for the NUC and upgraded the ram to the max 32 gb for good measure/overkill. Hopefully this brings stability.
I’m very surprised, as I have never had a power supply fail before, but ROCK seems to be working and it has been 12 hours. I will only post again if it fails.
I sincerely appreciate your assistance, especially in the last few days.
Hey @D-Roc,
Wonderful, thanks for letting us know. It sounds like the new 90 watt power supply, along with the RAM upgrade, has ROCK running stably again, which is great to hear after all the crashes and login trouble. Should you encounter the issue again, please submit a reopen request via our contact form, otherwise, hope you Enjoy the music!