I imagine the main sticking point is your local music library, because outside of that, everything can be stored remotely on your servers. But regardless of technical details, I agree when I’m away, I’d like my phone (or laptop) to work as my Roon Core.
In my case (as feedback to your team), I buy phones with extra storage so my entire music library always travels with me, also on my laptop. So if all my settings/playlists were in say a Roon Cloud, all my files are there.
And yes the Roon Audeze presets, and your focus on music fidelity and out of the box support for high end gear like Chord, means I’d be willing to pay extra for a Roon Cloud where I can upload my 250GB library and access it anywhere.
My solution for now is to move my Core from my Mac mini to my laptop. I installed Amphetamine to prevent it from sleeping when my Macbook Pro locks the screen.
Clients discover the server for browsing and controlling the server which is normal. Client server as you know it.
But where Roon is different is that the server discovers endpoints on the network that are capable of playback. This is the limiting factor that complicated things for remote playback as it stands right now.
I’m not sure what the problem is with remotely showing your devices at home. Sure you’re unlikely to start playing them when you’re not at home but that shouldn’t stop this from functioning remotely. It’s certainly easy enough for the Roon Core to tell if the client is on a different network and perhaps grey out those devices that aren’t available.
What does a static IP address have to do with anything?
You are guessing on how it should work. Discovery happens from your server inside your network and it finds the advertised playback devices. This discovery cannot traverse outside your private network or even outside the subnet for that matter.
You’re assuming discovery needs to happen in the first place. Discovery from client and server is only necessary if you don’t want the client to have static information about your server configured (such as IP address and port number). If you have those things, what else is there to discover?
Roon is very complex software, so maybe it does need to discover other things, but as far as client talking to server, IP address and port number is all you need, and those can be easily port forwarded on your firewall.
The static IP address is helpful from an outside network, since most home internet providers give you a DHCP address that can change any time, though in practice that address is often static for long periods of time. It wouldn’t be hard for me to find out my latest IP address from outside the network anyway.
Heck Roon on my phone itself will ask me for an IP address if it has trouble discovering the server on my network. I’ve had to do this a couple of times already.
Browsing is one thing, the bigger issue is playback outside your local network’s subnet.
I was just trying to help you understand why having a public ip address (static or dynamic) and open ports won’t work with playback as Roon is implemented right now. Heck even a VPN solution won’t work unless it’s a layer 2 bridge VPN.
All that said, I’m quite certain they won’t ever make it as simple as a public ip address and port forwarding. Doing so allows a person to easily share their Roon environment with many others license free.
Firstly, I really shouldn’t be contributing here - I am very computer illiterate and have no idea what a static IP address is…or pretty much any other of the technical stuff above. But I did manage to get ROON working to an acceptable level in my office using Google remote desktop.
When the lock down started I installed Google remote desk top on my PC at work and my PC at home so that I could work from home.
When we were allowed back in the office I logged into my home PC from the office PC and fired up ROON on my home PC. I set my home PC as the end point and voila music came out of my setup at work (PC to DragonFly Red to ARCAM power amp to homemade speakers.) It works fine other than the limitation of my WiFi at home - I live out in the country and WiFi is via a satellite dish and can be a bit temperamental. When the WiFi is playing nice then ROON works fine on the office PC.
Do you know the technical detail why Roon couldn’t play music from an outside network? I imagine it’s mostly they don’t want to support the headache of tickets of customers complaining about slow connections. Or, if Roon Core needs to “discover” its clients (even after you’ve established a connection already)… Given how often I see Roon client pause and reconnect to its server, even in the same room with super fast WiFi, maybe there’s something there.
I imagine though the big conversation is for them to implement Roon Cloud: upload your library for a fee per GB (with some bulk storage plans), and the rest is easy because it’s just as easy to stream Tidal from your phone anywhere as it is inside your home. But this requires uploading your library to them, because the hassle of different local music libraries at home and on your portable devices is a nightmare.
I see technical details on getting a VPN to work while still using discovery, which goes back to point #1: If you have an IP address and port, why can’t you skip discovery and connect to the server? This type of port forwarding goes back decades, I’ve set it up many times for ssh and other services on my home network.
The server only lists endpoints for playback if it can discover them via broadcast messages on the local network. I can only repeat this so many times.
I know. I can only repeat so many times that discovery isn’t necessary, because I’m talking about what might easily be done, not what currently is.
A new, useful response might be something like “well the server can’t efficiently stream back to the client on the same network connection so it needs to establish a second connection from server to client and that’s hard to do on a separate network”, not parroting “Roon needs discovery because Roon needs discovery” ad infinitum.
You asked why and I explained how it works and why simple port forwarding wouldn’t work.
You seem to have take offence and now are proceeding to tell Roon Engineers how their complex multi OS and hardware based playback endpoints could easily work with just port forwarding because you have set up port forwarding on your router with other software.
I think you might want to take a step back and consider the Roon eco system has many different playback endpoints that have the ability to be zoned and sync playback perfectly across devices in a zone. These endpoints may or may not even have a user interface.
The communication means used to achieve the above isn’t easily implemented on the high packet loss and high latency internet using standard internet streaming protocols.
I think maybe we’re talking about slightly different things. You are explaining discovery for various endpoints, but that has nothing to do with connecting my phone to a Roon Core remotely.
I agree that for the wide variety of playback devices Roon supports, discovery makes a lot of sense, and external network configuration would be extremely difficult.
But I’m just asking about connecting a single client to play music on that device. The rest of the ecosystem has nothing to do with my phone getting music from Roon Core. The rest of the discovery for devices on my network isn’t relevant to this, because I’m physically not there. I’m not going to ask Roon to play my home headphones, or speakers, or on the TV, or anything on my local network, when I’m away from home.
So… We’re essentially talking a single client to a single server. I don’t see how the rest of the complex ecosystem Roon has to manage at home impacts wanting to play my library through my phone. Not my phone plus other speakers at home; literally just my one little client. Roon doesn’t have to worry about latency issues syncing playback across multiple devices; it only has the one device to worry about.
Currently your phone is discovered as an endpoint by the server using the exact same means as every other endpoint. It doesn’t register as a player with the server. It also uses the same complex audio protocol that allows synced zones.
Roon is very consistent in this way. To this point they have had no interest in implementing and maintaining a lesser one off protocol that would work for single streams over the internet.
As well I mentioned before a simple port forward implementation would easily open up Roon to all my friends at no cost.