I have an old win81 laptop that I’ve just dusted off for use as a remote access device. I would like to install just the roon remote client instead of all three roon components (control, core, and output, aka remote, server, and bridge). This machine has limited free disk space.
I have no intention to ever run the server or bridge on this machine so they are not needed.
The full package package takes up 278mb, rather large for just a front end, so the full install takes up a lot of disk space, more than needed for just one of it’s three components
The limited disk space should be reserved for other uses and not be consumed unnecessarily.
It is bad practice to install unnecessary software from security and performance perspectives, as it simply creates more opportunity for problems.
It is possible that a user who is unfamiliar with Roon may open the app and select the option to run the server on the local machine instead of connecting to the configured remote server if it is temporarily unreachable. This will consume additional local space as the services allocate what they need. The user may wonder why there’s no music to play. Administrators may become unhappy.
I can see some benefits, but my thoughts are down to simplifying the architecture across all platforms to aid user understanding.
Having 3 separate installs, so user knows what does what and has choice.
Roon Server
Roon Bridge
Roon GUI
I don’t really feel that saving few MB of disk space carrying much wait with Roon … and I also foresee some cons; such as … making sure that all 3 are updated to the right versions for cross compatibility, but I’m sure that could be solvable.
I think what I would like to see is a Roon installation manager, a single small download that at runtime prompts the user what options they have / wish to install / wish to uninstall and then it pulls down and performs the installation (and manage compatibility etc.)
I see another issue for running just a remote where one tries to install on under spec hardware, not talking cpus here but graphics ability for open GL 3.0 support being the bigger issue likely to crop up.
Core doesn’t run much cpu when not running as a core (or at least it shouldn’t) and bridge is so light it’s really not an issue that I see being of any consequence.
That could be an issue, @wizardofoz, but OpenGL 3.0 was released in 2008. I don’t know how long it took for it to be widely supported by hardware vendors after release, but there probably aren’t too many PCs around that old. A laptop from back then would be more suitably used as a doorstop anyways.
I agree that saving disk space would not carry much weight with roonlabs because it’s probably not an issue for majority of customers who probably have recent hardware.
As for keeping the installs in sync, I presume you’re referring to keeping them in sync on the client hardware, not roonlabs updating them simultaneously for download? If so, roon is pretty good at keeping itself updated on client hardware, if not too good at it sometimes.
It is extremely common for an installer to give the user control over which of multiple components are to be installed from a single package. (At least on windows it is common.) roonlabs could follow this standard model. That would mean that the downloaded installer would be as large as presently, but bandwidth is no longer an issue even for old machines, so it’s just a matter of having enough temp disk space to hold the installer until the selected components are installed.
It’s worth noting that roonlabs already provides a separate installer for just the bridge for windows when only that functionality is required: why not do the same for for the remote?
Yes it was the forum was thinking of … to make sure that all the separate installs where on the same (or at least compatible) I don’t think it’s ok to just manage this from the server side on what’s available to download… some form of runtime checkin should be the order.
As I eluded to … It’s effort, but I can’t foresee any big stumbling blocks here.
We’ve debated releasing Roon Remote for Mac/Windows and make Roon Server a requirement.
Our reason for the all-in-one was two-fold (5 years ago):
most trialers need a core and remote, and an all-in-one install is the fastest way to get going
on older networks and machines, the all-in-one is faster than the remote/server because it uses memory instead of network. Remember, 5 years ago we still hardware to support from many years before that.
The first could be fixed by just having the installer include both packages. The second is not an issue nowadays.
I’d like to get this split done, but it’s not very important to the roadmap. The disk space + win8.1 reasons are not even on our radar for obvious reasons, but I think it’ll make our offering a bit more consistent if it was always the following 3 software packages in the installer:
Core
Remote
Bridge
So yah, it’s a good feature request even if we disagree on the reasons.
I let the roon client update itself on this old laptop I’ve been discussing, where I only want to have the client installed.
When I turned on this computer, a windows firewall warning came up, asking me whether or not to grant external network access to RAATserver. Why is this program/service even starting up and triggering this firewall exception request?
This is a problem. A program I don’t want installed on my computer is requesting access to the internet. This is another reason to allow for client-only installs on windows.
This is the network protocol for Roon. So, if you block the program, you will lose network access to your endpoints. As such, clients need RAAT running as well.
You’re saying a RAATserver process is required to run on a Windows pc to allow the roon Remote to talk to an actual server running roon Core. Wouldn’t the client use the RAAT protocol to talk to the service on another machine? I’m not sure this explanation is correct because I believe the RAATserver process stopped running after the firewall check.
How does this work on an android phone, for example? Is my phone client running the service too?
RAAT (Roon Advanced Audio Transport) is the backbone of Roon’s audio distribution technology (read the KB article to find out more about it if you wish).
It is not involved in the communication between a Roon Control (e.g. the Roon Control component running on your laptop) and the Core.
See this KB article for more information on Roon’s architecture of Core, Control and Output components.
So if you wish to play an album, and you choose to have the audio played on your laptop, the Core will use RAAT to send the stream over the network to the RAATserver on your laptop to play the audio on your laptop (or to an audio device that is attached to your laptop via e.g. USB or Bluetooth).
When you install the Roon software package on a Windows machine, then all three components are installed by default. Of course, if you never want to play audio on your laptop, then the RAATserver is not needed or used. It’s the same as for the Roon Core component - if your Core is elsewhere in your network, then you won’t be using the Roon Core on your laptop.
That’s exactly as I understand it. So on this laptop, which will only ever be used as a remote and not as an endpoint, RAATserver is not needed. I will not lose access to my endpoints (which are not on this laptop) without RAATserver running on the laptop.
