Remote on Android can't find ROCK

Hi @Just_Me,

Have you tried disabling the WiFi on either the router or the access point as a test?

Ideally we should simplify the setup to ensure that this issue is not due to one specific aspect of the chain (or the Android app switching between the router/access point).

I would also try a reinstall of the Roon app on the problematic Android devices if you haven’t done so yet.


  1. Remotes are always connected to the main router/AP - so that’s not it

  2. Why would this only affect the android devices? And only the Roon app on those devices? - possible but unlikely

  3. On BOTH? The definition of insanity is doing the same things twice and expecting a different result. :slight_smile:

If it were the issue, I have real problems with any technology that cannot deal with a modern, multi cell network.

And remember, this behaviour pre-dated the 2nd access point.


Android devices are more sensitive to properly working multicast from what I’ve seen.

So what you’re saying here is that this has occurred with the FIOS router and the Roon Remotes have only been connecting to the FIOS router and not to the access points, correct?

That furthers my suspicion that the FIOS router is bad at handling multicast traffic. It won’t be too hard of a test, but for us to proceed here, we need to limit some variables, and I suggest turning off the WiFi capabilities on the FIOS router so we can determine if this is the cause.


I hear ya, but then my remotes wont work at all. The ROCK on NUC (as you may recall from another “ticket” is not communicating over wifi, so it depends entirely on the FIOS router as an Ethernet to 802.11 bridge. The remote AP certainly wont work reliably in that part of the house. That’s part of why i’m certain the multiple AP thing is a red herring.


Ok, how about this testing scenario?

  • Turn off the WiFi on the FIOS router and have it still be a DHCP server

  • Ethernet to the ROCK will still work as well as any of the other Ethernet ports on the router

  • Temporarily move one of your access points to the router location and connect via Ethernet to router

  • Have the Roon Remotes connect via the access point WiFi instead of the router WiFi

  • Verify if the same behavior occurs

We have often seen multicast issues from ISP-provided equipment, so without any further testing here we won’t be able to make progress and the router is my biggest suspicion at this point time.

Thanks. Unfortunately, the AP i have in service now is a range extender - a repeater. No Ethernet back haul. BTW any AP ought to be transparent to multicast. I do plan to change that out to a proper ethernet backhaul unit in the future, but no can do… sorry. If i can find an old 802.11G Ethernet AP I’ll try to set it up. But the cure is now vying with the disease from an inconvenience standpoint…

The APs if they are configured properly, sure. But for FIOS or any ISP-provided gear I don’t have confidence that they will always pass multicast properly.

This sounds like it would be a good test and the next step to troubleshoot the issue further.

I’m going to hold off. Its happening less frequently - so its not clear that it would be an easy or quick test, since i’d really have to wait a long time to get good info. I have pinpointed one culprit - if the computer (MacOS) goers to sleep that is acting as one Roon endpoint, it halts everything on that grouped zone. Or, if it asleep, and i wake it, it halts everything. This is NOT however, the whole story. Sometimes its just “start radio, plays a few minuets, stops inexplicably”. restart and it typically plays a long time (or maybe stops again immediately and needs a “third time’s the charm”). This is inconsistent - much less recently. Why? Dunno. G

You can try and set your Mac to not go to sleep and see if the sleeping is indeed the culprit for that symptom.

No setting needed - i have extended its sleep. But - read my note again - sometimes the problem occurs after minutes as well. This has nothing to do with the other computer since it sleeps only after 2 hours.

This behavior seems different than the Android issues. If you want, I can take a look at diagnostics, just let me know the time + date + track when this next occurs and I can activate diagnostics mode for your account.

Update: In part, issues have settled down, and in part I’ve learned a few things that I will share both with support and with other, maybe frustrated users.

First, if the remote can’t find the Roon core ---- wait. While mine has been better i learned that it will often still say “cannot find Roon core, please select an a new core” (or something similar). WARNING: DON:T FALL FOR IT. if you DO select a new core, you are lost and it may take forever to re-establish contact. But rejoice! It lies like a rug! Probably within 5 sec of telling you to go select a new core it will, 95% of the time, magically reconnect. But should you “touch that dial” - no such luck. This issue is the interface giving us all really bad advice. Apparently its on some stupid arbitrary timer. Who thought that was a good idea?

As to finding core/ROCK in general, the best advice I can give, and this should not be the case, is use an android/fire tab as a single app device. If you switch to another app, like Silk or Outlook, the reconnect time lengthens disturbingly.

On any Apple device, new or old, its pretty seamless. But they cost, oh 10-15 times as much as a heavily discounted Fire.

So — great improvement. Some is simply working better (why? who knows), some is simply recognizing that the interface communications are not your friend. Ignore them.

Note, back to that old red herring, this is, and always has been, on the same AP despite the fact that i have several both the core and and the remotes are always on the same AP when i report back - and they almost never connect to other APs anyway since those are at far ends of the house.

On the “other topic” - Live radio starting and stopping, I’ll make two quick comments:

  1. it has been far less frequent
  2. There is a consistent issue that if a remote grouped device, a laptop, awakes and connects, it stops everything. I have no idea why. I have a very old MacBookPro that is by “bridge” int he main music room, which is remote from my ROCK. Bring it online, bring roon to a stop. But at least its predictable and therefore acceptable.


Hi @Just_Me,

Have you tried the other Access Point to see if the current networking equipment is a factor here?

That’s interesting… mind sharing a timestamp of when this issue is occurring? We can investigate this further:

  1. There are no other relevant APs in that part of the house. The ROCK is connected only via ethernet (RJ45 cat 6 Gig-E)
  2. On the grouped issue - its soooooo consistent it must b part of your design - 100% consistent. As to a timestamp - what exactly do you want? The time is not important to you, so there must be more you want…

Thanks, Grant

Hi @Just_Me,

I wanted to check in with you to see if there’s been any change in behavior here since upgrading to Roon build 521?

I am not sure I quite understand this part - you have the laptop grouped as an audio zone with you other zones? And when you play to your individual zones and wake the laptop up, it automatically joins the grouped zone and music stops playing to your other zones (if I’m understanding correctly)?

Since i don’t know when build 521 occurred, i cant say for sure. But no meaningful changes, no.

And yes, you have the config right. I have the ROCK in the LR directly connected to a USB DAC ()actually a USB-> SPDIF converter --> DAC). That is grouped with the laptop which acts as the ethernet–> USB bridge for a USB DAC int he music room. When the laptop goes to sleep - it ceases to play (no surprise). When it wakes, all zones int he group (usually just the 2) stop until restarted. A minor issue.

