Having the same problem with Qobuz when searching in Roon. Roon can play Qobuz titles already in my Roon library, but cannot search. I also have Tidal and there are no problems with Tidal Roon integration I see at this time.
Now getting “Unexpected error loading album. Please try again later. (Unauthorized)” when searching Tidal with Roon.
@dylan Dylan, I am using Roon 1.7 on a Nucleus+ core. Starting yesterday, I have not been able to use Qobuz or Tidal integration to search for anything. I can stream Qobuz and Tidal tracks if they are already in my Roon library, but I cannot search. Using the Qobuz or Tidal apps on a PC or iPhone are fine so my accounts are good with them. I have also gone to Settings in Roon and logged out and logged back into Qobuz without fixing the problem. I have rebooted the Nucleus+ which did not help. I can play and search for song, artist or album for music on my Synology NAS without problems. Please help.
Hi @Ivor_Benjamin,
So we can better assist you, please describe your network configuration/topology, including any networking hardware currently in use, so we can have a clear understanding of how your devices are communicating.
Can you share a screenshot of what you are seeing?
Are you able to load the TIDAL/Qobuz pages at all?
@dylan
Here is what my Settings > Account page looks like. For some reason there is an error retrieving my roon account information.
@dylan
Here is what a Qobuz page looks like:
@dylan
Here is what a Tidal page looks like when I click on any song and try to play it.
Here is what a Tidal page looks like when I click on any song and try to play it:
@dylan
Here are the Settings > Services page:
@dylan
I can only play Qobuz or Tidal songs that were already in my Roon library before the problem started. My Roon lifetime account is linked to my email address: [email address removed by Support]
Hi @Ivor_Benjamin,
I’ve removed your email address from the post and unlisted so that your email is not publicly visible.
It looks like your Core machine is having some trouble communicating with our servers.
Can you describe your networking setup?
Are you able to access the Nucleus Web Administration Interface? If so can you share a screenshot?
Thanks!
@dylan here is the screenshot requested. I am always able to access the Nucleus Web Administration Interface. Qobuz and Tidal tracks that have already been added to my Roon library also stream just fine. So do live radio stations. The only problems I have seen is that I cannot search. browse or play new content from Qobuz or Tidal. Everything from my NAS library works fine.
So my Roon Nucleus core is able to:
- Contact Qobuz and Tidal to stream music if its in the library already.
- Contact and stream any radio station from the Live Radio tab.
- Contact and stream any content on my NAS on my local network.
- Also, no problems for the Nucleus to connect to and stream to any Roon endpoint using RAAT or ApplePlay. Also, backups to the NAS are working fine.
My Roon Nucleus is NOT able to:
- Retrieve my Roon account information on the Settings > Account screen.
- Search, load or stream content from Qobuz or Tidal that is not already in my Roon library. I have no problems with Qobuz or Tidal when using the iPhone or desktop apps.
For my network, things are like this:
Internet Provider: Cox Gigablast.
Network Security Appliance/Router: Cisco Meraki MX84
Network Switch: Cisco Meraki MS220-8P
Access Points: Cisco Meraki MR34 x3 all directly connected via CAT6 to the POE MS220-8P.
The Nucleus and NAS are directly connected by ethernet CAT6 to the MS220-8P.
Here is a screen shot from right now from my Cisco Meraki Dashboard. As you can see the Nucleus is exchanging traffic via the internet with several Roon servers as well as Qobuz and Tidal servers. So it is not a connectivity issue that I can identify.
I have no other network issues.
I would really like to get this resolved quickly please.
Hi @Ivor_Benjamin,
Thanks for the details here. Things look okay on the Web UI screenshot, so moving forward I want to focus in on why the Nucleus isn’t able to reach out servers. Typically this is caused by one of two things:
- A networking issues preventing the connection from being made
- A firewall on the network blocking the connection
With this in mind, I’d like to suggest a test that should help us better understand why this is occurring. We’ve seen similar networking issues arise from managed switches in the past, Meraki switches in particular as they often require advanced configuration.
If you use a Windows or Mac machine as your Roon Core temporarily does this same issue occur? Specifically, if the Mac or Windows machine is connected in the same exact way as the Nucleus? This will help us further understand and verify where this behavior is stemming from.
Thanks!
@dylan ,
I did the test you asked for. I shut off the Nucleus+ and did a clean install of the Roon App on a MacMini. When I tried to enter my login credentials to configure it as new Roon Core, I got the following error in a pink box on the Mac: “Network error: Please check your internet connection.”
So I ran a packet trace on the Mac’s ethernet adaptor and here is the traffic exchanged when I was pressing the “Login” button on Roon several times and getting the same error. Looks like some exchanges were “unreachable”. The Mac is on the same LAN with the same security settings at the Nucleus. But nothing changed in my network configuration. I disabled “Advanced Malware Protection (AMP)” and “Intrusion detection and prevention” at the Cisco Meraki MX84 security appliance. No difference. In the past I had used this MacMini on the same network to setup my first Roon Core when I was trying out the software before I bought it. No problems. Then I went “all in” and bought a Nucleus+ to have the best hassle free experience with Roon. Worked for several months, them boom. All this trouble. I started with Roon at 1.6 and had no problems with 1.7 or the small upgrades since.
Here are what I believe are the relevant packet exchanges between the Mac Mini (192.168.129.61) with the new temporary core when I try to login and make it a Roon core:
00:53:36.678439 IP 192.168.129.61.51053 > 34.73.185.80.9200: Flags [F.], seq 332755958, ack 668508463, win 2053, options [nop,nop,TS val 546197192 ecr 2574207606], length 0
00:53:36.679852 IP 192.168.129.61.50921 > 68.105.28.11.53: 49087+ A? accounts5.roonlabs.com. (40)
00:53:36.679965 IP 192.168.129.61.56620 > 68.105.28.11.53: 46695+ AAAA? accounts5.roonlabs.com. (40)
00:53:36.688107 IP 68.105.28.11.53 > 192.168.129.61.56620: 46695 3/0/0 CNAME dualstack.roonaccounts5-1791324942.us-east-1.elb.amazonaws.com., AAAA 2406:da00:ff00::3213:fbf4, AAAA 2406:da00:ff00::3210:e80b (169)
00:53:36.689177 IP 192.168.129.61.50921 > 68.105.28.11.53: 49087+ A? dualstack.roonaccounts5-1791324942.us-east-1.elb.amazonaws.com. (80)
00:53:36.711725 IP 68.105.28.11.53 > 192.168.129.61.50921: 49087 2/0/0 A 50.16.232.11, A 50.19.251.244 (112)
00:53:36.714311 IP 192.168.129.61.51581 > 50.16.232.11.443: Flags [S], seq 3558622972, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 546197227 ecr 0,sackOK,eol], length 0
00:53:36.749828 IP 68.105.28.11.53 > 192.168.129.61.50921: 49087 3/0/0 CNAME dualstack.roonaccounts5-1791324942.us-east-1.elb.amazonaws.com., A 50.16.232.11, A 50.19.251.244 (145)
00:53:36.750892 IP 192.168.129.61 > 68.105.28.11: ICMP 192.168.129.61 udp port 50921 unreachable, length 36
00:53:36.758393 IP 34.73.185.80.9200 > 192.168.129.61.51053: Flags [F.], seq 1, ack 1, win 219, options [nop,nop,TS val 2574374384 ecr 546197192], length 0
00:53:36.758804 IP 192.168.129.61.51053 > 34.73.185.80.9200: Flags [.], ack 2, win 2053, options [nop,nop,TS val 546197271 ecr 2574374384], length 0
00:53:36.781769 IP 50.16.232.11.443 > 192.168.129.61.51581: Flags [S.], seq 338353617, ack 3558622973, win 28960, options [mss 1460,sackOK,TS val 630878894 ecr 546197227,nop,wscale 8], length 0
00:53:36.782055 IP 192.168.129.61.51581 > 50.16.232.11.443: Flags [.], ack 1, win 2058, options [nop,nop,TS val 546197294 ecr 630878894], length 0
00:53:36.783946 IP 192.168.129.61.51581 > 50.16.232.11.443: Flags [P.], seq 1:183, ack 1, win 2058, options [nop,nop,TS val 546197295 ecr 630878894], length 182
00:53:36.784246 IP 50.16.232.11.443 > 192.168.129.61.51581: Flags [R], seq 338353618, win 0, length 0
00:53:36.947672 IP 192.168.129.61.49210 > 192.168.129.18.49152: Flags [.], ack 1722716575, win 2048, length 0
00:53:36.952246 IP 192.168.129.18.49152 > 192.168.129.61.49210: Flags [.], ack 1, win 2048, options [nop,nop,TS val 586378124 ecr 545537039], length 0
00:53:37.137498 IP 192.168.129.61.51584 > 192.168.129.241.53218: Flags [S], seq 4256504969, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 546197646 ecr 0,sackOK,eol], length 0
00:53:37.256087 IP 192.168.129.241.53218 > 192.168.129.61.51584: Flags [S.], seq 4026692744, ack 4256504970, win 28960, options [mss 1408,sackOK,TS val 571074345 ecr 546197646,nop,wscale 6], length 0
00:53:37.256386 IP 192.168.129.61.51584 > 192.168.129.241.53218: Flags [.], ack 1, win 2050, options [nop,nop,TS val 546197763 ecr 571074345], length 0
00:53:37.276240 IP 192.168.129.241.53218 > 192.168.129.61.51584: Flags [P.], seq 1:17, ack 1, win 453, options [nop,nop,TS val 571074350 ecr 546197763], length 16
00:53:37.276525 IP 192.168.129.61.51584 > 192.168.129.241.53218: Flags [.], ack 17, win 2050, options [nop,nop,TS val 546197783 ecr 571074350], length 0
00:53:37.430363 IP 192.168.129.61.51584 > 192.168.129.241.53218: Flags [F.], seq 1, ack 17, win 2050, options [nop,nop,TS val 546197936 ecr 571074350], length 0
00:53:37.430481 IP 192.168.129.61.51586 > 192.168.129.241.53218: Flags [S], seq 868738241, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 546197936 ecr 0,sackOK,eol], length 0
00:53:37.450855 IP 192.168.129.241.53218 > 192.168.129.61.51586: Flags [S.], seq 294687428, ack 868738242, win 28960, options [mss 1408,sackOK,TS val 571074384 ecr 546197936,nop,wscale 6], length 0
00:53:37.451261 IP 192.168.129.241.53218 > 192.168.129.61.51584: Flags [F.], seq 17, ack 2, win 453, options [nop,nop,TS val 571074384 ecr 546197936], length 0
00:53:37.451340 IP 192.168.129.61.51586 > 192.168.129.241.53218: Flags [.], ack 1, win 2050, options [nop,nop,TS val 546197956 ecr 571074384], length 0
Please help. Thank you.
Ivor Benjamin
In particular, this exchange looks suspicious:
00:53:36.750892 IP 192.168.129.61 > 68.105.28.11: ICMP 192.168.129.61 udp port 50921 unreachable, length 36
It is suspicious because ICMP should not be using layer 4 UDP. Cisco Meraki probably appropriately drops this traffic.
To explore this as the culprit. I did a trace on the Mac Mini limiting the protocol to ICMP. Three traces:
Mac Mini pinging its LAN gateway, then Mac Mini Pinging Google’s open DNS server 8.8.8.8 and lastly I did an ICMP limited trace for when I try to log into Roon with the Roon app to make the Mac Mini a new Roon core. Same problem. Same result. If Roon sent these packets I am not sure why.
Mac Mini Pinging local gateway:
listening on sw0_pcap, link-type EN10MB (Ethernet), capture size 262144 bytes
02:13:05.725139 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 86, length 64
02:13:05.725403 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 86, length 64
02:13:06.726925 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 87, length 64
02:13:06.727044 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 87, length 64
02:13:07.728265 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 88, length 64
02:13:07.728697 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 88, length 64
02:13:08.730944 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 89, length 64
02:13:08.731061 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 89, length 64
02:13:09.736207 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 90, length 64
02:13:09.736320 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 90, length 64
02:13:10.737044 IP 192.168.129.61 > 192.168.129.1: ICMP echo request, id 58890, seq 91, length 64
02:13:10.737161 IP 192.168.129.1 > 192.168.129.61: ICMP echo reply, id 58890, seq 91, length 64
— End Of Stream —
MacMini Pinging Google’s open DNS server.
— Start Of Stream —
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sw0_pcap, link-type EN10MB (Ethernet), capture size 262144 bytes
02:13:35.841417 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 6, length 64
02:13:35.861831 IP 8.8.8.8 > 192.168.129.61: ICMP echo reply, id 779, seq 6, length 64
02:13:36.845967 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 7, length 64
02:13:36.865494 IP 8.8.8.8 > 192.168.129.61: ICMP echo reply, id 779, seq 7, length 64
02:13:37.848785 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 8, length 64
02:13:37.869755 IP 8.8.8.8 > 192.168.129.61: ICMP echo reply, id 779, seq 8, length 64
02:13:38.854095 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 9, length 64
02:13:38.875800 IP 8.8.8.8 > 192.168.129.61: ICMP echo reply, id 779, seq 9, length 64
02:13:39.859381 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 10, length 64
02:13:39.887642 IP 8.8.8.8 > 192.168.129.61: ICMP echo reply, id 779, seq 10, length 64
02:13:40.862449 IP 192.168.129.61 > 8.8.8.8: ICMP echo request, id 779, seq 11, length 64
— End Of Stream —
Mac Mini trying to log into Roon to become a Roon Core:
— Start Of Stream —
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sw0_pcap, link-type EN10MB (Ethernet), capture size 262144 bytes
02:14:09.882878 IP 192.168.129.61 > 192.168.133.100: ICMP 192.168.129.61 udp port 62286 unreachable, length 36
02:14:20.057357 IP 192.168.129.61 > 192.168.133.100: ICMP 192.168.129.61 udp port 49745 unreachable, length 36
— End Of Stream —
Please provide advice and a solution. Thank you for your help.
Ivor Benjamin
Good morning! New update. I was able to get the temporary Roon core on the Mac Mini to mostly work. I did install a minor bug fix upgrade to the Meraki Switch last night. Also rebooted the MX84 security appliance and M34 Access points. No configuration changes. On the temporary Core everything works EXCEPT for Tidal. Weird.
So here is a summary of the Mac Mini Temporary core functionality:
Register as a Core with Roon and obtain license: Yes
Load a local LAN song library: Yes
Set up and log in to Qobuz search and stream normally: Yes
Set up and log into Tidal: NO (I even changed my Tidal password and logged in via the Tidal web interface on a different machine no problems). When I try to add Tidal account credentials in Setup > Services > Tidal I get “Bad username or password” in a pink box although I am certain I have entered valid account credentials.
What should I do next? I would like to get Tidal working and go back to my Nucleus Core.
Thank you for your help.
Ivor Benjamin
One more update. I quit the Roon app/core on the Mac Mini and restarted it. Then tried to confiture Tidal and it WORKS!
So as far as I can tell, the temporary Mac Mini Core is working as intended.
Now what do you suggest as a next step to get back to the Nucleus core?
Thank you again.
Ivor Benjamin
Hi @Ivor_Benjamin,
Thanks for the updates here! I’m glad that you were able to get the Mac Mini up and running.
If you switch back to the Nucleus as the Core are things in the same exact state as before?
Is there any difference in how the Nucleus is connected to the network vs the Mac? Can you describe the network setup and what networking gear each device is connected to and how they’re connected?
The Mac Mini is working 100% correctly. Now I want to migrate back to the Nucleus+. To prep for this, I actually swapped the switch ports which the Mac Mini and the Nucleus+ were connected to on the Meraki switch. The Mac Mini continued to work perfectly after swapping switch ports with the Nucleus+. See the screen shot of the switch in the Cisco Meraki dashboard. This is the only switch on the network. The switch ports are configured identically at Layer 2. The Layer 3 configuration is also identical. Both the Mac Mini and the Nucleus+ grab dedicated IP addresses based upon their MAC addresses from the same DHCP pool. There are no firewall, IDS or content filtering lists that differ between the IP addresses of the Nucleus+ and Mac Mini.
Question: how do I “reset” the Nucleus+ so that it will ask me to reenter my credentials to grab back the Roon license from the Mac Mini?
Thank you again for your help and when the Nucleus+ is back up and running I am going to listen to a lot of high res music!
Ivor
