What problems with networking ? Networking runs just fine if the connection is done with at least CAT5 and the only devices on the network are a router, a core, and as many endpoints as you may require !
No problems. But a lay customer might have trouble understanding the nuances… to judge from threads on this very forum!
I think the majority of problems people have with Roon are network related.
I was being ironic, hence the emoticon (even though a non-trivial subset of the issues raised here possibly would be fixed by my modest proposal to stop using WiFi range extenders and hardwire everything instead… one problem it unfortunately won’t fix is the non-technical user gets a used enterprise managed switch because they read on some forum that it sounded better thing, but, well…)
Ethernet to the Roon core is definitely the way to go.
Roon is a networked product and thus relient on a stable network.
Any problem within the network makes Roon fail.
A proper network configuration can be wired or wireless but MUST be stable.
This means that Roon as a product gets the blame for failure, while the network on premise is to blame.
Yes, this… and it never hurts to remember the (in)famous KISS principle… Keep it Simple and Straightforward… Reading through posts on this forum I sometimes wonder to what lengths people seem to go to make their home networks impossible to grasp, never mind manage in a stable way.
Pretty sure it’s “Keep it simple, stupid”, but who’s counting.
Or, “Knights in Satan’s service”.
I’m about to experiment with a “bad” network setup because it will take quite a while to get wired net throughout our new place: UniFi Dream Machine base router/station wired to the optical network terminator, Roon Core server wired to it, UniFi Flex HD (on order) elsewhere in the house next to a coax outlet, dumb wired to dumb switch, that wired to MoCA that feeds our LAN to the house’s cable infrastructure, and also wired to a Roon endpoint. Other Roon endpoints on other MoCAs elsewhere in the house. Wish me luck.
I was new to ROON and ROCK for a little more than year, I am a technical user. Perhaps I missed or it is my bad memory to blame, I do not recall seeing prerequisites or some sort of checklist for quality networking. I recently learnt that unmanaged switch might make a good difference in ROON; I have both. This sounds logical to have unmanaged switch as the preference, however, easy to be missed by technical users like myself.
Yes, and recently I’ve been trying to solve a customer network issue with it. And the use of a managed switch and another switch I’ve never heard of with the single selling point of VLAN was not declared upfront, requiring the use of time for basic setting diagnosis that could otherwise be skipped.
I’d like to understand why people use enterprise network stuff at home. This is especially true of Roon forum members. I have not seen such a high concentration of audio system users doing this in anywhere else. There are really advanced networking discussions here that even exceed audiophilestyle.com (where there are many experts and engineers).
This has to be the most annoying aspect of working within Roon’s support team, I just can’t imagine.
What roon should potentially do is build in some some light network monitoring functionality into core and controllers that will throw a pink dialogue box warnings when network degradation events occur. Something like “hey, your network sucks”.
I think there might be some IP issues where roon now uses TCP/IP where lost or dropped packets can potentially cause issues where as some other streaming protocols perhaps still use UDP where such issues are not impacting the connectivity as much. Just my guess.
Roon Core should IMHO be unsupported on a wifi/EoP connection. Endpoints not so much of an issue
Your guess is wrong. Both TCP and UDP have their own benefits but we’ve chosen what we do with full evaluation based on tens of thousands of machines running Roon with both.
Absolute agreement here. I’ve seen exceptions work, but very rarely. I personally would never do it.
Perhaps you can expand on the reason we see so many tidal issues where Tidal (maybe Qobuz too) client works fine but the same content via roon to the same endpoint is problematic…at least from the networking protocols / infrastructure involved perspective.
Same protocols, same infrastructure, same api streaming both. We don’t hold their content.
here is an example of things going bad…clearly there is more to this than just
If Roon actually pulls the whole queue (I didn’t check it myself) this approach is rather bad. Most, if not all streaming services are pulling data during playback progress. This is perfectly visible e.g. when watching video on YouTube, where the bar gradually fills up slightly ahead of the current streaming position.
Such an approach is bad for many reasons, mainly concerning bandwidth management and data waste. It may particularly affect those users who use connections with limited data, e.g. LTE, 5G. Very often it will happen that a user stops playback, changes the queue or switches to something else, so data downloaded due to the queue is wasted.
It doesn’t. Roon pulls track by track… Shortly before the end of the currently playing track, caching of the next track begins, using the available bandwidth to download and cache the next track. During playback no download occurs. This is what I see on my system, monitoring the Roon log in real time. I did this monitoring because I had intermittent problems with my Internet access.
The user who claimed that Roon downloaded the entire queue has 2 Mbps Internet access, which is clearly not enough for reliable streaming. I went through this problem myself and had my Internet access revised and repaired.
The user who made that claim in another thread mentions that he is limited to a 2 mbps DSL Internet access. When your available bandwidth is so seriously constrained, Roon of course will be downloading and caching near all the time. Keep in mind that even if you have nominally 2 Mbps, the real throughput may be less. There are continuous fluctuations of throughput, and there may be other traffic as well. So, citing this user’s claim out of context seems to me disingenuous.