Android can't find Roon Core

Thankyou! This fixed my issues with my android devices. I had sent a ticket to support and this solution was not suggested. I wish I had seen this thread prior to installing and reinstalling roon multiple times and even trying to run mock on an old PC. Never an issue with my Apple devices always an issue with my android devices.

Coming from the Sonos environment which was plug-and-play and worked flawlessly, roon is clearly not yet ready for primetime. I think most of us who are using roon are fairly “techy” and feel the better sound quality/music storage are worth the effort. The majority of people though simply want to turn on the music and not waste time trying to get the music to work. The sound quality difference for most people is as well negligible. They really need to work on emulating the Sonos experience, which is essentially invisibility whereby the tech simply works and never interferes with enjoying the music.

From what I read there are just as many issues with Sonos and networking to especially subnets, all systems that rely on multicasts for discovery do to some degree it’s not unique to Roon I see it on other forums a lot including network hardware.

Roons discovery does need to improve and allow subnets though this is a given in today’s security paranoia. But most of multicast routing issues are down to bad implementation in network gear. IGMP should really be on for everything, you don’t want multicast packets being sent to every device on your network but this is done badly on most cheap domestic kitm These cheaper home gear are not made properly for multicast usage and the Mesh stuff like Google is is just ■■■■ with its constant double nat issues.

Respectfully I would have to disagree. I’m not sure if you’ve used Sonos, if so I would be surprised if you were to have as many issues as I have found running roon. I have used a Sonos based system for approximately 8 years, 5 devices in total. A mix and match of multiple devices to control… and very rarely if ever an issue. My wife and kids still use Sonos exclusively in our house, roon has not been stable enough for me to suggest they use it as of yet.

I don’t mind being tech support for the family, and have recently purchased an audio system that justifies the better sound quality roon/ tidal provide. However, most of my friends and family would not be willing to fuss with roon once it began causing issues. I have already sent three tickets to roon support in 3 weeks, and zero to Sonos support in 8 years.

Once they get to Sonos level of stability, with their advantages insound quality, library archiving, 3rd party device support, etc then I think they will become a more mainstream product. Until then I think it will continue to moreso attract people that post on forums at 1 in the morning :grin:

Same here, with Roon Core on Windows 10 PC and multiples remotes. The Android remotes take ages or don’t find the Core whilst ios remotes are immediatly connecting.

My way around is to restart the Core every day. Not acceptable.

Roon is obviously more to be run on a Linux system (Roon hardware development bias) and controled with ios devices (US bias).

I have experienced first hand very poor support from Roon for Windows based issues also.

Roon is definitely not a mainstream consumer product. Not robust enough.

I would be surprised also if current Roon customers base would not be 80% US. This would be another bias.

On the one hand, multicast discovery should work on a non-buggy network. That’s what Roon assumes. But unfortunately, some routers, WiFi access points, and switches have bugs that may not visible to other applications but trip up Roon. A possible compromise would be for Roon to fall back to a partially manual discovery that does not use multicast. The fallback might also make it possible to use subnets.

On the other hand, a well-built home network works beautifully with Roon. I use Ubiquiti EdgeRouter, Ubiquiti AmpliFi WiFi with 2 wireless mesh points and wired backhaul to a secondary AP, all wired together with Actiontec MoCA transceivers over coax, and a few Netgear dumb switches to connect various gadgets. Roon Core on a Linux (Ubuntu Server) NUC, Ropieee, Linn, and Chord 2go endpoints, and macOS, iOS, and Android control points. It all just works.

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 :confused:

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.

  1. 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…

  2. 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. :slight_smile:

@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?