Core Machine (Operating system/System info/Roon build number)
QNAP Native on TS-470 Pro (i5 3470T, 16Gb RAM, Library on 3*6Tb WD Red + Roon DB on 240Gb SSD) or
Roon ROCK on NUC6i5/NUC7i3/NUC8i3 (8Gb RAM, DB on m.2, library on internal 2Tb Hybrid drive and/or external 2.5") or
Portable setup with Roon complete on an MacBook Pro 2017, 16Gb ram internal m.2 for DB, external 4Tb 2.5" USB.
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
100Mbps connection via fiber, main router Asus RT-N66U. QNAP on WLAN 2.4G bridge, ROCK units on hard wire.
Endpoints mostly wired but Aries G1 on WLAN 5Ghz.
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
A few Pi’s, Aries G1 and Femto, Allo USBridge and SOtM sMS-200 or internal audio in MBP
Description Of Issue
As you can see i have a few Core machines that i use on occasion. Since 1.6 i often have to re-authorize the Core that i want to activate. And that takes a very long time, after i filled in my account details and clicked “Authorize”…
Wondering why this process must take, like, 10minutes?
I agree with you here, authorization should not take 10 minutes to complete. Is this behavior consistent only for your network or does the same occur on different networks as well? Are you using the same Roon Remote to authorize these cores? Is the behavior the same if you use another Roon Remote?
Thanks for getting back to me on this @noris,
I’d say the behaviour is pretty consistent between different networks and controllers.
It takes more time than my iPads screen lock function which is set to 2minutes. This means i have to be ready and active to keep the screen alive while authorizing, without clicking outside the auth-dialogue. I have missed this on occasion, and that the time needed when active is shorter than 10 minutes.
Let me once again be clear that it is only in the situations where i need to login to my account, and that it this process that is testing my patience. If i have two cores running the process of authorizing and de-authorizing them is pretty instant.
Just to make sure I understand you correctly here, the long wait issue is when you try to log in to your account, before you hit the authorize button, right? Is there any way you can share a screenshot or video of the exact screen that’s taking 10 min to complete?
Sorry for being slow with this… I haven’t been able to recreate this recently. As a matter of fact i have only seen the “log in” dialogue once in about 4-6 Core changes, and then it was not as glacial as earlier.
I timed it and it took about two minutes, which is way too slow for liking, but an obvious improvement over the previous experience.
Why cant the login process take as long as the time it takes to unauthorize the previous licensed Core? That only takes a few seconds mostly.
As a matter of fact, this has improved, but not to full satisfaction.
Yesterday, i had two Cores running, my standard NAS based Core (on an QNAP TS-470 Pro, Intel i5 3470T, 16Gb RAM) and my most recent ROCK, built on a NUC8i3 with a fast m.2 240Gb and 8Gb of DDR4.
I had redirected a major part of my library on the ROCK from an external 2.5" 4TB USB drive to the NAS (where my other Core lives).
This caused Roon to reanalyze almost all of the files, strangely, about 65K files.
So, to get to the point, I was playing music from the QNAP Core yesterday, to let the ROCK do it’s analyzing. But i was curious about it’s progress and disconnected my iPad from the QNAP Core and pointed it to the ROCK instead.
For some reason, the “you need to log in” screen came up.
I filled out my correct info and pressed Log In.
I timed it using my analogue watch and it took 2minutes - give or take 20 seconds.
You mentioned that this issue is improving recently, has anything network-related changed in your setup since we last spoke?
I believe the next step here would be to take a look at the diagnostics right after this issue occurs for both cores, perhaps there is an error being outputted at the login time in the background? I can’t say for sure, but it’s worth a check.
Can I please ask you to reproduce this issue and note the exact local time + date in your country of when it occurs and from which Core you are switching and the destination Core?
IP addresses for both Cores are preferable, and then I can go ahead and enable this mode and review diagnostics for any such traces. E.g. at 10:11PM I was using QNAP core (192.168.1.102) and at 10:14PM I switched over to the ROCK Core (192.168.1.105).
Appreciate the continued support!
I do have two Cores running at this moment but it is unclear to me what causes one of these to “log out” from it’s account, and hereby forcing me to perform a slow log in the next time it’s up for Core duties?
Since yesterday i have almost instantly been able to switch Cores, using my iPad, with the occasional “deactivate” for the last used core.
I’ll note the required information when it happens the next time, and provide detailed timing info.
Hi Noris, just reporting back on this.
I have been experimenting with several Roon Core’s lately and i think i have found a pattern where a Core forces me to log back on when it is being taken into service.
However, i had forgotten you wanted the ipadresses and times… Sorry, i’ll research this.
The time it takes to log in is still somewhere around 2-3minutes which is remarkably slow…
Thanks for the update, but when possible can you be a bit more specific on the exact patterns? I agree that timestamps will be helpful for looking at logs, if you are noticing this only occurs when going from one type of OS core to another type this is a great data point. Do let me know any additional details when you can.
This has been neglected long enough now, the pattern i see is this:
As long as I dont ever click the top left “Back/Log out” Arrow everything is fine. I don’t need to log back in for this particular Core and wait for the controller several minutes.
My workaround is this:
I simply Deactivate the currently active Core in the list below. It doesnt matter if it leaves me with the “wrong” Core for this particular controller. I can then go to Settings and Disconnect the “wrong” Core, and promptly select the desired Core, without delay.
Every time i am forced to login, due to this particular core having been logged out, it takes somewhere between 100 and 150 seconds. Its MUCH faster to switch Cores like i described above.
Deactivation of a previous Core only takes a couple of seconds, rather than the couple of minutes to log in…
Just to make sure I understand you clearly here, you are saying that instead of un-authorizing the existing Core and then re-authorizing then new one + logging in, you are:
Un-authorizing one of the old Cores
Selecting the remaining active cores (which is not the intended target)
Disconnecting in Roon Settings -> General
Selecting the new Core from the list
You are not being presented with a login request and the transition is seamless
Is this correct?
Does this behavior only occur when switching from one specific core to the other?
You mentioned last time that this issue occurred when you disconnected from QNAP and tried to connect to ROCK, has this been the case every time? Does switching between your QNAP to Macbook Pro exhibit the same behavior or has this been limited to QNAP -> ROCK?
Can you please let me know the exact local time + date when this issue next occurs? I still believe that diagnostics may be of help here to identify a possible pattern.
I haven’t seen a login screen since i started using the strategy of selecting another active Core…
And, i don’t see a different behaviour depending on which Core is being activated, they seem to behave in a similar way.
I can perform a logout if you want some logs of this? I’m sure i’ll be forced to logon that particular Core when activating it.
Thanks for confirming I understood you correctly .
Yes, if you can please reproduce this issue and then manually send me the logs from the affected core (by using these instructions), I can take a look to see if there is anything abnormal going on when you login the normal way. Please specify from which core you you activated. Thanks.
I have tried a few times making this clear, to me and you too…
Today I have had three Cores active and now, at 201907824 17:07 CET I selected Disconnect on my MacBook. Rather than selecting Unauthorize I opted for the Logout option top left.
The ordinary logon screen appeared, and I opted to display it in English rather than my default Swedish. After Roons restart, I filled in my credentials and pressed Login.
Simultaneously I started a timer, and after 1 minute 8 seconds (at ca 17:11) I was once agin prompted to Unauthorize my MacBook Core. I clicked the button and Roon opened immediately.
Hope this makes thing clearer? I never use the logout option anymore and switching between cores is a lot faster when desired.
Thank you for sharing those timestamps and log files. I took a quick look through them and I don’t see anything jump out at me as being an issue, so I will consult further with our QA team regarding the traces. As soon as I have further details I will be sure to let you know. Thanks!
I appreciate your patience here while QA has looked into this behavior further. They have tried to reproduce your findings by using non-staff testing accounts and switching between cores, but logging in on their end has not taken more than 30 seconds, even over WiFi connections.
I can’t say what is causing the delayed login on your end to occur, it is possible that it is due to the network or the Cores themselves are delayed in receiving the login confirmation back from our servers.
My suggestion here is that we revisit this issue again after the next Roon Release is out to see if any of the changes we made help with this issue. If the behavior is currently mitigated with using the strategy of selecting another active core and performing logout instead of un-authorize my suggestion would be to use this method for the time being. Thanks!
