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

Core Machine (Operating system/System info/Roon build number)

Roon OS (build 183)/Roon 1.7 (build 500) on Intel NUC 7I5BNK

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Synology RT2600AC router
Core is wired with ethernet cable
Roon remote on Windows 10 PC (Ethernet) / Android phone (Wifi)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

LS50W (Ethernet)
or
Nvidia Shield [Chromecast] (Ethernet)

Description Of Issue

Since the 1.7 update, playback stops very frequently when I listen music to my LS50W.
Before the update, I encountered this issue with my Chromecast endpoint, which I use mostly on Radio mode with paying attention to what is playing.

I updated my Roon devices last thursday, and I encountered the problem with the two Tidal MQA albums I tried to listen to.

I listened to other Tidal content that is not MQA and the problem did not occured.

Playback stops randomly somewhere in a track, but on Roon remote :

  • Playing icon keep moving on the current track line in the queue screen
  • The Play/Pause button still displays Pause as if playback continues
  • The cursor is blocked on the track timeline

If I click on pause then on play, playback resumes and most of the times stops again after a few seconds.

If I put a local track next in the queue and click next, playback restarts with this track without any problem, although I noticed this behaviour one or two times with local content in the recent days.

I have two MQA albums in local library, and problem doesn’t seem to happen with them.

I do not need to say that this is really a pain :rage: as it’s almost impossible to listen to a whole Tidal (MQA ?) album.

Hi @AdZero,

Thanks for reaching out, I have a few suggestions:

Can you let me know the exact local time + date you next notice this behavior?

You can grab a few more MQA tracks from the 2L Test Bench, can you give these a try and let me know if the behavior is the same?

Are the LS50s up to date on newest firmware?

Hi @noris

OK.

OK, I’ll do some tests as soon as I can.

I wasn’t aware of this recent update. My KEF are now up to date.

Hi @AdZero,

Please do check if the local MQA albums display the same behavior. I also want to mention that we just released Roon 1.7 build 505 which contains some improvements to our buffering implementation. I would give the update a try as well to see if it helps. Full details here:

Hi @Noris

I updated Roon this evening and gave the Ad Astra Soundtrack another try…
Playback stuck once again on the first track after 11 seconds. It was approximately 20:42:40.
Retried once again hitting the previous button and this time playback stuck after 8 seconds @ 20:47:55.

I then switched to Cup - Spinning Creatures -not an MQA album- which I listened to perfectly a few days ago. This time playback of the first track paused and resumed many, many times… (The track is not played entirely as I write these lines). Occured around 21:00, before and after.

It is really annoying, Tidal is unusable.

Hi @AdZero,

Thanks for sharing those timestamps. Now that I have this information, I have gone ahead and enabled diagnostics mode for your account and what this action will do is next time your Core is active, a set of logs will automatically be generated and uploaded to our servers for analysis.

@Noris,

I’m doing a quick test before leaving home. Currently the MQA Ad Astra Soundtrack is playing flawlessly.
Will try again this evening.

I’m a little bit puzzled by the diagnostics mode activation.
I’m aware of your privacy rules, but it should be a customer action to enable diagnostics and choose the level of telemetry that is send to your servers. At least current account status regarding this matter should be displayed somewhere. Maybe it’s the case and I don’t know where…

Happened again today approximately @ 13:24 with this MQA track.

Later, happened with this MQA track. Paused and resumed several times between 18:14 and 18:16 and remained stucked somewhere later in the track…
I then tried another MQA album and playback paused after twlve seconds of the first track, somewhere near 18:21…

Core Machine (Operating system/System info/Roon build number)

Roon OS (build 183)/Roon 1.7 (build 500) on Intel NUC 7I5BNK

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Synology RT2600AC router
Core is wired with ethernet cable
Roon remote on Windows 10 PC (Ethernet) / Android phone (Wifi)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

LS50W (Ethernet)
or
Nvidia Shield [Chromecast] (Ethernet)

Description Of Issue

Since I updated Roon to 1.7 version, I noticed that the scanning of the files on my NAS is really slower than before.
It takes minutes to complete the scan of a little less than 70k tracks available in the four main folders configured in the Storage section of Roon settings. I didn’t modified or added files recently.
Moreover, after ROCK is powered on, it takes time before Remote is able to connect.

Is there any explanation about this increase in the scanning duration ?

Edit :

Done another test with a stopwatch.

Starting Core, Remote has to wait nearly 4 minutes with this screen :

Annotation%202019-12-02%20083808

Then I have to wait another minute and a half for all the folder scanning to complete.

Before the update it was easily four times faster.

Hi @AdZero,

I have merged your two threads because I believe these two reports to be related.

I am looking over logs that our servers have received from a few days ago and I am noticing issues with Roon starting properly.

I wonder if this could be related to the database, I suggest that we perform a test here to help clarify. Can you please:

  • Manually send me a copy of your current ROCK logs by using these instructions
  • Create a Backup of your current database
  • Stop RoonServer from running in ROCK’s WebUI
  • Navigate to your Roon’s Database Location
  • Find the folder that says “RoonServer”
  • Rename the “RoonServer” folder to “RoonServer_old”
  • Restart the RoonServer in the WebUI to generate a new Roon database folder
  • Let me know if similar issues occur on a fresh database (do not restore the database).

Thank you.

Hello @noris.

Before I try your suggestions, can you confirm the effect of starting from a fresh server database ?
I fear that I will loose all my added Tidal content, history, playing stats and metadata customization done the last two years…?
If that is true, I’m not so keen to do that permanently.

Hi @AdZero,

Yes, this is correct, but this is a temporary test. I requested that you perform a Roon Backup as the first step before starting the process:

This backup should get you back to where you currently are, and if there is an issue with the backup,you can also rename RoonServer_old back to RoonServer to get your old database back. My thought process here is to eliminate any possible variables in the database causing this behavior and setting it aside using the above instructions would give us a good data point.

OK @noris

I’ve just proceeded with your instructions and started listening to MQA Tidal content and… playback stopped after 12 seconds !
I tried to reboot the Core completely, not only Roon Server and tried again. Playback stucked again after a few seconds… All of these happened between 18:17 and 18:23 approximately.
Switched to non MQA album on Tidal and I was able to listen to four tracks without problem… (still playing)

For the other problem, I must configure my network shares to scan my local files and test the scan performance. I disabled audio analysis, but track import takes time… So I will go on later If it still worth it as the first problem isn’t related to a database problem. Please let me know what to do regarding this problem.

Roon and RAAT server logs where added in the folder that I shared with you yesterday.

Hi @AdZero,

In the logs on your OneDrive I am noticing some issues, it appear that RoonServer is restarting fairly often, I’m not exactly sure why, but this could be a database issue. The folder titled AdZero.RoonServer.Logs.201912031847 is from before setting the old database aside, correct?

I am looking for the folder which contain the logs after setting your database aside, but I am not certain that I have the right one here as I only see one RoonServer and one RAATServer in the OneDrive you uploaded, can you send the new set?

Also, I would like to kindly request your database for closer inspection, can you please use these instructions to send this over?

Hi @noris,

I confirm that zip log files ending with 20191203 are from before the “reset” of the RoonServer database.
The other files ending with 20191204 contains the test database files.
You should be able to see these new files as I checked again online this morning.

I made a few stop and start with the server to test the database switch and to compare playing behaviour. Maybe that’s why you see a lot of restart in these logs. Moreover, my core is only on when I actually listen to music. It is powered on/off at least twice a day.

I’ve zipped my “real” database folder for inspection. Files are uploaded.

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.