Thanks for running this test! So this confirms that the PC itself is fine, but it’s just something regarding the network that prevents proper communication.
Since you have tried multiple routers, I wonder if this issue could be the modem or the firewall you’re using. Is there any change in behavior if you temporarily disable the router/modem firewall?
What if you try bypassing the router completely and have just the Core connected to the modem, do you still see this behavior occur?
(also reported in the ropieee thread.)
More testing, realized that with the ropieeexl endpoint turned off, the problem went away.
Did some network debugging.
My imac had a DNS server setting of 8.8.8.8. I must have set that in the past.
That’s google, so should work fine. But I was having some DNS lookup failures.
So reset it to 192.168.1.1 (my internet router).
Rebooted etc.
Now seems to be much happier.
Not sure why ropieee off would make things happy and with it on made it unhappy.
Not sure why 8.8.8.8 DNS server setting caused problems.
Doesn’t make much sense.
But that one change seems to have made roon talking to tidal happy. So I"ll be happy.
Hopefully it stays happy. Thanks for the thoughts…
I don’t suspect the Ropieee is part of the issue here but the DNS change might be. Using Google DNS shouldn’t have caused such behavior, but do let me know how things go with the DNS changed to the router!
Hi Noris.
Ropieexl running on my rasptouch -> roon has trouble talking to tidal
rasptouch turned off -> roon is much happier. Although it does seem to make me authenticate to Tidal every time I restart it and maybe after a period of time as well.
I’ve repeated this test several times with always the same result.
You cannot set a DNS service like that on a local device as far as I am aware. You have to set the main DNS service (Google, OpenDNS etc) at the router and have all devices point at the router using the router’s DNS.
If you set it at device level that device tries to look to the outside world but can’t because it relies on the router to resolve the external sites. It is worth doublechecking that the Ropieee is set to 198.168.1.1 for the DNS too.
Hi Danny,
On the mac you can certainly set whatever DNS server you want.
I had it pointed directly at google.
I changed it to point, as you say, to my internet router which makes its own decisions. Here is the CLI command:
% sudo networksetup -setdnsservers ethernet 192.168.1.1
A system can resolve DNS by itself without needing the router to do it. It’s just a service at an IP address and 8.8.8.8 is a valid, routable IP address.
On the ropieeexl I don’t see where via the GUI you can set a DNS server. The networking looks right to me.
Poking around via ssh on the ropieeexl, I see that it’s DNS servers are set to 8.8.8.8 as well in /etc/resolv.conf. Pretty sure I didn’t make any DNS changes on it.
[root@ropieeexl network]# cat /etc/systemd/resolved.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Resolve]
DNS=8.8.8.8 8.8.4.4
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
LLMNR=false
DNSSEC=false
MulticastDNS=false
#Cache=yes
#DNSStubListener=udp
Sorted out how to change it to my internet router…
Testing now…
Oddly enough, changing the DNS servers on the ropieeexl, at least on first testing, seems to have roon + tidal happy. Will keep the ropieee on and see if things stay happy.
No idea why a DNS setting pointing to google, on a roon endpoint, would cause roon core to not talk well with tidal. But seems to be the case…
Yes you can set it to whatever you want, you can in Windows too. However if there is a router between it and the outside world it doesn’t work too well.
If the Mac or PC or whatever was connected directly to the internet there’s no issue however if you are going via a router then the router is the DNS as far as the attached devices are concerned and then the router itself resolves the outside world via whichever service you point it to.
The fact this has resolved the issue demonstrates the point rather neatly :).
To put it another way the Mac or Pi can’t ‘see’ the outside world, only the router can. So by setting the DNS on the device your asking it to go off to Google or whatever directly and it can’t do that.
A router gets its name for a reason-it routes the traffic in and out of the network.
Note that except for roon, everything in my network worked fine when a given device (my mac) had a specific DNS resolver set. Just roon was acting oddly.
So beside the point, but if others read it would be good to be accurate here.
router routes traffic between networks, say between my home systems and the internet
It accepts UDP, TCP, and other protocol traffic. If a host inside says “hey, go ask 8.8.8.8 to resolve this DNS name to a DNS address”, the router will pass that traffic.
If someone doesn’t know how to find a DNS resolver, it can ask the router and the router will provide it the DNS resolver info.
So, works fine to have DNS resolving configured on a host, but if it’s not set it can be delivered by DHCP from the router (acting as the DHCP server as well) and then DNS can be resolved without having it configured on the host.
I have tried both setting the DNS service at device level and at router level. I have always found it problematic at device level hence I would always suggest setting it at router level.
Some information here is a tad inaccurate but it got me thinking. Could some of these issues be down to poor handling of mDNS traffic and actually be a problem communicating with the Core?
If the endpoint is trying to resolve a hostname to the IP address of the Core and fails using mDNS it will revert to the configured DNS servers regardless of whether manually configured. If these servers are external they won’t have a host record for the Core and problems will ensue. If the endpoint is configured to use the local router as a DNS forwarder then, given that most likely the router is also the DHCP server, there is a liklihood the router will have dynamically created a host record for the Core when it issued it a DHCP lease and as such will be able to resolve the request.
Not really had time to test properly but I have two identical Bluesound systems, save for hostnames and IP addresses, one of which can be discovered and works with Roon and one of which doesn’t. No amount of rebooting or kerjigging would change this. After reading this thread I changed the DHCP issued DNS server addresses from Cloudflare and Google to be my local router and sure enough the second Bluesound system has suddenly sprung into life. Could it be that some of my longterm problems are a result of a poorly implimented mDNS service on the endpoint, the Core, a poorly behaved switch or a combination of these? I am almost tempted to remove my network cable and see if the issues with Bluesound 2i WiFi have also been resolved. Could it really be this simple?
Interesting!
Not quite sure why mdns etc would be failing as it’s all in the same broadcast domain (all plugged in to the same switch). But some network issue on the endpoint might make some sense of this.
The thing I can’t sort is why the endpoint would have anything to do with Roon talking to Tidal.
Perhaps Roon is doing something non-standard w.r.t networking, but that would be very odd.
Anyway, happy my problems seem to be resolved and maybe your issue too…
Pretty much why it would have been the last thing I would have thought to try if I hadn’t glanced at this thread.
Who knows what the data flow is with Roon when streaming from Tidal as I haven’t tried to put a protocol analyser on it but the Core is still in the frame even if only for control purposes so its not necessarily the same as other solutions. Just tried it and its repeatable. Odd things happen when I don’t use the router as the DNS forwarder.
Personally I never trusted my Cisco SG300 switches. They do odd things with LACP, VLAN trunking, IGMP snooping and added to that spanning tree is a tad flaky on them too! Aside from that they work great…
My apologies then for the incorrect information. I have only ever had grief when trying to set the DNS server at device level but more than happy to stand corrected
I wonder though if there is some underlying reason that causes Roon/Tidal issues at device level though and that it causing some of the issues with Tidal login for so many people. It certainly seemed to resolve the situation here.
Could be way out of course-as I have already ably demonstrated in this thread
Hi Danny,
They certainly seem related, but setting DNS resolving settings manually on its own is usually a perfectly fine thing to do.
Must be some yet-unknown thing that Roon does that causes it not to work where Roon is involved.
Checking this should be part of the debugging that Roon tech support does when there are communications problems…
Yes things seem much more stable.
As reported in another thread though, I need to relogin to tidal or restart roon every day to get tidal authentication to work. Hopefully that gets fixed soon…
