In that house I have 3. They all fail at various points. One was a Roon certified DAP, one is a second Mac and one is an iPad Pro. Also using my iPhone as an endpoint in the house occasionally failed. As a note that also happens at the house here, so it’s not specific to a single device.
well that’s crappy.
There’s definitely a division between users who seem to have no issues, and those who simply cannot get roon to behave. Would love to know what the issues/differences are. Like, if I relocated my entire roon network (not a complicated one) to your house, would roon work ok?
Tempted to create a thread asking “if you had chronic roon connection issues, but now have none, what changed?”
(For what it’s worth, my core is a 2012 Mac Mini with 16 GB RAM.)
I think RAM is another underappreciated requirement. The more the better.
My Core is an M3 Multicore Macbook Pro with 32 GB of Ram. Pretty sure there isn’t a memory issue here lol.
My NUC7 running Roon Core on Debian has 8 GB RAM and uses less than 3 GB. Just playing, no upsampling nor DSP.
I also use sometimes with this NUC HQPlayer Embbeded for DSD256 upsampling. The RAM use keeps under 3 GB. Now the CPU use increases, of course, as well the CPU temperature.
you probably know this, but just a general PSA for roon-server/core macs (especially laptops):
All Energy Saver settings need to be set to not sleep, and set to wake for network access just to make sure ![]()
Well it doesn’t have to be. If you can make it work on good wifi, that’s fine, and some people do. But the limitations of wifi have to be taken into account, and for most people it’s easier to just wire the server. If it doesn’t work on wifi, then that’s simply the first place to start analysis.
I find it a bit ironic that Roon on the one hand pursues the “modern market” of mobile users with ARC but on the other hand isn’t working to streamline its network requirements so that wi-fi dependent users can rest more easily when using the main Roon software. So it’s a little odd to be pushing to the present and future on one side and holding users back to wired networks only on the other side. Wired networks just are not the way of the future, even though they are so much more dependable.
My Roon setup is entirely wired, albeit sometimes the network path is through multiple switches (single NAT though). Roon works perfectly 75% of the time, which is why I know that the 25% when it is misbehaving is Roon software and not my network. Why would rebooting Roon solve a network problem temporarily?
My theory on why it works for some and not others is that when it works for some, those users are not pushing Roon the same way the others are. For example, I ripped my DVD-Audio collection back around 2004 to get hirez before there were downloads or streaming hirez available. Similarly I have a lot of digitized vinyl. These are standard commercial albums but the song length is off by a few seconds from what is in the database, so many are unidentified.
The result is that Roon acts like a hunting dog and won’t stop trying to identify albums for which there will never be matching metadata, and I don’t feel like going through the album identification process for 700 or so titles (because that process is brutal even for one title). That identification process (as far as I understand what Roon is doing…it won’t tell me what it’s doing) strangles a single core for about an hour and it effectively kills Roon while that is happening. Restart and that process stops, at least for a while.
So if you don’t have a large library of unidentified, you won’t see this problem. So while I appreciate the helpful approach in defining your network when your Roon runs well, that doesn’t really help me. It just means I push Roon in a way that you don’t. My gripe isn’t that Roon needs to stop everything to fix the problem…but I would like to not have been told “this is expected behavior” in a way that tells me they don’t ever intend to fix it and that instead I should strip down my library. Plus there are some quicker fixes, like having the Roon Server restartable from a remote, and like being able to earmark an album as “don’t try to identify this anymore.”
Thanks for listening.
The “unidentified” thing is definitely a good clue to slowdowns/strangulations.
As an interesting test, could you somehow move those unidentified albums to a separate folder, and then disable that location so roon doesn’t look for that folder? And then see if that changes things?
Just as a test. (or maybe you already have)
lol, amirite
Even if the Core is hardwired there can still be issues with slow loading of albums and playback issues.
I love Roon , buts it’s a frustrating user experience at times
Indeed. Especially when you use it as directed and it STILL fails. I don’t understand why the management team carries on with a broken product like they do but I guess it’s sort of a “we’re the only one who does xyz so deal with it” kind of thing.
Notwithstanding the title of the thread, and our own challenges with Roon, we are still here using it. Why? Because even with its faults it does lap everyone else.
@ James_I
I think;
Due to the lack of alternatives currently available…and/or willingness to compromise.
It’s not all bad!
There are so many potentially interfering elements in WiFi , it can never be considered a cure-all
Mundane stuff like microwaves , baby-alarms etc all work on the same frequency
Building construction methods eg Brick Walls vs Stud and plasterboard
IN @sean.belliveau case a bi stone walled houses doesn’t sound good
Some people win ,some lose and it’s NOT just Roon !
My understanding is that buffering is kept deliberately low to facilitate Multi Room / Multi Zone Grouping sync hence the “Feature” comment.
many one zone media streams eg Netflix buffer a lot but who tries to get 3 room TV’s to sync ?
Hi @sean.belliveau, I guess that your case is not the common case. It would not make sense the people to buy a software product with the issues you describe. If Roon doesn’t work for you, you can try with another product. Be happy, Sean.
I think this is a myth. The DAC controls timing, and is responsible for buffering. Pull an Ethernet connection from the stream, and music continues to play for a minute. Similar with my Poly when out of Wi-Fi reach.
So, the network must be pretty shaky if it can’t cope with brief blips.
The simplest fix, which will cure many network-related issues is to place the server next to the router, with Ethernet connection, and avoid multiple Wi-Fi hops.
I’m not I moved back to what I used before Roon at beginning of the year and not looked back. Its moved on loads since I last used as my main app. For me it does everything I used or needed from Roon for 0 cost I never bought in to Lifetime so happy to call it quits. There are plenty of alts you just have to pick whats more important.
There’s at least this:
Now, excessive in this context meant loading a whole song or more into the buffer, so that doesn’t mean that Roon buffers are super tiny, but I think we do know that it buffers partial tracks in bursts.
However, at least in synched playback the smallest buffer of the synched devices must limit the size.
Yeah, but servers on congested WiFi channels over an inherently half-duplex connection and trying to move 192/24 from NAS to Roon Server and then from Roon Server to endpoint can have longer than brief blips and underrun the buffer.
That’s pretty strange.
When I’m hosting events for the Arizona Audio Video Club, I bring an inexpensive travel router that I connect to the Internet via USB-tethering to my smartphone. To the 1 Gbps LAN ports, I connect a tiny Roon Server and a network audio bridge (Raspberry Pi, iFi ZEN Stream, or similar). I have nearly 2,000 albums in FLAC and DSF format on an internal microSD card or USB-attached HDD, but we mostly stream from Qobuz.
For control, I have Roon apps installed on a couple of tablets and my laptop. Our Member Listening Night sessions typically run several hours. Even with this minimally spec’ed network and system with a less than perfect Internet connection, the Roon UI has been immediately responsive on all control surfaces for all of these events so far. Hoping this trend of success continues since I’m bring the same setup to an event later this month!
I realize that those who are experiencing problems with their Roon setups find anecdotes like these frustrating. I encourage them to take heart as these suggest that it is, in fact, possible to make Roon work flawlessly. Keep working at it.