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:
Zone selection (without any “local” zones as I don’t want to play music off the tablet speakers)
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?
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.
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.
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.