This is definitely an isolated case for Chromecasts. But as only Roon sees the duplicates it points to Roon as the issue here if you ask me and not the network or you would expect to see this behaviour in other apps that work with Chromexast. Roon has been known to do this with Airplay clients and has done it for me on my Naim Atom for Airplay when the Atom is rebooted. Roon would see two airplay endpoints but only one would actually work. Reboot Atom again another would appear. Rebooting core it resets to one. Others with Hegel saw multiples adding every tirne they powered amp off. To me this is Roon not working as it should, if all others apps.work as they should and no duplicates then Roon is the issue, yes it might have an issue with my network but that is a Roon issue and not mine and I should not have to change it for one application that has a hissy fit.
Thanks for the moral support, @CrystalGipsy
I know there are a lot of variables in network setups, etc, but as all of the duplicates also have identical IP addresses this certainly seems like something Roon should be able to handle (ie when a duplicate IP address is detected, ignore it).
Not above doing additional troubleshooting steps to narrow down the problem, so I’ll take a look at the terminal approach for finding duplicate announcements. There are multiple APs involved here as well, but it’s hard to imagine this happening that frequently for stationary devices.
As mentioned previously, I have exactly three CCA devices on the network and Roon is currently reporting a total of 18 of them after a little more than 24 hours.
As this is observed nowhere else, it’s difficult to avoid the conclusion that Roon is doing something screwy with device discovery here.
It sucks, because I really like the product otherwise, but this issue is extremely irritating and directly impacts usability not only for me, but for other members of my household.
Looking forward to @support following up here.
This may very well be the case if Roon is stupidly caching old service advertisements and adding new ones to the list. That’s why I suggested a further troubleshooting step – to see if the network advertises multiple concurrent entries for the same device or if Roon is adding-up devices. No one so far suggested someone changes anything on the network side of things.
Just to add: the other strange thing is that, even though 18 total CCA devices are detected in Settings > Audio, they are only duplicated a couple of times in the zone select menu (again without any intervention on my part).
So, sometimes a duplicate device is detected and Roon decides to add it to my list of configured zones, and other times it apparently decides not to.
I honestly don’t care about the list under Settings as long as only the devices I have manually configured actually show up in the zones menu.
Is there a way to turn on debug logging to see details about when these devices actually make their way into the zones menu?
OK, here’s what I did now.
-
Disabled pi-hole DNS service on my network.
-
Shut down Roon Core
-
Rebooted entire network (Unifi USG + 3 AP-Lite)
-
Restarted Roon Core
-
Reconfigured CCA devices with names that indicate I set them up manually as shown below. This is the entire list of “Roon tested” devices on the network from immediately following the reboot.
I also then had the desired list under the zones menu:
-
Started an dns-sd scan on an unrelated Windows PC. Initial result here:
-
Occasionally checked the Roon app for duplicate devices. Roughly 30 minutes later, one duplicate had appeared at 192.168.1.39 (this is the Garage CCA device):
Duplicate groups also began appearing at this time in the Roon app.
This seems to correspond with some activity in the DNS log:
I see a CCA device removed at 18:53, and then a nearly identical one added at 18:56, the only difference being the -8 vs. the -7 suffix on the instance name.
About 30 minutes later, and this activity continues:
And the duplicates are multiplying:
So, it looks like Roon is responding to these added CCA devices (as well as some groups). But again it’s ONLY the .37 (Office) and .39 (Garage) devices. I was going to say it might be possible these are switching bands, but the Office device is just ten feet away from an AP. Garage and Living Room are a bit farther away. If it was band switching, I’d expect the farther devices to exhibit this behavior, no?
This is interesting, I suppose, but not yet instructive. What do I do with this information, @BlackJack ?
First, it looks to me that indeed there is something going on in your network. As it is not mine and I can’t see similar behavior in my network I don’t know what is causing this (I did already speculate a bit in my post above) and therefore if it is expected behavior or something that could/should be fixed somehow. You may be able to figure out what’s going on when combining logs from different sources (WiFi AP, Router, …) if they are able to provide useful logs. Also the simple command from my previous post only monitors the service announcements. There is actually a payload (the mDNS information about the device {IP-Address, name, …}) not shown in this list. It’s hard to see which device is which just from the service advertisements. There are probably better tools out there to monitor mDNS but from lack of need I don’t know any.
But there are also remove (Rmv) announcements. So maybe Roon is not following all (Add and Rmv) announcements. But this is hard to tell – Roon’s current behavior might as well be the result of some sort of “keep the music playing” workaround. Is doubling only happening for devices currently playing music? Note: Usually Roon stops playback when it losses connection to a device (even if for a short time only). Also there seem to be much more Add than Rmv annoucements for some reason – this might also be what leads to the doubling (Rmv announcements may get lost during transition {sent over the old, no longer valid link and therefore being never received}?). Maybe a developer who implemented the protocol/GoogleCast support into Roon can shed some light on it. I have so far provided what I was able to come up with.
Well, this all got the gears turning and I think I’ve found the culprit.
In the Unifi controller, there is a setting for mdns repeating. It was previously on for something I was troubleshooting a few years ago
Turned it off an hour ago, no duplicates yet! I’ll update again in the morning
Interesting as that’s for allowing MDNs to go over vlans. Chromecast uses MDNs for discovery across networks and it should not be causing that behaviour. I have it on my Unifi network and never have had an issue with it when I had one Lan and now I have several vlans no issues. I would reach out to Unifi on that as it might be something else that’s reacting with it. That said if you only have one Lan it’s not something you need on. How are you aps set up?
Right, this wasn’t it anyway. The duplicates have all returned in force overnight.
My network is pretty simple: single LAN, no VLAN or guest network, and all three APs have wired backhaul.
I thought I had remembered installing a DNS repeating service on one of my servers, so I’ll look for that next. Barring that, I guess the next thing is to shut down all other network services and see what happens.
UPDATE: I had in fact been running a DNS reflector (https://www.avahi.org/) on my primary server. I have now disabled it. We’ll see how it goes!
Good luck, sounds like that might be the cause of it. Still odd that only Roons affected by it. Do you have any other apps like BubbleUPnP that can see Chromecasts and if they show double in there.
AFAIK other apps don’t track googlecast devices like Roon does because all the zone settings and so on are linked to (available) devices. Others apps just show you a list of (at that moment in time) available devices so you can select one to stream to; they just stream to the selected device and continue to do so until the stream ends or an error occurs. In case of an error they inform the user and may allow him to select (another) device to stream to, just presenting a list of (at that moment in time) available devices. This list may contain the same devices again, they may just have changed their IP-Address in the meantime for example (a possible reason why the stream broke previously). So I’m not sure that a comparison with other apps is really helpful as they don’t do the same thing.
But this is all speculation on basis of what I can see while using Roon or other apps. I don’t know how all these apps are actually programmed.
Agree completely that it’s strange that only Roon is impacted here.
Installed the BubbleUPNP app, and no duplicates appear there.
So far so good. Fingers crossed!
Not sure about that. If you haven’t added them no reason why it would be any different it’s just using same protocols to find them as other apps will I this case MDNs and TCP ports are used . It’s just a list until you have added them it’d not tracking anything. Be interesting if you power one off to see if they both disappear at same time or one hangs about.
I do think there is some oddities with Roon and Chromecasts though as in previous versions of Roon for no reason it stops seeing them and often they would drop off or just one would not show or would take an age to be discovered. This has happened mostly when there has been a core update and it’s done it several times after Roon update. Google Home and all other apps still see them perfectly fine and can cast and control them but Roon just wont.
Also as I said I have seen this behaviour with Airplay as did another user this was not resolved so I think this.maybe related to that. It maybe certain scenarios trigger it but it should not be happening.
Maybe but not in general or I should have the same issues with my three ChromeCast devices – but mine work flawless. Yes there was an aknowledged issue at some point but that one got fixed and I had no further issue since then. (CCU 4K over Ethernet to WiFi bridge {HDMI}, CCA over Ethernet to WiFi bridge {Optical} and CCA over WiFi {Analog})
It seems that only some users are affected without a clear root cause identified so far. Maybe that’s why it takes so long for Roon Labs to provide a fix (assuming it can be fixed in Roon at all).
First, let me say that your comments led me to a solution to this issue and for that I thank you. I spent the day listening to music instead of troubleshooting, and Roon’s discovery engine made that quite enjoyable.
The solution was disabling the DNS reflector I had enabled on my main server a couple years ago (and which I had also completely forgotten about until today). Sometimes I get a bit too big for my britches installing stuff.
However, a counterpoint: no other software I tested over the past six days had any problem whatsoever with my network configuration, including the DNS reflector. This is literally the first time I have ever even noticed it was there.
Roon is outstanding software, but all software has bugs. Frequently, those bugs only manifest themselves in unusual edge cases. I freely acknowledge that my use of a DNS reflector represents such an edge case, but the fact that no other software I tested in the past six days (and in fact over the past few years) so much as sneezed at this indicates that Roon is handling Chromecast discovery in a suboptimal way.
Your thoughts is this thread ultimately led me to a solution, and I am very thankful and pleased with the result. Thank you so much for sharing your expertise.
However, your comments regarding the issue at times bordered on apologism. Yes, I had an unusual situation that ultimately caused this problem for me. The fact that Roon is literally the only software that misbehaved in this environment does, to me, indicate some deficiency specific to Chromecast discovery in Roon.
Reporting faults, even in software we love… no, PARTICULARLY in software we love, is how that software gets even better.
Thanks again for your help. I’m truly grateful. I look forward to enjoying Roon for many years, and I hope you do as well.
I^m happy to hear that your problem is solved now.
I like Roon and I surely like Roon to be as robust and error free as possible, but networks and the many standards that make up their functionality are a complex subject. This is the first thread I read about that thematic that came up with a clear cause and a solution for the affected user. Maybe the Roon team is able to use that information to setup a test environment in which they can reproduce the issue and make Roon more robust regarding this.
PS: There is always a “first/only”. I spent a lot of time on support forums from network hard- and software companies while I was solving my own bucket of network related issues. They are full of people having issues with only this or that peace of software (“My networks is stable otherwise”, “No issues with the network but …”). Just to hopefully figure out how they miss-configured their network and possibly what exactly went wrong as a consequence of that. Not every software uses all network protocols and even two that use the same ones may use it differently and in the end only one may exhibit erratic/unexpected behavior. But often the root cause is and remains the miss-configured network, until corrected, and not the software that can’t cope (well) with the consequences thereof.
I’m so glad you were able to get to the bottom of this, @Chad_Dybdahl! Great troubleshooting efforts from all involved, thank you!
I’ve passed a ticket to our QA team on this so we can hopefully prevent any issues like this in the future for folks in similar situations.
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.