Nucleus Plus slowing down

Roon Core Machine

Nucleus Plus Rev A, no modifications
OS build 259, Core build 1321 earlyaccess

Networking Gear & Setup Details

Ubiquiti UDM Pro and Unifi switches. Endpoints and are all wired with Ethernet. Fast internet connection (850Mb up and down) with 2ms latency to major sites.

Local songs are stored on a Synology Diskstation. Two shares are connected to Roon (one for the main library, the other just for DSD files).

Connected Audio Devices

USB from Nucleus to SMSL DAC, grouped with Lyngdorf MP-60 (Roon Ready, connected via wired LAN). I’ve also tried AirPlay to various devices (BlueSound, MP-60, Savant music player)

Number of Tracks in Library

30,000 tracks / 2,200 albums

Description of Issue

My Nucleus has recently slowed down when playing mixed playlists (I noticed it on a particular tag in my library that has a broad mix of old stuff from my library and stuff from Qobuz, with lots of format changes). It seems to get worse with time, resetting after a reboot.

Advancing to the next song is usually quite speedy. But as time goes on, gaps seem to grow. It eventually takes 15-30 seconds to advance to the next song. It’s possible that it only gets worse if I play songs through (skipping through lots of songs one at a time with the “next” button doesn’t seem to slow it down), so maybe it’s related to updating statistics for songs that have played through? I believe that format changes (44k to 96k, for example) are the most problematic, but that’s a bit of a guess. :slight_smile:

I’ve been looking through the log files, and every time there’s a slowdown, it’s accompanied in the log by a library endmutation entry (“Trace: [library] endmutation in xxxx ms”). The time (xxxx) is always the length of the delay between songs (as seen between “Advance_” and “Playing” log entries for the zone). It’s like the Advance_ directive starts a database update and the next song won’t play until it’s done updating, which somehow takes 5-digit ms times.

The Roon UI also seems to slow way down when the problem is active. The home screen can take 15 seconds to load, and the queue can take minutes to display. It’s very frustrating.

My Nuclelus has been configured and running for many years, so maybe it’s time to reset and reload the data? I have another Roon setup in another location running on an M2 Mac Mini, and it does not seem to have these problems with an identical library and very similar infrastructure. But I haven’t played extensively with that setup to test this.

Note that this problem also manifests with AirPlay zones: the endpoints seem to time out waiting for the song to advance. So instead of delays between songs, AirPlay just stops after every song. I’ve tried grouped endpoints, ungrouped endpoints, different endpoints, etc. Once the problem happens, it seems to happen everywhere.

UPDATED EDIT: I’ve verified that the next-track slowdown happens only when the music format changes (44k to 96k, for example). After a reboot, the delay is just a few seconds. But as time goes on, it gets to more than 30 seconds. From what I can see, it seems like the Nucleus is essentially blocking processes for 5-25 seconds before it even attempts to read the next file.

1 Like

@David_Roberts, can you post a screenshot of your Nucleus’ WebAdmin screen? Given the age of the Nucleus, two ideas come to mind. The Nucleus SSD holding your Roon database may be reaching capacity or getting old and beginning to fail.

1 Like

I should add that there are lots of endmutation entries with less than 100 ms entries. I’ve only seen long (>5 sec) entries during startup or when this slowdown happens.

Mine looks identical, also rev A I also have a Synology NAS
All same versions as yours. (Now deleted screen shot)
Not noticed any problems but then I have been playing CD’s the last week or so.

If running Early Access you should normally post issues in #early-access unless the issue also occurs with production versions. But I guess this issue is sufficiently muddy and moderators will make a call :slight_smile:

Although if it is actually an issue with EA it would be better if developers saw it in EA to fix it before it spreads

Good point, I didn’t think about posting there. I do believe this has been happening for several releases though. I’ve just noticed it more because I’ve been listening to tracks lately (instead of Live Radio via Roon, which I typically do at this location).

1 Like

I can’t be sure if this is due to Early Access or not, so I’m posting here. I discovered this issue while trying isolate a problem where my Nucleus Plus had 30 second delays (or more) between playlist songs. This is repeatable on both my Nucleus Plus and my M1 Mac Mini, both on early access builds (1321).

