Best Practices = Reliability?

I am always puzzled when I see people having problems, sometimes extreme, with Roon and ARC. I am no starry-eyed fanboy, but my experience has been excellent.

I use Roon 4 - 5 hours every day, and just got back from 3 weeks away where I used ARC daily. Roon is not perfect but is easily as good or better than anything else. Jeez, look at Sonos if you want to see real pain!

Key Success Factors:

  1. Internet connection, gateway/router, and any Ethernet switches are all working properly
  2. All Roon Devices (Core, Endpoints, whatever) are connected via Ethernet, with the obvious exception of your Roon Remote devices
  3. My Core is a Roon-spec Intel NUC with my FLAC music files on a Samsung USB SSD attached to it
  4. My Endpoints are DIY RPi3’s and 4’s with HiFi Berry HATS running RoPieee, connected to a variety of DAC’s and amplifiers. They’ve been flawless.

My network is nothing special - 250 megabit service from my cable TV provider, a Motorola cable modem, a TP-Link Router, and TrendNet switches. Definitely not fancy.

Any weak link can probably mess everything up, but over 5 years now, I couldn’t be more pleased. Does this match the experience of others that use Ethernet and have configs similar to mine?

15 Likes

I asked the same question about 14 months ago: Best Practise for Roon - Networking

At that time my network was far from ideal since I used Powerline adapators to distribute ethernet around the house:

Nevertheless, I still had a good Roon experience.

Since then, my home network has been improved a lot (I elliminated the powerline adaptors and established a 10Gbps backplane) and now looks like:

I have never had any problems with Roon.

I do not use a MESH WiFi system - the Asus routers that I use can propagate WiFi to a reasonable standard throughout the house (which is not large) but, with this latest network implementation, I don’t normally use WiFi for audio (or video) streaming. It is occaisionally used to casually stream to phones and tablets. WiFi connected phones and tablets are used as control surfaces.

I have a configured my network simply: I have all my computers, phones, tablets and streaming devices on a single logical network (not separated by use of VLANs) and I use unmanaged switches throughout for simplicity.

I use a NUC11 for my Roon Server (on the ROCK compatible hardware list) but I don’t use ROCK (I used to but migrated to DietPi nearly a year ago).

All dedicated audio zone/endpoint devices are connected by ethernet and network capacity is planned such that non-audio activities (like editing video on my NAS) does not saturate any of the inter-switch links to the extent that Roon (or any other activity) is starved of network bandwidth.

My broadband is reasonably good - 500Mbps down/ 73Mbps up - but importantly, it is low latency FTTP GPON based service. Previously, I used a 1Gbps down/50Mbps up DOCSIS service which had much higher latencies. Many internet related activities are actually faster on the new service despite the reduced download data rate.

Finally, whilst I have a number of hi-res albums, I don’t have (and I don’t believe in the need for) any local library albums sampled at higher than 192kHz.

Of my four main endpoints, one is an ARCAM ST60 streamer which has been absolutely flawless since I bought it (although I believe that there were some teething issues with this device) feeding into a 25year old Denon 3802 AVR with a 3.1 speaker setup (I used to have a 5.1 setup but room use and aesthetics demanded the removal of the surround speakers :frowning: )

The remaining are RPi4’s running DietPi and Roon Bridge - one using USB to a FiiO K9 PRO headphone amp, one with an IQAudIO DigiAmp+ HAT (30W/channel max) and thence directly into passive speakers and one with an IQAudIO DacPro HAT into a Ruark R1 mk 4 radio/alarm clock.

4 Likes

I agree! I have had very little issues with Room (overall). I think it is by far the best option out there. My only gripe is Arc. While Arc works fairly well (it has come such a long way) while I am connected to the internet, it is awful when I am unable to connect. Using Offline mode is an awful experience. I don’t need to be offline often (usually only while travelling, airplane etc) but it would be amazing if Arc worked well while offline (like an old iPod was). I also purchased a Fiio m11 and it would be great to use this offline. Would also love to be able to download music to a SD card. Hopefully one day they make this experience great!

2 Likes

