Playback stops... and continues sometimes later, mostly on MQA Tidal tracks

Hello @noris

I’ve seen the thread of @Andrew_Waghorn regarding the connection time of roon remote after core start.
It seems related to my problem of poor start and scanning times.

I’ve done some other tests watching the effective connection to my nas where scanned folders are located.
I noticed that the nas user account used by the Roon core took almost 4 minutes to establish a cifs connection. As soon as I saw the user connection in my nas administrator ui, all my remotes screen switched from “Waiting for Remote Core…” screen to the animated Roon logo and after a few seconds the album browser.
I don’t know why it takes so long for the Core to connect to my nas but I’m 100% sure that before the 1.7 update it worked perfectly and connection was established very quickly.
If there’s a problem related to samba/cifs connections it can also explain the relative new slowness of the file scans.

Please let me know what to do to investigate this matter further.

Hi @AdZero,

Thank you for sending the database and new logs over.

At this time, we don’t believe the issue is related to storage, but there is still an active investigation on QA’s side. We’ll have more information once the investigation is complete.

Hi @noris,

Just a quick update to let you know that the Tidal playback problem is occuring again.
Like yesterday night, I tried to play a tidal album added to my library and playbacks hangs just after a few seconds…

I really hope you will find the root cause of this problem and its fix soon. It’s frustrating !

Hi @AdZero,

Which zone were you playing to at the time, the LS50W or the Sheild? Next time this behavior occurs can you please note the exact local time + date? This would help in cross-referencing in logs.

Hello @noris ,

It was the LS50w zone and according to my scrobbles it was between 19h59 and 20h11 (8/01/2020) that I tried to listen to Tidal albums.

Tried again tonight, with the same Tidal MQA album and playback stuck after a few seconds @17:54.
As yesterday tried another Tidal non MQA album and playback stops and resumes constantly (between 17:55 and now 17:57)

I’m switching to my local library once again…

Hi @AdZero,

Thanks for letting me know that timestamp. It looks like logs have not yet been delivered on our end, can I please request that you share a manual copy as you have done earlier in the thread?

Was your LS50W still connected via Ethernet for the above timestamp? Is there any change if you temporarily connect them via USB?


My LS50W are always wired with ethernet.
I just uploaded a new zip file with the logs on the One Drive share used previously.
I’m currently experiencing the issue (started @ 21:20) once again as I’m listening to a new Tidal release (not MQA). Playback stops and resumes constantly.

Just adding one info on that thread since I am experiencing the same problems with Tidal streaming. Seems to be more the case when it is an MQA track but it is very annoying and makes it impossible to listen since it stops every few seconds and ends up skipping the track, etc…
I am running Rock on a NUCi7 recommended configuration and with a Raat connection to a Devialet, but the problem is the same on my other system which is going through Airplay.
Help would be most welcome !

1 Like

My first message about this problem is almost two months old… and nothing has changed or even progressed.
I pay Tidal Hifi every month and most of the time I’m not able to use it with Roon…

I was listening to music tonight and playback stopped after 6 seconds of the first Tidal track in my queue (@18:42). It has already been said, but it’s FRUSTRATING !

@noris, have you something concrete to tell us about this problem and how it is handled ? I provided you logs and export of my database but nothing really came in return.

Have you any clue about a possible cause ?

Thanks for your feedback.

Have you also some news about my other problem that was merged into this one ?
What are the conclusion of your investigation on the QA’s side ?


Hi @AdZero,

Apologies for the frustrations here. Let me try to address each part of your post individually as there are actually two issues here:

Upon reviewing the logs, you were getting “Too many open files” errors listed when using the old database. Your database is still with QA pending review (and they have to load it to the lab environment to try and reproduce using your database), but once you set the old database aside and started fresh, this shouldn’t have impacted the other behaviors you reported (unless you restored the database from a backup).

Have you by any chance tested the KEFs via USB as I suggested earlier in the thread?

We have seen some reports that KEF speakers are not always stable on Ethernet, which is why I suggested to try using them via USB.

There have been some reports that factory resetting them helps improve behavior on Ethernet and it’s worth a try, but testing on USB would be the better test.

Factory reset instructions can be found on the KEF Manual - Section A5.

If this same behavior were to occur on the NVIDIA Shield zone or your NUC’s HDMI zone, that would provide a better data point, and point away from the theory that this behavior just happens on the KEF endpoint, so if you do notice this behavior occur there, please do let me know as it would warrant a different troubleshooting path.

As I said before, I tried with a fresh database (with a very little number of local tracks as metadata retrieving takes time…) just after you merged the two problems and was able to reproduce the playback problem. I then switched back to my database to be able to listen to my library and keep all the metadata customization I made during the last two years.
I never was able to try to reproduce the core slow starting and file scanning times as it woul take way too much time with my library.
As this problem is not critical,

I will wait for a more precise feedback of your QA pending review.

I didn’t test the usb connection to the Core previously but I took time to connect my LS50W to my NUC core with USB cable and made some tests with Tidal MQA content.
I first tried to reproduce the playback stop/resume/skip problem with the LS50W ethernet zone. I succeeded (very quickly…).
I then switched to the newly LS50W USB zone and, surprisingly, experienced the same problem many times ! The only difference is that playback did not stuck. It stuttered and ended skipping to the next track in the queue.
Moreover an error message was displayed. When experiencing the problem in ethernet mode, there was no such message.

