Roon Player on Mac 1.5 build 363
Mac is MacBook Pro 2017 16 GB, 1 GB SSD
Roon Core is ROCK 1.5 build 363 as well
Connected to NAS same switch, 1 Gb ethernet
LS50w are connected in wireless fairly close to the Wifi Router, I can through 24/96 file without any issue, flawless playback otherwise.
Issue
If I go heavy on track skip/next/previous or scrub within a track, like multiple actions like 1s to 5s apart, Roon and LS50w refuse to play anything.
No error message, the Roon Player just stall, play button doesn’t play anything.
The only work around I found is to play a track in Spotify to LS50w using Spotify Connect
I don’t have this issue with Spotify, just with Roon
Additional details
I am playing mostly FLAC 16bit/44.1khz and was able to reproduce the issue also with mp3 file
The bottleneck is likely to be the 3 spinning disk RAID in the NAS, 7200rpm should be do the trick, I am okay if it takes a couple of seconds to buffer before playing.
I have an Airport Extreme 802.11ac with the uplink going to the FTTH modem.
The 3 ethernet ports are used as follow: Roon Core, NAS, and AV Receiver, all Gbit ethernet.
Players are connected in WiFi, I usually have no problem getting 500 to 600 Mbps over the LAN/wifi.
I use the built-in switch from the Airport router.
I tried for 10 minutes with the AV receiver in the living room (AirPlay Streaming), I never experienced any hang/stall/lost status. Today I was out, my wife got into the same issue with the Kef. If it helps here Roon Player was still showing the Kef in the list while they were off. I show her how to restart the Roon Server software from the software, it resolved the problem.
I am not a Tidal subscriber.
The only thing I can eventually offer to narrow down the research is to hook up the Kef over Ethernet.
I did a reset of the speaker, hook them up over wire, and try to seek/scrub on a 16b/44.1khz track, I got in the same nowhere.
I made a short video for you so you can see.
The .133 address is wired I made sure the wifi was not enabled between the Kef and the router.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the behavior occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
Now that I have the timestamps, diagnostics have been enabled on your account. The next time your Core is active a diagnostics report will automatically be generated and uploaded directly to our servers
Once that’s been received, I’ll be sure to update this thread and pass the diagnostics over to the team for further analysis.
I wanted to touch base with some good news, which is that our technical team has been able to reproduce this behavior and we’ve opened up a bug report with our developers. Getting things reproduced in-house is a critical first step to a solution for this issue.
We are investigating further and discussing this behavior with KEF. We will be sure to update you here when more news becomes available.
Thanks for your report saying you were able to reproduce this issue. I took a look at our internal tracker today, and I can see that your ticket is still in our development queue. This means our developers are still planning to look at this, but we don’t yet have a timeframe for when that’s going to happen.
Once the ticket has been scheduled and work begins, I’ll have a better sense of timing here. Thanks in advance for your patience!
