Could a member of support staff pick up this topic again please. Crashes are ongoing.
@Geoff_Coupe please could you help with this thread which seems to have fallen off the support radar - thanks.
Hey @Ian_Tollett,
I’m so sorry for the long delay in replying to your issue! You are correct here, it’s slipped through the cracks, and we’ve made sure to set a priority tag to your issue to ensure this does not happen again.
I want to thank you for all the timestamps as well, it allowed us to review each individually and confirmed that the same issue is occurring for each stoppage you’ve reported.
The sequences all seem to mirror the same behavior:
- The Drop: At
20:33:02, the signal path suddenly goes inactive and throws aStoppedEndOfMediaNaturalerror. This usually happens when the server's buffer for the Meridian zone is starved of data or the control connection is interrupted. - The Trigger: At
20:33:06, we see the iPhone (172.16.0.14) connect to the Server. - The Storm: Immediately upon the iPhone connecting, the Server starts a massive metadata flush (
pending adds=27589). This suggests that when the iPhone app opens, it triggers a full library sync. - The Failure: The Meridian ID41 protocol is highly sensitive to network latency. The overhead of the iPhone syncing 27,000+ metadata objects appears to be saturating the network stack or the servers processing priority just enough to cause the connection to the ID41 (
172.16.0.58) to time out and "die."
With that - Many ID41 users are still on Software 1.1 (Build 163). However, the most stable “final” version for Roon compatibility is Software 1.2 (Build 218). Can you check this?
And, from reviewing your network setup from a prior thread - The Meridian ID41 is a 10/100 Mbps device, whereas your Orbi and Muon are designed for Gigabit (1000 Mbps) environments.
The Muon is a passive filter. While excellent for noise, older 10/100 NICs (Network Interface Cards) like the one in the ID41 can be very sensitive to the slight voltage drop or impedance change a passive filter introduces.
- Test: Temporarily bypass the Muon and connect the ID41 directly to a cheap, unmanaged 5-port switch (like a Netgear GS105), then to the Orbi. If the issue disappears, the ID41's aging NIC is struggling to maintain a stable "link-up" through the filter's passive stages.
Thanks @benjamin
Picking up on your questions:
- My ID41 is on Software 1.2, build 218 so up to date
- I removed the Muon from the network path to the ID41 after the earlier thread advice
- The ID41 is connected directly to the Orbi
- There is no long queue or play history “tied to” the iPhone app - I quite often use the iPhone app to play from a long playlist but don’t keep the playlist active in the queue afterwards.
I’ll try deleting the app and downloading it again.
What’s the easiest way to clear the past-played queue from the app?
It sounds though from what you’ve said that replacing the ID41 would help.
Another crash just now at 17.12 GMT playing Fool’s Gold by The Stone Roses.
This was after deleting and reinstalling the Roon app on my iPhone and playing a 22 track Tidal playlist. This was the 2nd track on the playlist.
Hi @Ian_Tollett,
Thank you for the reply and fresh timestamp. To confirm, did you open Roon on your mobile device, which caused the playback to stop?
Based on your Roon Server logs, the “initial stop” or hesitation when transitioning to Fools Gold wasn’t a hard crash, but a combination of a network “hiccup” and a stream reset.
At 17:10:24, right as the previous track ended, Roon logged:
Trace: [roondns] flushed 43 last-known-good entries
A DNS flush in Roon usually indicates that the server detected a change in network state or lost its path to the internet for a millisecond. Because Roon was trying to "handshake" with Tidal for the next track, this forced it to re-resolve the Tidal servers, causing a delay.
At 17:10:27, there is a sequence where Roon prepares the audio environment:
- It identifies the track as a standard 16/44 FLAC.
- The "Stop": It immediately logs
All streams were disposed. - It then re-identifies the track as 16/44 MQA and re-opens the stream at 24/44.
When the track finally started playing, your buffer was at 2%:
[Lossless... 24/44 MQA] [2% buf] [PLAYING @ 0:00] Fools Gold
Normally, Roon likes to see a much healthier buffer before it commits to the "Playing" state. Because the buffer was so low (due to the DNS flush and Tidal latency), any tiny micro-stutter in your network at that moment would have caused the ID41 to stop or "choke" initially before the buffer finally climbed to 100% at 17:10:32
Were any of the other tracks on the playlist MQA?
It wasn’t opening the app that caused Fools Gold to stop - it just did it anyway.
Later I tried playing the playlist again via USB to the ID41 instead of via Ethernet and it stuttered on Fools Gold again. That was the only MQA track that played.
So what is the answer for making Roon run healthily?
Also, has there been any repeat of:
I need to decide whether to get a new Roon Ready Meridian streamer; to ditch Meridian completely, or to ditch Roon completely.
@benjamin Do you have any advice following my posts above?
Hey @Ian_Tollett,
First off, I want to sincerely apologize for the delay in getting back to you, and I completely understand your frustration.
I know you’ve been dealing with these drops for a while, and it’s totally fair to question the future of your setup when things aren’t working as they should. We definitely don’t want you to ditch Roon or your Meridian gear!
Our engineering team has been closely reviewing the timestamps you provided alongside your logs, and we believe we’ve pinpointed the core of the issue.
What is happening: When you open the Roon remote app on your iPhone, it sends out a burst of discovery and synchronization data across your network (known as multicast or mDNS traffic). Modern mesh networks like your Orbi handle this extremely quickly. However, the network interface in the Meridian ID41 is based on an older architecture. It appears that the ID41 is getting completely overwhelmed by this sudden “storm” of multicast traffic from the iOS app, causing it to panic, drop the connection, and destroy the audio zone.
How we can fix this: Before we consider any hardware changes, we need to optimize how your Orbi router handles this specific type of network traffic. We highly recommend enabling a feature called IGMP Snooping on your router.
Think of IGMP Snooping as a “traffic cop” for your network. Instead of letting your iPhone broadcast its sync data to every single device on the network (which overloads the ID41), IGMP Snooping ensures that this heavy multicast traffic is only sent to the devices that actually need it.
Next Steps: Could you please log into your Orbi’s administrative interface (usually via a web browser) and check your settings?
- Go to the Advanced tab.
- Look under Advanced Setup.
- Locate the IGMP Snooping setting (on some Netgear/Orbi interfaces, this might be under WAN Setup or LAN Setup) and ensure it is Enabled.
Please let us know how the system behaves after making this adjustment. We’re committed to getting this running smoothly for you!
Thanks @alex_h - but my Orbi router doesn’t have an IGMP snooping setting. It does have “Disable IGMP Proxying” which I have had unchecked for a long time as recommended here:
@alex_h could you take another look at this please. Is there any other way to reduce the network overwhelm of the ID41?
I am considering buying the Meridian 210 streamer which is Roon Ready. Would this be better?
^ this is clearly not the case - very disappointing
@Geoff_Coupe is there anyway you could prod support into looking at this? Thanks
Hi @Ian_Tollett,
Very sorry for the delay here. To answer your question directly:
Frankly, the ID41 is based on network architecture from the Sooloos era (2009-2015), and it’s only through progressive firmware updates from Meridian that the device maintains pace and parity with modern mesh network technology. ID41 users tend to experience symptoms of sudden device loss when they use this device on large mesh networks.
Between the two, the 210 offers a more contemporary suite of network capabilities. Roon Ready is a stable, tested protocol.
There are a few classes of errors we’ve seen with playback in this thread.
Some of these are caused by longstanding, widely reported (but technically undocumented) network “panics” in the ID41 firmware. This is partially just a consequence of the device being significantly older than the network supporting it.
Then, there are the dropouts with a more recognizable cause, some of which you’ve encountered when connected via USB. Some of these we’ve traced in logs to instability and packet loss during audio transport with streaming service playback. We’ve tried to limit this by hardwiring everything and optimizing mesh network settings so the network carries traffic in a manner Roon expects. From logs, this seems to have helped eliminate some of the frequency of these errors.
What dropouts or unexpected pauses have you experienced in the last few days? If you can provide the track names, we’ll investigate. Thank you again for your patience, as the team has been somewhat understaffed this week. We’ll ensure we respond much sooner moving forward.
OK thanks. It seems pretty clear I need to update the ID41. I’ve got a chance to trial a 210 so I’ll do that and report back.
Hi @Ian_Tollett ,
Thanks for letting us know, we’ll be standing by to hear back from you on how your 210 testing goes!
