it worked for me too! Thanks!
I use basically the same setup - Ubiquiti Edge / AmpliFi HD-GE mesh / Ubiquiti and D-Link Gb wired infrastructure and for the first 11 days of my trial, most things worked, including the household Android Pixel 3A phones. FYI weāre running latest Android OS/patches, Core is on a Windows 10 (1903) PC with Ryzen 7 3700X and 64GB of DDR4 fast RAM (huge overkill)
On day 11 of trial, NO Android devices can find the Core at all. App un/re-install, etc. are of no help. Not looking good for me to transition to a paying customer in 3 daysā¦ We use our phones more than PCs, etc. to control music across our devices and this looks seriously bad when attempting to sell the wife on it.
I spent several decades in IT at all levels of expertise and from my perspective, Roon is not yet predictable enough to be family friendly, unless the family/users all like shooting obscure and sometimes unsolvable bugs (I used to but not anymore; I just want my sāt to work now.)
To reflect on someone elseās posts here, we also have a lot of Sonos gear throughout the house and that stuff just works 99% of the time with no issue. So far, my experience with Roon is far from that.
Just my $0.02 on that.
For now, Iād really like to know what, if anything I can do to get my Android phones to find the Core again. Iāve seen a couple of mentions of a 255.255 workaround (Iām assuming a subnet mask setting somewhere (where/what menu?)) but no indication of exactly what that workaround actually is. And from what it sounds like, itās not permanent and requires babysitting and the expectation of abnormally & frustratingly long wait times for connection and/or interface response time(?)
Can someone enlighten me as to what the 255.255 workaround is, please?
Cheers all!
C
1 Like
Never needed to use the hack myself, but apparently itās to enter 255.255.255.255 as Roon core address on the Android client. Donāt ask me why that works 
Thanks for the response!
I just found a post that finally says what to actually doā¦ It seems one has to WAIT for the search to basically expire and then click on āNeed helpā to access the screen in which an IP address field is displayed and then enter 255.255.255.255 for the Roon Coreās IP address.
-
You probably already knew that @Fernando_Pereira but I wanted to put it out here so at least it shows up in a couple places for anyone else like me having a time finding the specificsā¦
-
Yeah - thatās bizarre at best. Letās just enter an arguably invalid IP address at the extreme end of the range (and an address often reserved for subnet mask, .254/.1 notwithstanding) to hack it into finding the Coreā¦ huh?? and wowā¦ Eyebrows raised but OK.
I have already restarted the Core but next time it happens, Iāll give the 255 hack a shot to see how long it sticks.
Android is such a fickle platform to begin withā¦ I hope Roon Labs listens to the OP who mentioned a tech shift to using mDNS as that is a more stable approach and lightens Roonās load from a dev perspective in the long run (after obvious up-front investment.)
It is not an invalid IP, it has specific meaning as a special broadcast address. If you care, do some googling and read up.
mDNS uses IP multicastā¦
@Rugby Thus the āarguablyāā¦ Iām quite familiar with the IP4 address range. Just as I said, the 255.255.255 extremes are generally used as a subnet mask and rarely as an IP address in a DHCP pool or as a static. Plus, my main point was that itās highly unlikely that the actual IP address of the Core is ā¦255. Mine certainly isnāt, which means putting ā¦255 in the field to find it equates to entering an invalid IP address for the device itself, if that makes sense. (hope so anyway)
Thanks for the reply though. 
@Fernando_Pereira, and Roon is multicast heavy but seems to rely on their own homegrown code to handle it where mDNS is a more ubiquitous tool to get the job done.
However they handle it, restarting Roon or rebooting the Core on a regular basis or every time the Android client goes belly up in its search for the Core is not a tenable solution/option. At least not for meā¦
Cheers yāall!
But the issue is not host name lookup, which is the purpose of mDNS. Itās the fact that some IGMP implementations decide to shut down routes to some hosts some time after a multicast, while Roon seems to expect to be able to use multicast relatively frequently to reestablish its internal map of whatās what where. As I mentioned before, I spent nontrivial time several years ago trying to help Roon engineers to track down this problem on my home network. Even tons of packet traces could not fully pin it down. Weeks later, turning off IGMP snooping on the Netgear managed switch I had then in the middle of my home network solved the problem for good. Iāve commented on other threads that if I were in charge (Iām not, and I donāt have the full technical picture or economics), Iād add a backoff mechanism to keep the Roon network map without IP multicast. Basically, a client that was once connected to a core re-awakes and fails to find the core in the usual way, it would talk to a separate TCP/IP listener on the core to establish a āhardā connection. But then Iāve not written any sockets code in the last several decadesā¦
@Fernando_Pereira - Copy that. Me either on the sockets codeā¦ Hell, I havenāt really written any useful code in well over 10 years and most of my coding career that was āclose to metalā was not around network protocols/layers/comms as much as systems code. - Iād probably get myself and several others in trouble if I even tried these days. LOL
I know itās kinda unrelated technically but do you think going to an all static IP strategy would help? Or does the client use more of a stateless approach such that any loss of contact results in a rescan / lookup? Just wondering if I just went old school and assigned all devices a static address (or mapped them as static leases at the DHCP server) if that would also be a workaround.
Iām pretty sure I have IGMP snoop turned off on my network but will definitely have to verify. Come to think of it, I may not since I suffered the Android client issue earlier today - which is how I got here in the first place. Hmmmā¦
I think I had static IP assignments when I was having this issue several years ago.
1 Like
I used to have issues with Android when I had used just my Netgear Nighthawk, used to get stuck at initialising all the time. As soon as I switched to using one Unifi AP at that time it worked every time and had no issues since. I later moved to a Unifi router and another one of their Aps upstairs. Still no issues. I did have Cisco 2960 switches in until I went full Unifi a month or so ago. Now I have issues with Chromecast discovery in Roon with IGMP on it sees them once then next time you power up nothing , it may appear randomly after a while. It worked fine with the Ciscoās itās infuriating as they say to have IGMP on for Chromecasts. Google home works just not Roon.
For what this is worth, when I moved from Roon Core on Windows 10 desktop to Rock in Virtual Box on same PC, I had no further problems connecting to Roon Core from Android phones.
Before my iPhone was always catching fast the Roon Core whilst the Android phones would mostly struggle or not find it at all or find it only after a Roon Core restart and working for a while.
Actually Norisā¦ I don;t think your update fixed anything at all. Maybe just luckā¦ I am getting this every day now and itās so frustrating. Especially when I bought a Nucleus which is almost invisible on my network.
I bought the Nucleus a few months ago, and the performance with Android is just as bad - and the IOS apps are not much better. Actually starting to get really frustrated. Roon seem to think they have something superior going on with their techā¦ but it doesnāt work and you need a degree in computers and home networking to understand it.
Whilst playing and trying to get my Android phone to workā¦ the 255.255.255.255 trick works. Whilst the Android was trying to connect it also locked out two ipads which were initialising but failed to connectā¦ as soon as I put the 255 IP in, they connected straight away. So maybe the Android app was locking out or blocking other connections?
Interestingly enough, I suffered an issue (I think mentioned by another person somewhere in this thread but perhaps a sibling/related one) where I was not presented with the IP field on the āneed helpā screen. It actually opened a browser and took me to the general support page. This was on a Pixel 3A running the most current generally available Android OS. If I attempted to just let the āsearchingā process expire, it never did even after like 20-25 minutes - just kept spinning/searching. When I went into config and entered 255ā¦255, that didnāt work either.
Anyone else experience this inconsistency?
To resolve it, I walked to the Roon Core PC and closed/restarted the Roon app. Obviously, not a glamorous or really even acceptable solution, long termā¦
Iāve also had to reboot said PC once or twice due to a lockup (at least it appeared locked up as nothing would break the screenās sleep mode) and had to do a forceful cold boot. I canāt identify the source of that issue, so Iām not gonna arbitrarily point to Roon (the only app running but still couldāve been an separate/unrelated Windows issue.)
Anyway, itās the inconsistency here that troubles me.
Five days ago i have updated my Motorola G (only used as Remote) to Android 10 (before 9).
The core is an spezialized Mini-PC with Win 10-64.
Now the Smartphone can`t find the core when i start the Mini-PC at first and the Phone as second. Started the phone at first it works fine.
Not really a great problem but i`m wonderingā¦
Amazing i did this and it instantly found the core - weird!
It seems to force unrestricted IP multicast discovery on your subnet, bypassing whatever IGMP weirdness was preventing discovery before. Ugly for sure, Roon developers are well aware of the issue that this is kind of a workaround for, their key difficulty is that itās hard to replicate in their lab. Surprising as it might seem, home IP networking is a terrible mess that only seems to work until any device tries to use a slightly more advanced protocol option. Network stack bugs abound, WiFi is often flaky (now that so many are doing video calls from home thatās become a lot more apparent), and so onā¦