In essence, it appears to be 2 problems:

  1. When tracks change, Roon processes library “profilestats” that are presumably related to both the current player profile and the completed song. Over time (just a few songs), the processing delays to do this get more pronounced. When I had my now-deleted original profile directing things (it was the primary profile on my account for years), the processing of profilestats went on for 30 seconds or more.
  2. That problem might not be so bad except that when music formats change between songs (from FLAC 192 to FLAC 96, for example), the Roon core seems to be blocked from doing many things (like loading the next song) until the database update completes. This does NOT happen unless the track formats change (the delays still happen, but they don’t block queuing the next song unless there’s a format change).

Steps to repeat:

  • Create a playlist or queue from two or more albums (local or Qobuz) with different bit depths. All the songs should be in the Library.
  • Reorder the playlist to alternate between formats for each song.
  • Play the list, taking care not to just “NextSong” through each entry because that doesn’t appear to engage the profilestats the same way
  • Watch log entries for music/profilestats and subsequent library endmutation entries grow longer. On my Nucleus+, these grew pretty fast. They seem to grow more slowly on the M1 Mac, but they still grow.
  • Once the delays are long enough, you’ll be able to hear the delay, as well as seeing the Remote client go into a “waiting” state where the play bar busy-flashes as it waits to advance to the next track.

Other observations

  • Rebooting the core resets the delays back to manageable (less than 1 second) levels.
  • If a playlist item was added by an old (i.e. big and bloated?) profile, the updates can take more than 30 seconds. With a clean profile, they still climbed to more than 5 seconds in a couple hours on my Nucleus+. This was entirely dependent on which profile (bloated/old or new/clean) added the song to the playlist. Even with the same playlist.
  • On the M1 Mac mini running as a dedicated core, for example, it only took a couple hours of music to get profilestats log time of 800+ms with subsequent endmutation time of 1500ms. That’s more than 2 seconds in total. The Mac itself doesn’t appear under any performance pressure at all (memory, disk, cpu, network all at very low utilization).
  • I don’t think any of this happens if I just play a Qobuz playlist (where none of the tracks are in my library).
  • Once blocking happens, lots of other weird timing problems manifest depending on which endpoints I’m using. It can, for example, make one of my AirPlay clients just stop between songs every time the format changes.

Both setups are running in clean network environments, using Ubiquiti infrastructure and wired endpoints. It happens with any endpoint (I’ve observed with RAAT connections to SMSL DAC, Matrix Element X2 DAC, and Devialet Phantoms).

Hello @David_Roberts !

Thank you for the detailed report! We appreciate this a lot.

We’ve tried to reproduce your issue locally but unfortunately, we don’t get delays between tracks on our end.

Can you please upload your RoonServer database so that we can try to reproduce the issue with your setup more precisely?

Please use the following instructions to upload your database:

You can upload it here:
https://workdrive.zohoexternal.com/collection/gnhz54df9ddffa33d49a3be8619bd6376a5de/external

Gentle reminder of something similar though not so extreme and perhaps different causes, but also gaps in playlists. I provided logs back then and apparently there is a ticket: B1212 Gaps within playlist caused by apparent buffering at start of next Qobuz track [Ticket in]

1 Like

Hi @David_Roberts,

I’ve moved this to #early-access for consistency, but we’ve identified that you’re encountering a known issue present across both branches.

Do you have IPv6 enabled in your UDM? If so, try disabling it as a workaround in the meantime and let us know if that eliminates any performance issues.

Additionally, try disabling any of Roon API Extensions that you might in use with this account. Uninstall them temporarily and see if you’re able to improve performance.

We’ll stand by for your response. Thanks!

Hi @Suedkiez,

Thanks! We do have an open ticket for the issue you reported after reproducing. We can’t repro this yet, so we’re not positive it’s the same.

1 Like

Hi,

In response to your earlier questions:

  • IPv6 is disabled on my two WAN connections (has been forever)
  • I did upload the database
  • I had the AppleTV remote extension running, though it wasn’t being used. I’ve disabled it now

Still seeing slowdowns between songs when formats change.

I’m going to replace the Nucleus with a Mac Mini this week. If it has the same problems, I’m hoping they won’t be as noticeable with the beefier machine.

Your Roon Database & Settings readout indicates that your 55 GB SSD is 36 percent full. That is a 20 GB database for only 30,000 tracks. Something is amiss with your database and/or music library.

AJ

1 Like

Seems like a lot, but I’m not sure what’s stored there. Years worth of play history? Temporary metadata downloads for the library? Stats operations seem to take a long time, so that leads me to believe there’s clutter somewhere.

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