I agree except my main listening room endpoint uses an RPi4 connected by WIFI and is flawless. WIFI can work well for endpoints depending on signal strength and interference, etc.

4 Likes

As I wrote elsewhere, I have a hardwired NUC and NAS but only WiFi endpoints and have zero problems at home with streaming music in Roon.

ARC, when using at home on WiFi is fine, ARC when using away on 4g or 5g is fine.

ARC when using and switching from a WiFi connection to cellular loses the play queue, mandating the closure and reopening of ARC to resurrect it. Many others experience this and whilst might seem relatively easy to remedy, is a pain when solo driving when touching a phone is illegal here.

Whilst ethernet is best practice, it’s not a necessity, I have no issues with it at all.

Only networking problem I ever had was sudden persistent dropouts. I got rid of the Xfinity gateway and installed an Orbi system and it’s been rock solid since. I use a combination of wired and wireless endpoints, but my core is wired direct to the gateway/router. Endpoints are all Pi3 or Pi4 running Ropieee (highly recommended).

I think, and it’s been said before in this thread, that this is the most important point. Connecting endpoints by ethernet does not have the same positive impact on ultimate network reliability as connecting the Roon Server by ethernet (although connecting endpoints using wired ethernet is still a positive compared to everything connected by WiFi).

3 Likes

I don’t use ARC but otherwise fully agree. I use one NUC and two roon-ready endpoints, both with ethernet. One of them, a Zen Stream, works equally well via wifi. It’s been up and running for 2.5 years without any issues.

I find it curious that people who have no issues with Roon are often the first to comment when someone mentions they’re having problems. While I’m sure it’s well-intentioned, it doesn’t really help—it’s a bit like telling someone with lung cancer that you’ve smoked all your life and are perfectly healthy.

9 Likes

The best is to analyze what the no problem user is doing that the problem user is not.

I restart daily i have no problems 8yrs and counting

I’ve been thinking about what might contribute to the smooth experience some people have with Roon. One key factor seems to be that many of them have simple networks with minimal security measures. But things are very different in a busy household.

For example, I rely on a mesh network to get proper coverage, which immediately introduces potential points of failure even though I use cabled connections where ever possible. On top of that, I typically have around 32 devices connected, with another 40 offline devices on the list. Modern homes are packed with IoT gadgets—media players, phones, tablets, watches, laptops, camara’s, doorbels, smart lighting, and more. And when you add dodgy manufactureres and teenagers into the mix, robust network security becomes essential. That’s another area where Roon can struggle.

Take ARC, for instance—I’ve never been able to get it working without turning off far too much security, which isn’t something I’m willing to do.

Out of the four people I know who use Roon, two (both single guys with simple networks) don’t have any issues. Another person with a setup as complex as mine has similar struggles. Meanwhile, services like Spotify work 99.9% of the time and are consistently fast. In fact, every other music player I’ve tried has been stable—except for Roon.

Roon seems to be overly sensitive to what’s happening on the network, leading to issues like playback stopping, slowdowns, long connection times, and so on. I see this as a fundamental design flaw. Roon really needs to be less dependent on a user’s specific network environment. No other music player I’ve used has this level of fragility—it’s only Roon.

And yes, I’ve reached out for help in the past, but the issues persist. My point is that it’s not helpful to comment that you’re having no problems when your situation is completely different. I’ve even tried switching off everything on my network except the Roon server and one endpoint. That setup does run stably—until I hit another recurring issue with Roon: memory leakage. Sure, rebooting daily helps, but that’s not how a server should function.

The only real fix for me would be adding a second internet connection, but I’m not willing to pay another €40 a month just to keep Roon running smoothly.

I’m genuinely glad that some people don’t face any problems, but it’s clear to me that Roon struggles in complex network environments. I believe this is its Achilles’ heel. While the software itself is excellent, the slowdowns and hiccups drive me crazy.

Lately, I’ve been using Spotify more, and to be honest, now that I’ve gotten more familiar with it, I don’t miss Roon as much as I thought I would.

4 Likes

You are right , I have a simple set up, Fibre to a Router the devices are simple 2 x desktops, TV , NUC and One Zone headphone amp.

