Understanding Roon Remote and why it's so "heavy"

Howdy, on day 2 of using Roon so there’s that… but… I’m a bit perplexed with Roon Remote.

I completely buy-into the distributed nature of Roon of having the server doing it’s thing, the playback device doing it’s thing, and “remote” being the control center to select tracks and point them at the playback device… except… Roon Remote does far more than that. Why?

My ideal “remote” would be limited to:

  • Profile selection
  • Zone selection (without any “local” zones as I don’t want to play music off the tablet speakers)
  • Music selection

But more important than that… limiting the functionality of the “remote” would greatly reduce the complexity and chattiness of the software on the network. It would allow for a single TCP socket to be used to control the Roon Server (I could even point the app at an address instead of requiring a “discovery”). This would make things like BYOD/Guest devices on isolated networks able to reach Roon without the need for complex port forwarding / multicast relay etc.

I see there has been discussion of a “party” mode for Remote but I really think it goes beyond that. My (granted very early) investigation of what the Remote is doing on the network reveals an overly complex and, frankly, bloated implementation of what a “remote” should be in the traditional Server/Streamer/Remote environment. Remote is really acting as “Admin Console+Remote+Streamer” and the product I really want is just the remote.

So, my questions after all that: Is my ideal Remote possible? Would integrating with home automation do what I want? Is a true “Remote” on the roadmap (at least maybe for tablets)? Or am I fundamentally not understanding Roon?

You can get that (maybe without profile selection) by installing the Web Controller Extension but you will miss the browsing through your library experience which makes Roon so unique.

You don’t have to enable devices that you don’t wanna use. Only enabled devices show up as play zones.
Click on the cog-wheels to disable zones.

The problem I have with showing “local” zones in a remote is that part of the Roon Core discovery process is that it negotiates the ports needed to stream to my local device. I want that removed so “finding Roon Core” doesn’t have a dependency on that functionality.

You should then open up a Feature Request for that, I guess.

BTW: Shouldn’t be a problem when you use the Web Controller Extension.


In what way will that improve the performance or the experience of most users?

Although, as we discussed in the Roon API Web Controller Extension Thread, the web controller will always show all zones, including private ones (ie. Remotes that do streaming.)

Thank you @CRo, I’m aware of that (and imho is expected behavior).

Remotes need to be able handle many things including setting up devices where the might only be a remote and a headless core server like Nucleus or ROCK

I don’t really understand the need for this. The remote great doing what it does. I don’t want to have to use different apps or web clients to setup and change settings.


Thanks for the suggestions everyone. It may very well be that the Roon Web Controller is the answer. However, I’m running ROCK so it appears I need to get a Node.js server built on the local network? Topic for another thread.

For those confused by my question I totally understand that. In a lot of ways having the Remote do everything under the sun makes sense. My position is that, in the Roon Ecosystem, what is lacking is a real remote that is used for control of music playback. Not an all in one Config+Remote+Endpoint Setup+Everything else. Roon as gone to the trouble of identifying Server, Remote, and Endpoint development to maximize resources within each. I’d like to see them break it into Server, Remote, Endpoint, and Admin/Console. It would reduce the size and complexity of the remote while at the same time making the configuration interface much more streamlined and user friendly (not to mention a heck of a lot more secure through the elimination of accidental “I don’t know what this knob does”). I’ll open a feature request.

One other reason I can see for having a true “Remote” is for installers who don’t want their customers getting into the configuration. Locking the config prevents the accidental house call and a generally disgruntled customer even if that customer caused their own issue. The installer would hand the Remote to the customer without that customer having access to any of the configuration.

1 Like

I still don’t see it.
The weight of the remote doesn’t come from the Settings area.
The remote provides a very rich way of navigating the library, and that is the central value proposition.
I have a hard time seeing any value in a remote that doesn’t do Roon stuff.

Just use a phone. Problem solved.

1 Like