Qobuz slow to start

I noticed that often albums I play from Qobuz would take a long time to start playing, I don’t have this issue with Tidal, but very often on Qobuz… Does anyone else have the same issue? there isn’t a reliable way to recreate this…

I had such delays when running Roon on my Dell XPS 15 laptop. Since moving to a Nucleus, I have no delays.

I had this problem with Qobuz.

For me, it was an IPv6 versus IPv4 issue. After editing /etc/gai.conf to prefer IPv4 addresses (and rebooting the Roon Core machine), I encountered no further delays.

I would not know how to fix that on RoonOS.

you did this on your core, router, or…?

My Core is running on Ubuntu 19.10. That’s the machine I did this on.

Just so nobody screws up their DNS, here’s what my /etc/gai.conf file looks like, after prioritizing IPv4:

# Configuration for getaddrinfo(3).
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting.  But the RFC also says that system
# administrators should be able to overwrite the defaults.  This can be
# achieved here.
# All lines have an initial identifier specifying the option followed by
# up to two values.  Information specified in this file replaces the
# default information.  Complete absence of data of one kind causes the
# appropriate default information to be used.  The supported commands include:
# reload  <yes|no>
#    If set to yes, each getaddrinfo(3) call will check whether this file
#    changed and if necessary reload.  This option should not really be
#    used.  There are possible runtime problems.  The default is no.
# label   <mask>   <value>
#    Add another rule to the RFC 3484 label table.  See section 2.1 in
#    RFC 3484.  The default is:
#label ::1/128       0
#label ::/0          1
#label 2002::/16     2
#label ::/96         3
#label ::ffff:0:0/96 4
#label fec0::/10     5
#label fc00::/7      6
#label 2001:0::/32   7
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
#precedence ::ffff:0:0/96  10
#    For sites which prefer IPv4 connections change the last line to
precedence ::ffff:0:0/96  100

# scopev4  <mask>  <value>
#    Add another rule to the RFC 6724 scope table for IPv4 addresses.
#    By default the scope IDs described in section 3.2 in RFC 6724 are
#    used.  Changing these defaults should hardly ever be necessary.
#    The defaults are equivalent to:
#scopev4 ::ffff:  2
#scopev4 ::ffff:    2
#scopev4 ::ffff:       14
1 Like

Interesting, I hope the Roon folks can comment on the IPv4 versus IPv6 configuration on the ROCK/Roon OS platform, I could not find a way to do it from the ROCK configuration page… Curiously, if I run the same albums from withing the Qobuz desktop application, everything works fine, never a hint of a delay so it has to do with the Qobuz integration with Roon.

I’m afraid the issue depends rather strongly on the capabilities of your router and your broadband provider.

A month ago, with my provider (Spectrum), IPv6 was definitely not working — something you can test, by visiting https://test-ipv6.com. That was the cause of the Qobuz delays that I was experiencing. And those delays immediately went away when I prioritized IPv4 addresses.

Tonight, on a lark, I retested it, and IPv6 seemed to be working. Since nothing on my router had changed, I assume that Spectrum has done something to upgrade their network.

So I reverted the above change in /etc/gai.conf and did a

sudo systemctl restart systemd-resolved

So far, Qobuz is working fine, with no delays.

N.B.: I have no idea how you would fix this on ROCK/Roon OS. I can only vouch for MacOS and Linux.

I just tested and yes, I didn’t have an IPv6 connection, then went to my ASUS router settings and found IPv6 disabled there… I just enabled it and ran the tests again, now I have IPv6 and will test to see if Qobuz performance improves after this…

i have an eero mesh network, and i believe there is an IPv6 setting, will have to test it. i’ve been having a problem with a variety of older wifi endpoints staying connected, but it’s not clear if it’s a wifi issue, a core issue, or failing wifi cards.

has happened on Squeezebox Touch, Boom, and Radio, all of which are older, but also on a Sonos Play 3 (about 3-4 years old).

i have two RPis, a 3+ and a 4, and neither has an issue connecting via wifi.

And the verdict is … ?

It is inconclusive, I basically changed 2 things at the router level, 1- successfully enabled IPv6 and ran the test which checked out fine, and 2- moved the WAN DNS setting to “automatic” to get the ISP DNS setting instead of the previous setup where I had the Google DNS settings forced ( and…

It looked like Qobuz suddenly started behaving more like Tidal within Roon, spent 2 hours listening and only at the end of the listening session did I again start getting weird delays when Qobuz was playing thru roon, specially when changing formats (when moving from 44.1 to 92khz for instance)… Will do some more testing…

IPv6 is evidently still flaky with Spectrum, so I’ve gone back to prioritizing IPv4 addresses.

I wish there was a way to do so in ROCK…