Nucleus One Performance and Reliability Improvements

Tinkering
1

I’ll mark this one as “tinkering” since it’s of my own doing.

Disclaimer: I performed this update of my own accord without guidance, advice, or approval from the fine Roon team. This probably voided my warranty, and with that I am fine. Proceed at your own risk.

I started having problems with my Nucleus One the larger my library became. I can’t compete with many of you, but my library is up to around 150,000 tracks now. Roon software has a an audio analysis feature that you can find in Settings > Library > Background Audio Analysis. This setting is on by default. When the server got about 1/3 to 1/2 of the way through the library, it would be one unresponsive and drop connections to end devices, spontaneously reboot, and other such annoyances. I suppose I could have disabled the feature, but it’s there so why not use it? I never experienced these problems when running on desktop-class computers (Windows, MacOS, Linux) so wondered if this could be a hardware resource issue with Nucleus One.

So I grabbed my favorite screwdriver and dove into the innards of my Nucleus One. After a few screws removed, I noted that the appliance has 4GB of memory along with a 128GB SSD. Plenty of hard drive space for the casual user, but wondered if I could realize some improvements with a memory upgrade.

A quick call to Amazon brought me a Crucial 16GB RAM module which replaced the other in a few seconds. After clearing the library database from the Nucleus One’s Roon web interface and a fresh software reload, I was off to the races.

I connected my external USB drive, mapped the storage location, gradually bumped up the number of CPU cores to four on the Background Audio Analysis feature, and let Roon do its thing. It starting chewing through music at a pace I hadn’t experienced in its previous configuration. The import occurred quickly, and the music processing was nearly complete when I woke up this morning. The server never glitched, burped, or stopped playing music while using it during the import.

For US$25, I wholeheartedly see this as a worthy upgrade for Nucleus One. Your mileage may vary, and your warranty may be affected. So if this is something you’d like to try, evaluate your tolerance for warranty before proceeding.

~Chris

Crucial 16GB DDR4 3200 MHz… https://www.amazon.com/dp/B08C511GQH

IMG_1735
IMG_17351512×2016 1.43 MB

IMG_1769
IMG_17693024×4032 2.84 MB

IMG_1780
IMG_17803024×4032 3.11 MB

1 Like
2

Roon OS doesn’t swap. Whatever the reason for the change, it wasn’t more RAM that made it faster. See the links to the official Roon staff posts linked from this post:

3

I guess I just got lucky then. Because it’s been a total dog lately, crashing, etc. Now it works great. Placebo performance increases may be a function of the fact the the system is performing reliably now. Maybe a memory reseat would have resolved it? Either way, I’m a happy listener now. :smiley:

1 Like
4

Crashing is a different thing. Roon OS does crash if it doesn’t have enough RAM for the size of the database and/or the operations it performs. If it crashes a lot, then it’s definitely recommended to add RAM.

Remember that the Nucleus One specifications say that it’s expected to work with up to 100k tracks, but you have 50% more at 150k, so it’s definitely possible, even likely, that you ran out of RAM and this crashed it.

It’s just that if Roon OS has enough RAM for the database size, then any extra RAM will just go unused and not speed it up.

This is different to the general-purpose operating systems that we all know, like Windows, macOS, and common Linux distros. If those don’t have enough RAM for what they are doing at a given time, then they swap RAM content out to the hard disk, keeping only the recently used data and code in the RAM. As RAM is much, much faster than disks, this makes the system slower when RAM is full, but it doesn’t crash because of maxing out the available RAM. The price is that performance becomes unpredictable if one doesn’t watch the RAM and ensures that there’s enough for the typical tasks at hand.

It’s certainly possible that something was wrong with the original RAM stick. However, you wrote that you cleared out the original database on the Nucleus and started from scratch, so it’s also possible that there was something wrong with the database, possibly caused by previous crashes.

5

Thanks for the additional insight. I was unaware of the 100K track number, so I appreciate that extra bit of information. I had indeed cleared and rebuilt the database many times and it did start to see problems when the census increased beyond that threshold. So your detailed description certainly aligns with the symptoms. Now that I know the limits, I’m (cautiously) looking forward to seeing how much farther I can push the platform.

I’m surprised that I wasn’t able to find previous discussion on the topic through (what I thought was) pretty extension search. Many thanks for taking the time to comment and add clarity to the architecture! Hopefully this will make it easier for folks who experience similar problems to find a resolution.

2 Likes
6

I’m sure your detailed description of the steps will help others, too :+1:

The 100k number is obviously not a hard limit, it’s just what Roon Labs felt comfortable recommending because they expect it to work for nearly all users.

With 16GB it’s nearly sure that you won’t run into a RAM limit again. Only the largest of large libraries (and we are talking 500k tracks or more) need more than that on Roon OS, and at that size you are probably going to run into performance limitations before the RAM runs out.

The performance depends on specifics of the library structure, and it will be more of a gradual decline and you will notice if it becomes too much. With a library that follows a typical structure, you can probably stay happy with much more than 100k tracks on a Nucleus One.

(Known factors that contribute to additional hardware demands are: large numbers of unidentified albums, artist folders with hundreds of albums in them, albums folders with hundreds of tracks in them, Roon tags with very high numbers of tagged items).

2 Likes
7

As a side note, I’m using locally attached (USB) storage. My next phase of the project is to use NAS storage to make adding music a bit easier. If there are any changes in performance related to that (network latency versus direct connect), I’ll be sure to note it here.

8

Just be aware that NAS storage doesn’t always notify Roon when new music is added, so it may be necessary to run a manual scan periodically.

1 Like
9

It probably won’t. The performance limitation is predominantly related to the database performance on the Roon Server.

1 Like
10

@CHZRNR - In case you missed it, there’s a Help article on RAM upgrades/SSD replacements for the Nucleus…

1 Like
11

I absolutely did miss that article. Thanks for sharing! Looks like I need to dive into the help article collection to see what else I can do to optimize the system.

12

I finally had the opportunity to get the NAS stood up and connect it to Roon. It behaved exactly as you described it. After I got all the music ported over, I bought a couple albums from Bandcamp and copied them to the storage location. Roon did not pick it up automatically. Running a manual scan took less than two minutes for 146,000 tracks. It picked them up right away and added them to the library. Thankfully the music library isn’t updated often or by anyone but me, so I’ll just need to do a rescan when I upload new music. Easy peasy.

2 Likes