Random playback stoppage - Roon memory usage climbs - after switching to Qobuz

Roon Core Machine

HP Elitedesk 800 G2 Mini (Dedicated to Roon Server)
Intel i5-6500t processor, 3.2 Ghz base frequency, 6 MB cache, 4 core, 4 threads
8 GB RAM DDR4
250 GB WD M.2 drive (229 GB free)
LinuxMint 21.1 Vera x64
USB connected 500GB Seagate GoFlex HDD (Local Library files)

Networking Gear & Setup Details

Gigabit fibre to the house; ISP provided ONT (Nokia ?) → ethernet to ISP provided Actiontec T3200m router → TP-Link TL-SG108 switch → ethernet to HP server. Server connects to endpoint via the router MoCA, no wifi.

Roon remote installed on HP Chromebook (Play Store installation) and Samsung A53 phone. Remotes connect via wifi.

Connected Audio Devices

Ethernet (via MoCA) → D-Link 5 port switch → ethernet to Raspberry Pi 4 (VitOS-1.0.1415) → USB to Topping Isolator → USB to Matrix X-SPDIF 2 → SPDIF to MHDT Lab Istanbul.

Number of Tracks in Library

12992 tracks

Description of Issue

This system had been performing well with very few issues while subscribed to Tidal. Believe it or not, after I subscribed to Qobuz recently (new Canadian subscriber) within a couple of days I would get occasional stoppage of music playback.

When this occurred, the Roon remote would show the album/track playing had vanished. After a minute or so the album would reappear and pressing play would restart the track from the point it had stopped. While the album was missing, clicking Qobuz on the menu at left would not show any content. It was as if the connection to Qobuz was dropping.

Playback would continue for minutes, sometimes hours, and then stop again.

I initially believed this to be a network issue. Rebooting the ONT, Router, and TP-Link switch (in order) did not resolve things. Rebooting the server would see the issue stop, for a couple of days (not sure of actual duration) and then playback stoppage would reoccur.

I’ve now noticed that memory consumption slowly climbs; eventually the system starts using swap which doesn’t occur for hours after a reboot. Memory usage after a reboot is 1.8 GB, it is currently at 2.5 GB. The other day memory usage was about 5.5 GB before I rebooted. I’ll try and keep tabs when the playback stoppages start happening again. I do not believe the system is rebooting spontaneously, as the remotes are connecting to the Core when this happens.

Hopefully this explanation conveys what’s going on here. It’s not a show-stopper because it is temporarily fixed by rebooting, which is my current workaround.

Suggestions welcomed, I may have missed something somewhere.

2 Likes

Because you had it running with Tidal without issues my first thought is that Roon is building the database with new metadata from Qobuz in the background. That can take a while. You could have look at the settings for this to set it to only scan minimal while playing.
BTW, the memory filling up is a normal procedure on a Linux machine.

Ok, I’ve set both analysis settings to “Throttled”. Before was “Fast” and using 2 cores.

I’m not sure how normal this memory consumption is, remember I’m reporting this wasn’t an issue with Tidal. Same OS. I can look into scheduling reboots to make this hands off, but it’s still a workaround.

Thanks for the reply.

Sounds VERY similar to my problem…

1 Like

I’ve continued monitoring as much as I can what the Core is doing. I added more RAM for a total of 16 GB. The behaviour didn’t change. I clearly have no clue what is going on. For the fun of it I increased the priority of roonappliance, without improvement.

The RAM usage in and of itself might not be an issue, it should be able to cruise at around 80%. I had thought RAM might be involved since Swap was being used, about 25% of it. After the RAM was doubled and the symptom reappeared, I saw that 25% of Swap had been used again. That was puzzling because I wouldn’t expect it to need Swap.

Finally I was able to watch top while the symptom occurred a few times. Each occasion saw the cpu getting 3 of 4 cores pinned, which is how I interpret top showing 300+% cpu utilization. I don’t think this is because of background analysis, as the dedicated Core runs 24/7. Plenty of opportunity to scan since I moved to Qobuz, and the library isn’t all that large.

As for Swap, I read that LinuxMint will Swap aggressively by default. I don’t think that’s needed in my application, so I followed the instructions to reduce the tendency to access Swap. That was yesterday and I’m still waiting to see how long it takes to hit Swap again.

So far so good, and if I can go three days without the symptom reappearing that would be nice. Memory isn’t climbing as quickly right now.

2 Likes

After three days, things have been normal. Kind of hard to believe that the changes I made caused the improvement. Will see how things go.

Hi @airdronian,

Thank you for your patience while the team worked through the queue to reach your request. We’ve assigned this thread and will keep it open for several days to verify that your issue hasn’t recurred.

Ok, thanks. I am encouraged by today’s result.

After 6 days things are good. Nice and stable. I still have my doubts this issue was due to library analysis, the library is not that large and Qobuz has been the sole streaming service since April 19.

The memory filling up is not normal procedure on a Linux machine. Yes, the kernel may build up increasing disk cache (“buffer”) but that will in no way be reflected as the working set of the RoonAppliance process. Also, “buffer” is not actually memory “in-use”. (Windows has very similar features and then also prefetch as well)

Hi your CPU usage observations prior to/during stoppages closely match my description here Very regular 2-minute drop outs / need manual restart. As a data point I also use Qobuz and my database has been complete/stable for a loooong time (so it is and wasn’t building the initial database).

Sadly the problem reoccurred since yesterday, so I’m back to monitoring the vitals for a while… (see 2 minute drop outs and resource leaks are back)

1 Like

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.