ROCK - wired in Netgear GS108e
NAS units wired into same switch
Edimax WAP1750 POE WAP, wired into same switch
Cisco RV340 Router provides NAT & Firewall
ISP modem in “Modem only Mode”
Connected Audio Devices
SonoreUPnP Bridge running on UltraRendu - wired
UltraRendu with USB → S/PDIF - wired
2 Chromecast Audio devices (permanently on) - WiFi
2 “Chromecast support” powered WiFi speakers (powered on, as required in Bathrooms)
The above Chromecast devices operate in a single Chromecast Group, “Bath & Bedrooms”
Chromecast - picture only as Roon display - WiFi
Number of Tracks in Library
97k tracks, 7k albums
Description of Issue
So after about 48hrs Roon loses connectivity with all WiFi connected Chromecast Audio based Endpoints
Checking in the WAP they are all still connected
A reboot of the WAP and they return
A reboot of the CISCO router (without rebooting WAP) and they return
Restarting/Rebooting the Core has no effect.
All existed for last 12months and were stable and always present in Roon and available for playback.
All networking software running its latest firmware builds
So why are they suddenly losing their offered presence to Roon?
And forcing a disconnection/reconnection of each by either Router or WAP reboots gets them to reappear in Roon as endpoints again.
Most-likely because something happens in your network after 48 hours.
This seems to demonstrate that, whatever it is, it is unlikely to be related to your ROCK machine.
Are your DHCP leases running out after 48 hours (2880 seconds) possibly? Can you see something happening at the time of loss in the logs of the WAP or the router?
DHCP renewal is business as usual for a router so why might this suddenly be causing issues? And in any case, devices should just reconnect not go offline. Are they still on the network with an IP address but ROCK cannot see them? Use FING or similar to check. Is this a Chromecast rather than a wifi issue?
So why should there be an issue at all? Clearly something has changed in the original poster’s network if the issue just started happening recently. So without him telling us what this change was, we have to make guesses and ask questions - or just leave it to himself to figure out.
If the lease expires, the client must immediately discontinue its use of the current IP address. The DHCP client then begins the DHCP lease discovery process in an attempt to lease a new IP address. If the DHCP client fails to receive an address, the client will assign itself an address by using automatic IP address assignment in the 169.254.0.0 range.
The devices have actually been set as Static DHCP entries in my Router, against their MAC addresses, to prevent any potentially DHCP issues within my ‘Infrastructure’ of known networking devices.
Sorry - yes let me qualify this for the Networking equipment in the chain
The Edimax WAP1750 is running latest firmware released since 2021/09/10
The Cisco RV340 Router is running latest firmware released 2022-Jan-30
Roon Core 1.8 R898 was released 31st Jan 2022
The Chromecast Audio devices are running 1.56.281627 - December 2021
Netgear GS108e and GS105 - firmware on these hasn’t changed in years.
Your ROCK is wired too, so can’t be him by your logic.
So more or less the same day it seems.
So possibly just the last then from two in a very small time frame.
As for the missing ChromeCast devices, Roon just reads the mDNS-SD announcements to find ChromCast devices in your network. These announcements have to be published by your ChromeCast device and propagated by your WAP and router for your wired ROCK to see them. You stated that a restart of the ROCK doesn’t bring them back, this tells me that there weren’t any announcements to be found (update) or depending on how Roon is going forward when detecting announcements, the ROCK was unable to establish a connection to the devices using their published address. I would definitely try and read through the logs of the router and WAP to see if something unusual turns up there.
What would prevent the mDNS-SD announcements from either not being broadcast over the network from the Chromecast Audio devices (the Chromecast device continues to be listed)? Or stops them being read.
In terms of Firmware on the Router - I can reboot it using the previous Firmware image, but I would imagine its handling of any mDNS-SD announcements is binary - they are either passed through or not, and not passed for a couple of days then not.
Is there any other way to determine if the mDNS-SD announcements from the Chromecast Audio devices are being made, outside of Roon? What other client will look for them - Tidal Connect?
Any setting that might trouble multicast traffic. There might be related settings in the section for routing, for the integrated switch as well as for the firewall of the RV340.
The switch (I mean the switch built in your router) might use a technique called IGMP snooping as well as multicast flood control to limit traffic to specific ports. There is also wireless multicast forwarding (WMF) as Cisco calls it (it may be named differently by other brands), that controls how multicast is handled over WiFi.
I don’t know why things stop working for you after some time, but I suspect that some fundamental change happens in your network at that time when things stop working. Maybe things would recover after some time. I suspect that as you are the person with the issue, it’s upon you to undertake some serious troubleshooting.
Form a command line one could use dns-sd -B _googlecast._tcp to browse for announced GoogleCast services (hit control + c to stop browsing) - but I don’t know if the command is available to you.
This can help you in troubleshooting. If all works as before with the old firmware you would know for sure that the router is to blame. If not, looks like there were a lot of changes in that last update, default settings may have changed, new settings were possibly added and some maybe even deleted. As I don’t know the router you use, I don’t know how well things will work out when you downgrade the firmware (your issue might survive the downgrade as part of the changed configuration).
If I were in your shoes, I would definitely try and contact Cisco customer support. Not only do they know your router, they should also know networks and troubleshooting network issues better than you and me.
Correct me if I’m wrong but based on this timing the change to your router firmware happened more or less coincidentally with the Roon core update, right? Sure, Roon was likely the last thing changed, but the dates you present put the router change well within the 48 hour window in which this problem manifests.
I’m with @BlackJack on this one as this is clearly an issue with the underlying network infrastructure. If I were to guess as to the root cause I’d say that something in that very recent update to your router is related to multicast behavior and that has caused a conflict with either your “smart” switch or your WAP. Hard to tell which at this point, but it’s quite common for WAPs to selectively block multicast traffic at periodic intervals in order to cut down on wireless broadcasts. If multicast is blocked then device discovery breaks and things like Roon endpoints and chromecast devices seem to disappear from the network.
I will say that running more advanced network gear from 3 different manufacturers can be a recipe for disaster. An innocuous change on one can very easily awaken a demon in another and then all hell breaks loose. I lived this nightmare quite often for many years with customers insisting on using Sonos with Cisco managed switches and Ubiquiti WAPs. Everything would work fine… until it didn’t.
I had discovery issues mixing Ubiquiti WAPs with Netgear managed switches. I have two different locations now, and the most trouble-free is all from a single manufacturer (Ubiquiti).
So rebooting the Cisco RV340 against the previous Firmware version, as Chromecast Audio devices had been dropped from available endpoints by Roon.
Rebooting Edimax WAP1750 also.
So now the only changed element in the system, from something working reliably for several years is the Roon 1.8 B898, the software consuming the availability of the Chromecast Audio devices.
And if over the next 48hrs, if they are dropped as available endpoints, what then?
Others have also posted about loosing Chromecast devices with core updates. Happened to me quite a few times. When mine went it’s always related to a Roon core update. It’s happend more times than I can remember. During these periods nothing changed in my network setup at all.
Google home and all other devices that can Chromecast could see and use these Chromecasts yet Roon would not detect them. I only got them back by restarting all my network gear then restarting Rock. So I do believe their is something at odds here that causes this and it’s Roon specific.
As a side note since I moved all my Chromecasts to thier own subnet which is what is recommended by my manufacturer for them this has not happened again and Roon has no issues discovering them.
Hi, Thanks for that and a different perspective from what I have gotten so far, in terms of Support, where the entire emphasis is on a local network issue and a potential change in how the Discovery is undertaken and presented to Roon.
I have now rolled back a Router Firmware upgrade which was applied at the same time as 1.8 Build 898, so will see what happens (as it had been all working for a couple of years, since I replaced an original RPi running Squeezelite with a Chromecast Audio, and then got another one, as I was impressed with them, for the usage application I needed them for).
If the issue continues, may have to investigate the subnet option for them.
So Roon is now displaying 2 Chromecast Groups using the same device details, i.e. the same IP address of one of the Chromecast Audio devices in the Chromecast Group.
It may have displayed the same Chromecast Group but associated with different devices, i.e. using different IP addresses of the different devices in the Chromecast Gorup.
Was there any change made to the handling of Chromecast devices in B898?
