I’m having an issue with Roon Core and Chromecast Audio discovery. Looking at Roon logs and network captures, I can see that Roon Core is making mDNS discovery requests and getting responses back, but somehow Roon ends up using the IP address of the mDNS proxy instead of the IP address of the CCA device or group, and because of this, Roon discovery of the CCA fails. The Roon logs look like this:
Error: [cast/client] [Chromecast-Audio-65bcb2c39fa08010cd24db65fb28d555-1._googlecast._tcp.local] Failed connect to 192.168.1.1 port 8009
Error: [cast/client] [Google-Cast-Group-7145B8DBE86F49C7880129BCEE4E802C-1._googlecast._tcp.local] Failed connect to 192.168.1.1 port 42683
What I have already investigated:
Rebooted everything on the network. No change to behavior.
Chrome browser on the Roon Core correctly detects and can cast to CCA devices and CCA groups.
VLC on the Roon Core sees and can cast to the CCA devices but does not see the CCA groups.
dns-sd and zeroconfServiceBrowser both see the same mDNS records for the CCA devices and groups.
The fact that Roon is grabbing the address of the mDNS proxy instead of the CCA’s address seems strange to me. I’m not willing to rule out some sort of configuration or user error, but is it possible that Roon is mishandling discovery in this case? Earlier threads ‘Use Airplay device (Apple TV) in different IP subnet (for example over VPN)’ and ‘Remote control from another LAN’ have reports of similar behavior, but no resolution.
Environment:
pfSense firewall/router & avahi, IGMP proxy (192.168.1.1)
Ubiquiti switches & APs (192.168.1.xx)
Roon Core - NUC, Windows 10 (192.168.1.73)
4 CCA devices (192.168.20.30 - 192.168.20.33)
2 CCA groups, each with 2 member devices
All the devices Roon needs to see must be on the same subnet. Your cca devices are on a different subnet thus this could be the issue. They should be on the 192.168.1.xx subnet
I understand the official position regarding subnets. Not supported does not always mean impossible, it can also mean that you won’t get much official support if you want to use Roon in an unsupported way.
Chromecast is a bit tricky to get working in a multiple subnet environment, but it is possible to do.
The CCA devices themselves are working across multiple subnets in practice and confirmed using tests recommended by Roon for troubleshooting. I believe Roon Core is seeing them, but somehow ends up using the IP address of the mDNS proxy instead of the CCA IP address to connect which causes discovery to fail. From the outside looking in, this looks like a bug in Roon Core, but it could just as easily have an internal explanation that points back to configuration or user error.
My reason for posting is the hope that Roon would value improving their discovery process and investigate this, even though my specific configuration is officially unsupported at this time.
At best this is likely to end up the Feature request but most likely the tinkering area. Likewise has been the ability to work over VPN etc.
Roon has some basic networking requirements that have been stated (all devices must be on one subnet) and this is where it will stand for the foreseeable future as it’s been noted the past.
Roon requires that your devices be on the same subnet in order to properly work. Since this appears to be “working as designed” I would recommend also posting your suggestion in the 'feature request" section of the site.
Our product team and developers keep a close eye on that category, so that’s definitely the best place to propose a change like this and get feedback from the Community.
In this thread from 2016, @danny indicates that there was an issue with Roon Core and that it was going to be fixed in the next public build. Can you confirm for me that the fix described in this earlier thread was actually made and publicly released?
Apologies for the delay here. I brought this to our meeting with the development team to get their feedback. The development team is going to do some additional investigation into this issue. I’ll be sure to update you once I’ve received more information from the team.
@Greg_Miller We have a fix for a bug with resolving proxied mDNS queries that will fix discovery and allow for our Chromecast (and Airplay) integration to work across subnets, provided that your proxy, firewall, and switches are configured properly. What that means is highly dependent on the specifics of your equipment and environment.
It will probably end up in the next public release, but I don’t have an ETA on when that will be.
I wanted to touch base with some good news and let you know that we’ve made some changes in Roon version 1.6 which should address this issue. Please update to the latest Roon Build and let me know how it goes!
Happy to report that Roon 1.6 is working well with Chromecast Audio on different subnets and different vlans. Great work! Thanks to you and the team for making this happen!
Two things of note:
It took a few hours for the CCA devices to be fully discovered and usable. During this time, some of the endpoints were discovered, but they would not play. I doubt this is entirely a Roon issue, but it still may be of interest, as my Chrome browser was able to use the same endpoints almost right away.
Roon is showing multiple entries for some CCA endpoints. See the attached screenshot. The only pattern I’ve been able to figure out is that if a CCA device is part of a group, the device seems to show up multiple times in the settings list, but I haven’t spent much time on troubleshooting and it’s easy to workaround.
I would try rebooting your Core + Network to see if that helps with the duplicating chromecast issue. This behavior is a bit unexpected so if rebooting does not resolve it let me know as I’d like to look into this further.
This was definitely not the case in our own testing of this functionality. If they show up in Roon but there are issues actually playing, it sounds like there may be networking issues impeding communications between Roon and your Chromecast devices. Like I said when I stated that we were going to fix this issue, discovery and playback will work, but only if everything is configured properly. Here are some tips:
Your firewall rules must allow traffic originating from your Roon core to reach the Chromecast devices and vice versa. This is not the case with most other Chromecast applications. Your Chromecast devices must also be able to reach the internet at large, but this is the case with any Chromecast application.
You might have to update your AP firmware. In my own testing of this feature, I discovered a long-standing Ubiquiti AP firmware bug that broke some types of inter-VLAN communications and wasn’t fixed in non-beta firmware until very recently (ie: the last month or so).
Depending on your firewall settings, your NAT rules may also be inadvertently catching inter-VLAN traffic, which may break our Chromecast support if any IPs or source ports are being rewritten/translated. The default-ish NAT rules in pfSense definitely seem to do some version of this to inter-VLAN traffic. I had to add “NO NAT” rules like this to make things work properly:
The 1.6 release contained a fix to a definite bug in our mDNS discovery code which should allow for inter-VLAN Chromecast and Airplay playback, but if you have a network like this at home, you’re mostly on your own when it comes to fixing your own Very Complicated Network. You definitely do not have an officially supported configuration that our support staff can help you with.
The way Chromecast grouping works, one of the devices in the group advertises the group as a different (virtual) Chromecast device that shares an IP with the real device. Are you sure you’re not just seeing the virtual devices for the groups you’ve created?
