I’m running Roon ROCK with a Qobuz and Tidal subscription. I wanted to play around with the DNS sinkhole Pi-hole on a Raspberry Pi to block unwanted ads and tracking. Pi-hole is very easy to setup and I used the default configuration. Everything seemed to work well and I was blocking ads and tracking but then when I tried to play audio from Qobuz, Roon just hung and would not play. I also noticed that email from Qobuz had much of it blocked out. Tidal still worked as did local files. I turned off Pi-hole and immediately Qobuz worked again. My Qobuz email displayed properly.
I take this to be a pretty good indication that Qobuz is using something that is blocked by default by Pi-hole. I did not track it down yet. There is likely some site that needs to be whitelisted in order for Qobuz to function properly. Or, maybe better, Qobuz should not be using sites that are blacklisted by a popular DNS sinkhole.
Anyway, thought folks might want to know. I no longer use Pi-hole so I am not experiencing a problem. Also, this is not meant to be a criticism of Pi-hole, that seems to be a pretty cool project. It’s more a criticism of Qobuz.
I haven’t seen any issues with Pi-Hole and Qobuz with or without Roon. I’d be curious to dig into your settings to see if I could replicate this issue.
It’s certainly possible that my configuration was somehow causing an issue with Qobuz. Unfortunately, I’ve backed that SD up and re-imaged with another OS. I will try to get you my configuration but it may take a while as I am currently embarking on a wine pilgrimage. I was using the latest Blacklist from here: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
.
I am using same default blacklist and don´t notice any problems with Qobuz.
But take a look at pi-hole config blacklist page, I have had problems with other services when I have added some entrys manually (by looking at query log page and then added some suspicous looking items to blacklist)
Other folks running Pi-hole without issue with Qobuz certainly does point in my direction. I will try to run this down when I have time. One possible reason why some would see an issue with Pi-hole/Qobuz or any other service would be the way in which we are configuring how DNS is configured. In my case I configured Pi-hole as my DNS server at the router. Any of my devices that was configured to point to my router for DNS would then be using Pi-hole. This included my NUC running ROCK. If you configured DNS per device and, for example, pointed all your Roon endpoints to Pi-hole but your Roon Core was still resolving elsewhere then you might not see any issue. So it might not be me. But, me is still the primary suspect.
Honestly, it sounds like a fluke. Maybe a bad entry at that time. Like you, I am running the Pi-Hole network wide for DNS resolution. In fact, I even block outbound DNS at the router, except from the Pi-Hole. An interesting issue, but I wouldn’t spend too much time on it, unless you want to migrate back to the Pi-Hole.
Maybe related. Maybe not. I don’t run pi-hole but I’ll you my tale of DNS sadness anyway…
Qobuz stopped working on Rock and only Rock. Worked fine from all my other systems. Opened support case and they said switch to the 1.1.1.1 or 8.8.8.8. Set that on Rock directly and all was good. There was no way to troubleshoot this from Rock and without proper traces from Rock I was content with the workaround… just use 1.1.1.1 set in the web interface of Rock and be happy with it.
Fast forward a few months and I identify something really wonky with a cloud service I’m trying to reach. “Hey Mr. ipeverywhere, this looks like the Rock issue.” and this time I was able to run traces. Long troubleshooting session / spare you the details / go right to summary… It was a firewall issue. I had blocked TCP to my DNS server and this specific domain was doing some wonky AAAA lookup even though I have v6 turned off everywhere. The AAAA response was asking the client to switch to TCP because of the size of the answer. Since I blocked TCP that didn’t happen and the client never progressed to an A record query.
I fixed my firewall. I set Roon back to using my own DNS server. Alls been good for months now. So, yeah, if you’re blocking TCP or have any firewall rules set-up between Rock and the pi-hole check your rules or temp remove them and try again. Otherwise you can set just Rock to use something besides the Pi-hole for DNS (unless you’re intercepting DNS shrug)
Thanks Mr. @ipeverywhere ! I will try that. So maybe this issue is an interesting but infrequent combination of Rock, Qobuz, Pi-hole, and firewall/dns.
Not sure if this will be helpful but I finally found the root cause for my frequent drop-out when playing hires titles from Qobuz.
I’m a long-time user of Pi-hole and always use the default blocking sites but I’d been playing around with which DNS servers to contact for DNS resolution.
It turned out that I had picked DNS servers in the configuration which didn’t (properly) support ECS (e.g. cloudflare). ECS is most useful for content provides as it allows DNS servers to refer to the most appropriate server when resolving a request.
So once I picked DNS servers which properly support ECS (e.g. Google or OpenDNS) my roon core connected to the - for me - best Qobuz server (i.e. the one nearest to me).
Funnily I never had any issue playing hires titles from Tidal so they must be using a different mechanism for load-balancing and the issue was depending on the time of day, i.e. more prominent in the PM or during the night than in the AM.
PS: I’m based in Germany so this might be a Germany related issue but worth pointing out to others who might have a similar issue.
Thanks ipeverywhere. This solved a problem that had been bugging my online connectivity. When you fixed your firewall did you work out which ports you had to allow for TCP or did you allow all TCP traffic?
