Various Bluesound devices and directly attached powered speakers to the iMAc
Number of Tracks in Library
20,000 Tracks
Description of Issue
I am accessing the Roon Api from a plugin running on the Indigo Home Automation system. It was working pefectly yesterday. However, after updating to Roon version 1.8 (Build 880) Stable, I am now getting a Connection refused error when I try and connect to the Roon core at 192.168.1.8 Port:9100 either from the plugin running on the same iMac or from my macMini on the same network.
I see reference in other posts to ports 9330-9332 and have tried those instead of 9100 with no success. I have also turned off the firewall to double check.
The port number is not (and was never) a fixed quantity, and Roon API extensions were never intended to hard-code it.
It has always been assigned out of a range, where we look for the first available port. 9100 was the first port in that range, so on many machines, Roon would use 9100, but there are many people who have been using 9101 or 9102, and quite a few users who ping-pong around based on the order that various software starts up.
We moved the port range because we became aware of several pieces of software that are inflexibly tied to 9100, and due to implementation errors in that software, they would sometimes result in conflicts.
For Roon API extensions, the correct approach is to use the discovery protocol to discover the Roon Core and the correct port, as exemplified in our SDKs, for example GitHub - RoonLabs/node-roon-api: Javascript Roon API .
So users must wrestle with finding which ports to open from time to time… without notice?
Like many, I spent much of this morning checking my system only to find that the ports changed.
Actually, still having problems with my Chromecast audio devices.
Wow
If this broke for you, it’s because the extension was relying on undocumented behavior. Whenever someone does something like this, they create risk of things breaking in the future. I’m sorry that it happened to you, but your quarrel should be with the extension author, not with us.
Any extension broken by this change was already broken for some users, since even before this change the port assignments were dynamic and not every user was using port 9100, as I explained above.
If we were making a change to the sanctioned method of discovering Roon Cores there would have been plenty of notice and a long period of backwards compatibility, but that’s not what happened here.
I don’t think I’m having an issue with a refused connection. I did immediately after the update but I reinstalled the core app on my NAS and restored the database from a backup. The restore appeared to progress normally but after I relauched the remote as prompted, I got this:
After that restore, there are 6472 files in the NAS’s Roon_Server folder and the audio folders are all where they should be but nothing shows up. According to Roon, my library’s empty and I can’t play a thing.
While tinkering around looking at implementing discovery, I “discovered” that the default port (on my setup) is 9300. So I changed the port number from 9100 to 9300 and voilà it works (after re-authorisation in Roon). So I have done a tempoarary work-around fix to my Indigo plugin while I investigate the best way to implement discovery in my plugin. Takes the immediate pressure off.
Changing the port number is very stupid in my opinion, they do not thing about people that have a dedicated display configuration that start a browser automatically at system boot in kiosk mode, like the one of mine!!
So you are telling me the port can change often??? Great!!!
I’ve not yet heard of any application that uses a random incoming port, or chances without any prior notification.
How do you manage your network security of you don’t know what the destination port is server-side?
I have several applications running and they ALL use fixed incoming ports.