The rest is phones and iPads by Wi Fi, 2 elderly users , no kids, and that’s about it.

I understand servers should run 24/7 but in Johannesburg we have nasty thunderstorms which some years ago cost me a lot of hi fi kit when a neighbour’s tree caught a direct strike so after that all sensitive electronics is unplugged when lightening is due or even so overnight. I am convinced the KISS principal works

Roon User for 22 months (Still a baby!).

When I was using ROCK (First 11 Months) I used to manually restart Roon Server (not the OS) every week or so simply because there were a lot of people suggesting that that was a good idea due to memory leaks and, with ROCK, I didn’t have the tools to see for myself. Most of the time, the Roon Server restart made no noticeable difference to Roon operation.

For the last 10 Months, I have been running DietPi (on the same NUC). On migration to DietPi, I initially configured a nightly restart of Roon Server (again, not the OS) but soon decided that this was completely unnecessary so I changed it to Weekly. Just recently, I have started an experiment with no restart at all. It is, however, far too early to comment on the impact that this change has made (I’m only 2 weeks into the experiment).

My experience, with the weekly Roon Server restarts, is that both ROCK and DietPi have been exceptionally reliable. I don’t recall ever having to restart/reboot the NUC other than the occaisions when I had to power it off due to external factors.

Having said that, I know, from comments made in other threads, that @Mike_O_Neill has other, very valid, reasons for the daily restart.

If the response is something to the effect of “Well it works here!”, then yes I agree.

If, however, the response it something like “I don’t have that issue possibly because …” then that is a different matter. With such a response, it’s not the “I don’t have that issue” part of the statement that should be focused upon. It is the “possibly because …” part. That may well give clues as to the reasons for the difference in experience and thus the actions required to improve the experience of the poster with the issue.

Of the responses to peoples requests for help that I have seen, by far the majority fall into the second catogory. At least in intent. There are, of couse, many occaisions when the response has been off the mark for one reason or another and not particularly helpful as a consequence - I have done it myself :frowning:

2 Likes

I’ve been using Roon since 2016, currently on 3 separate sites. I worked through a number of issues, and I helped Roon staff debug some of them. I’ve learned through experimentation that RAAT is quite sensitive to WiFi packet loss/retransmit. If for some reason there’s a burst of losses/retransmits – not unusual in busy WiFi environments – the delay induced on the RAAT stream causes Roon to give up and skip the track. This can happen even with a robust WiFi network if someone in your household is, for instance, doing a high-resolution video call over WiFi while you are listening to music. Careful tweaking of WiFi configuration to put different devices on separate channels may help, but you can’t control which channels your neighbors are doing their video calls or downloads on…

In my interpretation, the above behavior is the result of a design choice to buffer very little in the endpoint to simplify endpoint requirements and to make it easier to synchronize multiple endpoints in a zone. If that’s the case, I wish RAAT control was changed to recognize un-zoned endpoints with sufficient buffer capacity and go into a mode where additional buffering could be used to smooth out bursty packet loss.

3 Likes

This. This reinforces my original point that any Roon device other than something running Roon Remote should be connected via Ethernet, at least if you’re using RAAT, which I was assuming.

This is true unless you don’t have ethernet available at said location and your WIFI situation does not cause problems. I use WIFI to my main listening room with never an issue. Don’t automatically assume WIFI can’t work well for an endpoint. If WIFI did not work well, I would go to the expense and/or bother to run ethernet.

2 Likes

I currently have 3 managed switches, ~40 devices generally online, a somewhat managed switch built into the main router, switches in mesh extension units (technically, managed if you ran them standalone), and Roon on NAS that only gets restarted when there’s either Roon or DSM update. Everything, including ARC works. It’s not so much a complexity of the network as a planned design.

For me the key was using WiFi - until I moved ALL of my endpoints to Ethernet, I had constant problems with Roon connectivity.

How large is your library? My 20k+ albums breaks ARC. When I was an early beta tester, it worked for me a couple of years ago and prob had 16-7k albums then. I’ve given up on the idea of ARC working for me and because PlexAmp does what ARC should do flawlessly.

Daily restart is key but doesn’t solve my ARC issue.