@Suedkiez yes the N1 came with 4gb and that was a joke. The N1 was useless. Some of the Roon staff clearly advise to upgrade the memory. I had a 32gb stick lying around and used it. I just 
and hope we one day will be back to the quality of the 1.8 version. Until then I will keep on rebooting.
Can’t find this post with such a recommendation in a quick search, but @danny, who designed Roon OS, wrote many, many times on the forum that it simply crashes if it runs out of memory, and if it doesn’t crash, more memory will do absolutely nothing. (Roon OS doesn’t swap RAM to disk).
Anyway, it won’t hurt, it cost you nothing, and RAM is not your problem. Nor should the N1 hardware generally be, with 80k tracks. Sounds like a software/library problem.
Same issue here…fast for a few days, then slowing down. Only 2400 albums (mix of ripped CD’s and Qobuz albums) and less than 35,000 tracks on a Nucleus Plus. Always faster after an update, then slows down again.
@Suedkiez what kind of library problem? I have about 2000 local albums and little over 5000 Qobuz. 70 albums of the locals are unidentified. Should I take a disk utility check on my ssd? I am open for any suggestions.
Probably only addressing 16 GB.
Then I’m on the safe side.
7,000 albums on a Nucleus ONE must be pushing it to the limits.
About 80000 tracks is 20000 short to maximum
Only 80k, I expected more than an average of 11 tracks per album. You should be good for a while.
Nothing specific and nothing that seems to be your fault. Something must be wrong somewhere and I would guess it’s in Roon that somehow gets tripped up by something in your library. But it’s just a guess because I, and many others, don’t experience this. And I’m not doing anything special.
This is perfectly normal, of course, and should be within the N1‘s capabilities according to its published specs.
It can’t hurt (except that you need to remove the SSD and then need a lowlevel SSD check tool that can deal with the ext4 file system that is used by the Linux kernel in Roon OS).
As the database gets largely loaded into RAM during operation, I’m doubtful that an SSD issue would manifest in performance problems. (Unless, of course, there are data errors on the SSD that corrupt the database, but I think this would manifest in Roon refusing to create a backup due to database corruption).
I believe this is something that only Roon support can figure out by analyzing your logs and perhaps a database upload. I can’t see any support ticket that you ever created specifically for this performance issue. You should.
@Suedkiez it’s an external ssd so I thought I could connect it to my Mac and use disk utility.
I was thinking of the internal system SSD. I’m confused but may not have paid enough attention - how is an external SSD related to performance problems? Do they go away if you unplug it from the Nucleus?
If it’s exFAT formatted, I think Disk Utility can perform basic checks/repairs for partition errors and directory corruption, but Disk Utility in general is not a low-level SSD error check tool. SSDs are internally extremely complex and have their own internal firmware that handles all the dirty reality, while presenting a sane standardized disk interface to the outside world.
You may try a dedicated disk health checker such as
The manufacturer of your SSD may offer their own tools, such as this from Samsung:
I created a support ticket. Thx for feedback
This is confusing “crashes if it runs out” and “more memory will do nothing”. If there is more memory, doesn’t that mean that it won’t “run out” as easily?
I just switched to a fast-ish stripped-down Windows 11 box with 32GB of RAM and a 1TB SSD for the DB, and I’m seeing 50% RAM usage with a 32GB DB size. That also suggests that more is better, RAMwise.
(I’m also noticing fast performance and then slowdowns within a few days of boot, but I’l wait to open a ticket until I have a month or so of data and time to think about it.)
Weird thing just happened. My internet accidentally shut down for a few seconds and all stereo, computer, and tvs shut down. When it came back up, Roon so much faster. Hope it stays this way.
No idea what happened.
If I understand correctly, the comments about crashing when memory runs out or more memory being a waste if not crashing, only applies to RoonOS (ie Nucleus and ROCK).
Someone can correct me if my understanding is incorrect.
Sure, but if Roon OS does not crash (due to an out of memory condition) then it doesn’t run out, and adding more RAM won’t do anything. „Do nothing“ specifically referred to „making it faster“ or „doing anything useful“.
If a specific Roon database needs, say, 3 GB to be held in RAM together with the necessary OS services, then having 8 GB on Roon OS will just leave 5 GB empty doing nothing.
Now, of course a little headroom (or let’s say even doubling the predicted need) is good for future growth and to prevent an out of memory condition just because something in Roon needs more RAM than was expected. But 32 GB is wasted on a database that needs 3, on a machine that will be far too slow to run a Roon database in a satisfying manner when it grows to really needing 32 GB, due to other constraints like CPU speed.
And this added RAM that’s sitting there empty just for safety won’t make it faster - that’s the important part here.
Roon OS is not Windows. Everything that was said about this applies only to Roon OS.
Windows and other generic OSes swap RAM content to disk based on complicated algorithms. That’s necessary because on Windows the user can always open another program that needs additional RAM to run. This is also the case in a general-purpose Linux (and Mac of course, though on Macs with Apple Silicon it’s a little different these days because the memory architecture is so fast that the access speed difference between RAM and SSD disk is starting to converge for many practical loads. Nevertheless the same principle still applies. Of course, SSDs as opposed to spinning disks have a similar positive effect on machines using PC/Intel architecture, but not quite the same as on Apple Silicon).
This can make performance somewhat unpredictable - a Windows machine with too little RAM for the tasks will still run, but it will be slow. If the user (or the OS itself) switches between different programs, a program’s swapped-out memory will have to be read back from disk into RAM, and another program’s memory will in turn have to be swapped out to disk, because RAM space must be provided to the program that needs it at the moment (e.g., because the user brought it to the foreground or because the OS has something to do in the background). All of this swapping work puts additional load on the CPU, on memory buses, etc., which then have less time for other things.
However, in Roon OS this swapping out to disk was turned off on purpose. The user can’t install or start anything unpredictably, the processes that can ever run on Roon OS are perfectly known at design time, and the RAM requirement scales predictably with Roon database size (barring any unintended events like memory leaks or unexpected design errors in Roon that lead to more memory usage than planned). Therefore, in an out of RAM condition where Windows would start to swap to disk and become unpredictable, Roon OS is designed to just crash.
Therefore, with a given iteration of Roon and a given size of database, Roon OS will either run or it won’t. There can’t be any slowdowns caused by the OS‘s memory management swapping RAM out to disk with its slower accesses, because it just doesn’t do that. (Of course there can still be other slowdowns due to overly complex tasks or inefficient programming).
This is a good thing, provided that Roon developers stay within the expected, designed memory limits, because it eliminates a whole complex class of possible performance issues - the performance of the machine’s memory subsystem is perfectly known and predictable at all times.
And it’s important to understand that the ONLY reason why adding RAM to Windows (or Macs or generic Linux) can make it faster is the prevention of these RAM to disk swaps. A program needs as much memory as it needs.
But even on Windows, if the OS services and all programs you will ever run at the same time need a maximum of, say, 64 GB, then having 256 will still do nothing. (For a while, Windows will allocate otherwise unused RAM for file caches and so on, but even this has its useful limits).
There are, of course, other things that can cause slowdowns even if there is more than enough RAM. Some algorithm in Roon may just have poor performance in some conditions or whatever.
@HeavyMetalDrummer and others…
If you have log files, and you’d be willing to share I’d be happy to dig through them. We have started a directed effort to track down and improve performance starting with 2.65. We are just getting started and there are already more in the next major release. If I can figure out what is going on with your log files I might be able to improve the system(s) affecting your performance.
Thanks for the explanation. I didn’t realize you were talking about RoonOS exclusively.
Can you move this part of the conversation to another space, so that we can talk a little bit more about Roon’s actual requirements without my continuing to pollute this thread?
Maybe the mods want to move it, I can’t. But happy to continue elsewhere if anything is left to say after that wall of text 