In case others have the same problem, there’s an interesting symptom to try to replicate :-
Everything off (Core & Remote / Remotes).
Remote will search until you toggle (on the Core) the “accept Remotes” on / off, or input the Core IP address within the Remote app.
Restart Remote - no change to the above behaviour - Remote doesn’t connect unless “helped”.
Remote on (Remote will obviously search).
Remote immediately finds Core without any assistance.
Roon running on Windows 8.1.
Controlling it directly, it played to Meridian end point.
But Surface Windows 10 and iPad could not connect.
Restarted Roon, and connection worked.
Not investigated further.
Moving @AndersVinberg’s response here, since I was going to follow up with @rolski today, but this may be a second occurrence of this issue, so we might as well track this type of connectivity issue together, since the other two linked above were unrelated memory issues and installation problems, respectively.
I believe @rolski has also seen a similar circumstances to this – correct me if I’m wrong:
Anyway, our QA spent a significant amount time this week trying to reproduce the connection issues described by @rolski since 1.1. There were some bug fixes implemented to our discovery protocols for 1.1 that seem to be stable for the vast majority of users, but apparently are causing issues in certain configurations.
Unfortunately, despite our best efforts to set up a network similar to the @rolski’s (which he patiently described for us in considerable detail), we were not able to reproduce this issue in house, yet. So we’re working on a bug fix release for the future that will include the ability to enable some extra logging here, so we can gather more information.
@rolski – I’ll send you some more details, including instructions for enabling the logging. @AndersVinberg – let us know if you’re seeing this issue more regularly and I can walk you through the process as well.
@mike remote has now failed to connect twice again.
Last night, restarting Roon did not help (unlike previous times), toggling the “Accept remotes” did.
But I saw one possible hint: when I restarted Roon, I got a brief (~1s) message about “managing the library will take longer than usual due to a version upgrade”. Running build 55 and have for some time, no version change. This suggests something has gotten scrambled.
The connection has aged out overnight.
Last night I got it working by toggling the accept setting. After listening, I left the iPad with the Roon app open.
This morning, I tried with another iPad: no connection.
Went back to the original iPad, the app was still up but could not reconnect.
Toggling the setting made the iPad immediately connect, sub second, I was holding it in my hand as I clicked on the setting on the OC.
That said, the other iPad couldn’t connect after this.
Nor could a Surface.
Maybe one connection breaks the ability to accept further connections? But shutting down and restarting the remote on the main iPad still works. I’ll reboot this iPad and see what happens.
@mike As expected, after reboot this iPad couldn’t connect. (Although it is strange that cycling the app didn’t have that effect, suggests it has to do with networking. My network is excessively complex. I’ll experiment.)
Ok, I removed my double hop network connection through an extender, and the connectivity problems disappeared. I expected it was network related, after the recent experiments.
So now my problem is solved (except I have an Ethernet cable running through my living room).
But I still consider this a Roon bug. The double hop network worked fine for all other purposes, at great speed (triple channel ac). So it is interesting why Roon wouldn’t handle it, and why toggling the Accept setting helped.
Switching off Norton 360 Premier (Firewall) doesn’t fix the problem.
Switching off Windows Defender doesn’t help either.
My Remote has “1 hop” to my WiFi Router - it’s directly connected - and is then connected to my Core through 1 dumb switch. The connection is also rock-solid when using all other programmes / network connections / the internet.
Using “enter i.p. address” doesn’t actually work any more either - Roon (Remote) just searches continually.
The only methods that force a connection are :-
Core : start Roon. You can play music, or not - makes no difference.
Remote : start Roon. There will be no connection.
Core : close Roon.
Core : start Roon. The Remote will identify the Core immediately.
Remote : connect to Core. All is good. Until Roon (Remote) randomly crashes / shuts-down at some point. Which is another problem altogether…
a) Core : start Roon. You can play music, or not - makes no difference.
b) Remote : start Roon. There will be no connection.
c) Core : toggle “accept remote connections” off & on. The Remote will identify the Core immediately.
d) Remote : connect to Core. All is good. Until Roon (Remote) randomly crashes / shuts-down at some point. Which is another problem altogether…
It seems that a common thread is Windows10 although there are more reports of this with other OS’s now throughout this website. And this started immediately with v1.1/55 : v1.0 was stable…
so, the remote sends out a packet saying ‘hello? anyone there?’ in a loop. either that isnt getting out of your remote, or the server isn’t receiving it, or the server’s response isnt making it back to the remote.
when you flip the ‘accept remote connections’ setting on, or restart the server, it sends a packet to everyone on the LAN saying ‘FYI, I’m here!’ – you seem to be getting those just fine, which means that server -> remote communication seems fine.
that leaves remote -> server communication issues, which could happen due to network topology or firewall. your network toplogy is single LAN w/ hub + spoke. very simple, which is why I suggested firewall.
i’ve added a lot more logging related to this network traffic and given @mike a build that he will have to figure out how to get to you. you will need to run with a special commandline argument so the trace can be turned on, as it is too noisy to leave on in normal builds.
The 1.1 update fixed a few bugs in this code that were preventing it from working in some other cases, but I’ve looked over then a ton and not found any new issue that I might have caused would explain what you are seeing. The other thing is that most people are working fine and we can’t reproduce the issue in our QA lab either.
I did a line by line audit and added quite a bit of trace so we can see what your network triggering. This is clearly a bug of ours.