Radio still periodically stops for no reason.

Hi @Just_Me,

I spoke to the technical team regarding this aspect and they have confirmed that this is expected behavior. When a zone that is part of a group re-joins the group the other endpoints also pause.

This seems like a bigger concern - does it happen with all radio stations or just one/some in particular?

Neither are particularly problematic. The grouped zone thing is not unexpected. The radio stopping happens with multiple stations Since i listen to a relatively few most of the time I cant really say whether there is a difference - but its not, for instance, one station. Mot NYC/NJ NPR stations, Radio paradise…and Typically once restarted it goes much longer - maybe 1+ hours. But then it will stop.

Not the end of the world, more a minor inconvenience. The issues I have raised with sign-in / sign out of roon cores is a much bigger concern since it prevents use under some conditions. (another thread but being studiously ignored by support, probably because they don’t like the answer)

Hi @Just_Me,

Is this the thread you are referring to?

It looks like it got auto closed since it appeared to be a one-time issue. If this is occurring again and it is reproducible, I can re-open it for you, do you wish for me to do this?

that is but one instance a bigger issue. I first brought this up when i moved, and needed to be able to switch cores, with no network connectivity (and no wifi in the ROCK due to the BIOS configuration YOU provide). Its not about the technical details, its about the rigidity of the license control method and the fact that your method assumes network connectivity. if your tech works perfectly 100% of the time, not issues, ok. But if its does not, it prevents legitimate users from being able to play their very expensive ($500 to you plus even more for the NUC) system. I have raised this in at lest three threads for different situations, but they all have a root issue: a very strict policy and an assumption that things work as your engineers imagine. Sometimes they don’t, and we, your customers, pay the price. no one even offered me a temporary authorization to get it working when i moved. I find that to be indifferent arrogance. Even Microsoft gives you a grace period before its protection kicks in, and they are not a model of flexibility.