Qobuz through Roon skipping and stopping


(Tapatrick) #22

Hi @noris

Thank you very much for diagnosing all this.

Regarding the ping testing. How long do I need to do this?
and does this not interfere with the network traffic if I have to do it for along time until it shows up?


(Noris) #23

Hello @Patrick_Bryson,

A ping test is very lightweight, all it does is send a few packets to google’s servers and ask “anyone there”? And then google replies “yes, I’m here” or “no response”. If you are seeing the no response (or “Response Timed Out”) messages, this indicates that your network connection is not able to reach the general internet, so I would definitely double check this.

Thanks,
Noris


(Tapatrick) #24

Here is what the ping test said:

— 8.8.8.8 ping statistics —

267 packets transmitted, 267 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 14.918/25.180/587.606/39.806 ms


(Tapatrick) #25

also ping to the roon server ( ping 192.168.0.10):
— 192.168.0.10 ping statistics —

116 packets transmitted, 116 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.695/1.851/5.134/1.150 ms


(Tapatrick) #26

This one with the ping -t 192.168.0.10

usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
[-g sweepminsize] [-h sweepincrsize] [-i wait] [−k trafficclass]
[-l preload] [-M mask | time] [-m ttl] [-p pattern]
[-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z tos]
host
ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i wait]
[−k trafficclass] [-l preload] [-M mask | time] [-m ttl] [-p pattern] [-S src_addr]
[-s packetsize] [-T ttl] [-t timeout] [-W waittime]
[-z tos] mcast-group


(Noris) #27

Hello @Patrick_Bryson,

Thanks for running those ping tests. Just to confirm here – these tests are from when you were experiencing Qobuz issues at the same time or are they a baseline of how the system normally operates? The most useful test here would be running a ping test when Roon is experiencing issues with Qobuz and I just want to make sure this is the test that was performed here.

Thanks,
Noris


(Tapatrick) #28

those were just initial tests to see how the system is…

During this one (playing Qobuz album) there was a short pause, then started itself

— 8.8.8.8 ping statistics —
892 packets transmitted, 892 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.860/21.325/78.821/7.518 ms


(Tapatrick) #29

this was to my roon server with a short pause in the middle, which then started itself

192.168.0.10 ping statistics —
28 packets transmitted, 28 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.122/1.542/4.427/0.862 ms


(Noris) #30

Hi @Patrick_Bryson,

Thanks for running those tests. It appears that the network connection itself does not go down so let’s take a look at other possible causes here:

  1. Can you please confirm if the same behavior occurs across multiple endpoints? If you don’t have other endpoints to test, that’s ok, we can also use the “System Output” or HDMI output from your Core, even if there is no audible media playing, it will be a good test to see if just the Direct Stream Junior Dac is affected by this issue or if all zones are.

  2. ISP provided routers can still have unsatisfactory behavior associated with them as mentioned in our Networking Best Practices Guide, would you by any chance have another router around the house or one that you can borrow from a friend and see if replacing the Virgin router to a typical consumer grade router has any change in the issue?

  3. Are you able to use the TIDAL/Qobuz app and play content as expected through them without this issue occurring?

As before, if you can kindly let me know a few timestamps of when are running these tests, I can also check to see if diagnostics perhaps reveal further information.

Thanks,
Noris


(Tapatrick) #31

Thanks @noris

I’ll will try to find time to test your suggestions.

  1. I don’t have other endpoints

  2. Virgin don’t allow changing routers

  3. Tidal/Qobuz apps: That is not possible in my current set up. I will try a Mac laptop as Roon server.

As mentioned the earlier serious problems are not happening. I don’t know why as fundamentally everything is the same. Over past few days only getting occasional pauses and stops which are hard to catch with a ping test.

Hopefully have more extensive times on weekend.

Thanks for your help!


(Noris) #32

Hi @Patrick_Bryson,

Thanks for letting me know that. I would go ahead with trying TIDAL/Qobuz as you mentioned on the Mac Laptop as this will also give us a good data point.

If you’d like to run the test on “System Output” on the NUC core, then that will also allow us to separate if the issue happens across all endpoints (meaning the behavior is on the Core itself) or just for that one PS Audio Endpoint (meaning we have to take a closer look at just the endpoint).

Do let me know when you have had a chance to look into this further after the weekend.

Thanks,
Noris


(Tapatrick) #33

Will do.

Curious what this shows @ 22.06
I choose a qobuz track… seeking for 20-30 seconds then stops. This was the ping test during this time.

— 192.168.XXX ping statistics —

1347 packets transmitted, 1347 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.698/1.867/86.860/4.038 ms


(Noris) #34

Hello @Patrick_Bryson,

I just wanted to check in here with you to see if you were able to reproduce the same issue on the System Output zone over the weekend.

I checked at the above timestamp you mentioned, and I did see the issue. It appears that the buffers were being filled in this case but there is something more concerning here in the logs:

03/22 23:06:42 Trace: [Ultra Digital] [zoneplayer/raat] Endpoint SONORE USB AUDIO State Changed: Idle => Prepared
03/22 23:06:42 Trace: [raatserver] [RaatServer audiolinux @ 127.0.0.1:43581] lost client connection. Retrying
03/22 23:06:42 Trace: [raatserver] [RaatServer audiolinux @ 127.0.0.1:43581] connecting (attempt 1)
03/22 23:06:42 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
03/22 23:06:42 Trace: [raatserver] [RaatServer audiolinux @ 192.168.0.9:36469] connected

It appears that the Core is losing connection to the localhost RAAT instance as well, and this kind of behavior does not typically occur on standard Operating Systems. Have you tried running Roon on a non Audiolinux based server and is the issue still the same?

This info will be useful in narrowing down the issue further but getting to stop loosing connection to the network interface has to be addressed first and foremost, it’s not clear if the operating system is part of the issue here or if it is your network setup but let’s start by eliminating one of these variables.

Thanks,
Noris


(Tapatrick) #35

Thanks @noris

Interesting. Both my servers run on Linux but only one on Audiolinux. I’ve not had the time to try the things you suggested yet and get down to this level of detail. It’s getting very technical and requires some reconfigurations to test.

I’ll be travelling very soon for work so I may not be able to get to this for a while. I’ll update you when I have tried another source with system out.


(Noris) #36

Hi @Patrick_Bryson,

Thanks for letting me know. No rush, whenever you are back and ready to take another look just let me know. Safe travels!

Thnaks,
Noris