Hi @Just_Me,
Happy New Year and apologies for the delay in getting back to you here, I have been travelling until recently.
I was not aware that you had multiple access points configured. Does this behavior only occur when you are connected to the primary router? What is the model/manufacturer of the Access Point? If you specify a manual connection to the Access Point, is the connection stable each time?
I see no pattern – It occurs on any/all of them (to be fair one is at the other end of the house and i’ve never connected the remote to it). Note that the ROCK is ethernet connected (wired). Most of the time however i am connected to the primary - which is the Verizon Fios Router (FIOS G-1100). The other two are linksys APs - simply pass through s from a routing / IP pool perspective.
Does anyone have a single AP anymore?
Yes, I do.
Single AP checking in over here as well. Relatively small apartment and Unifi AP Pro covers pretty much all of it.
It sounds like multicast is going wrong somewhere. I would simplify the network a bit, you mentioned that this occurred when you were using the Fios router and went away when you connected to the linksys access point, correct?
If you can temporarily turn off the WiFi features of the Fios router, it would be interesting to know if this occurs when only the Linksys APs are broadcasting the SSIDs. You may also want to try toggling IGMP Snooping/Proxying if you have such settings available in the router/access points.
No that is not what I said. I am generally connected to the main router. Ios devices have zero issues.
Note this now occurs with a second Android tab but never iOS. Turning off Wi-Fi and back on helps. Sounds like you cache whatever the scan returns. Not good. G
I love this product, I hate this product.
So, i got a new Fire tab. Loaded Roon remote. Note that Roon remote is working mostly fine on two iphones and another fire tab. I have a ROCK active as my core. I also have full Roon (inactive) on several macs. One is being used as a network-usb bridge endpoint.
The new fire tab simply wont find ROCK. It boots up and says “select your Roon core”. The macbook pro (not active) shows up. NOT the ROCK, which all the other remotes seem to see just fine.
What’s going on?
Grant
Configuration: ROCK, latest. Intel NUC NUC8i5BEH. Gig-E network, all wired except for remotes. Local DAC via USB. Remote room with Macbook Pro acting as a network --> USB bridge (Roon endpoint) driving another DAC. Several remotes, two iphones two NOOKs.
Note: while this is a new twist, the support guys are well aware of Android related issues and my setup.
Note2: stopping and re-starting wifi fixed it, once. Entering the explicit IP address or a fully populated subnet did not.
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.
Hi,
Remotes are always connected to the main router/AP - so that’s not it
Why would this only affect the android devices? And only the Roon app on those devices? - possible but unlikely
On BOTH? The definition of insanity is doing the same things twice and expecting a different result. 
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.
G
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.
yes.
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.
G
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:
G