I precise that my internet connection was ok and that there was little network load.

I transfered my queue to my Shield Chromecast zone and was able to listen to the first three tracks of the same album without a problem.

I switched back to my LS50W usb zone and continued listening to the same album. Problem occured once again after a few tracks with the same message displayed.
I finally switched back to LS50W ethernet zone and playback once again stopped after a minute…
I tried to factory reset my LS50W as adviced and tried once again… but still the same problem and as soon as I’m playing local content everything is ok…

I think I’ve done all the tests you suggested this time.

I must insist and say that something is wrong with your last changes. Once again, everything worked fine before the 1.7 update and I use Roon everyday for more than two years now !

Like @Philippe_D_ANDREA and the other users who have a similar problem I want to use Roon and Tidal with my main audio equipment as before.

I you want something else (logs or more specific tests), please let me know. I’m motivated to help you and stay a satisfied Roon user, but the situation must evolve !

EDIT : I’ve done all these tests between 18:30 and 20:00 today.

Hi @AdZero,

This piece of your post is interesting. In the previous similar reports, USB worked as expected for KEF devices, it was just Ethernet/WiFi that was affected.

Since this issue occurs on USB, I have re-enabled diagnostics and am looking through the 18:30-20:00 timestamp you mentioned.

I’m seeing the following:

At 18:10 - Your Shield was not buffering a TIDAL track properly
At 17:53 - You KEF USB endpoint is getting a “lost” message when playing library tracks

To me, this looks like the issue is indeed occurring on the SHIELD zone as well.

I would next like to clarify if this behavior occurs for any network output. To determine this, can I please ask that you:

  1. Install Roon on another PC you have
  2. Keep the Core on ROCK (on the “Choose your Core” screen, select ROCK)
  3. Try playing content to your other PC’s “System Output” zone
  4. Verify if there are any issue and if there are note the timestamp it occurs at

Can you please use these instructions so we can determine the impact of this issue better?

Hello @noris,

Just to be clear, I watched the log files on Roon server and there’s a one hour offset between the timestamps in the logs and the ones I give.
When I said 18:00, it is actually 17:00 in the logs.
Starting from now, I will try to give you the timestamps from the logs to avoid any confusion.

For the two points you noticed, as far as I can remember :

  • when I tried to listen on Shield zone playback worked well despite the buffering problem you saw (no interruption)
  • when I listened to local flac files no audible error noticed despite the getting lost message

Maybe these errors where logged when I switched between zones or tracks.

Roon is already installed on the only PC I have as I used it as my main Roon remote.
I tried to play the same Tidal MQA album both on the System output zone and the PC soundcard S/PDIF zone. No problem with the playback for the whole album length.

I then played the same album with the LS50W plugged with USB on my PC. No problem.

I tried once again playing the same album with the ethernet LS50W zone and playback stopped after 2:22 of the first track.
I uploaded the last log file to my OneDrive share, file name is : AdZero.RoonServer.Logs.202001261857.txt
I watched the content closely and your clearly see what’s happening (first track played till 2:22, stop, skipping to next track and playback stuck at the beginning of next track) around these lines :

01/26 18:50:14 Trace: [LS50W] [zoneplayer/kef] state from device: STOPPED
01/26 18:50:14 Trace: [LS50W] [zoneplayer/kef] zoneplayer state: Disconnected

Let me know when you have analysed these logs and have something new.

Thank you.

Hello @AdZero,

Thanks for confirming that this issue is only occurring on the KEFs.

We are actively discussing this behavior with KEF and have an open investigation into a few similar reports, hopefully we will have some more information soon.

I will be sure to let you know once we have any further details regarding this investigation with KEF, if this behavior starts occurring regularly on any of your other endpoints in the interim do let me know.

Thank you.

Hello @noris,

Just a quick update to tell you that today I encountered a similar problem playing local content. Playback stopped suddenly while listening to 24/96 flac album with my LS50w ethernet endpoint.
I uploaded log file AdZero.RoonServer.Logs.202001261857.txt in my OneDrive share.

It happened somewhere after the following line :

02/07 17:50:13 Trace: [LS50W] [Enhanced 82.7x, 24/96 FLAC => 24/96] [100% buf] [PLAYING @ 3:49/6:38] Blood of Eden - Peter Gabriel

It was actually stucked @ 3:54.

Hi @AdZero,

Thanks for letting me know. I just spoke to the hardware team and there has been some progress with KEF in debugging this behavior and we’re still communicating further with them on how we could improve. I can’t say for sure when the investigation will be completed but do note that it is under active development.

Hi @AdZero,

We’ve recently released RoonOS (Build 186) which includes changes that should improve the behavior regarding RoonServer restarts and delayed Roon Remote/Client connections. Please give it this a try and let us know how it goes!

You can read the full release notes here:

The Team at Roon Labs

Hello @noris !

I noticed and applied the update yesterday evening. I wondered what the update contained as there were no release notes published at that time.
I will watch more closely in the next few days but I already noticed a quicker startup this morning when I powered on my core.


1 Like


I confirm that startup times are back to same level as before 1.7 update.
However file scanning seems to be still as slow. I’m not able to compare but I’m convinced that scanning was faster before.
However it is not really a problem apart for people who do really frequent scanning which is not my case.

I keep my fingers crossed to have a fix for the ongoing issue with playback which happens again a lot recently with Tidal.


1 Like