My music library contains around 100,000 files (5500 albums). I have tried the following configurations with Roon:
Roon on an iMac (i5 3.3GHz) - Roon to HQPlayer (up sampling to DSD) to Micro Rendu to Chord 2Qute DAC
Roon Server on Mac Mini (i5 2.5GHz) - same configuration as above
Roon Server on Intel i5 NUC - same configuration as above
All network connections are ethernet.
In all three configurations, storage is DAS, connected directly to the respective computers that are running Roon. File additions (many per day) are prepared (downloaded, ripped, tagged, etc) on the iMac. Where the Roon Server is used, I move files from the iMac over ethernet to the DAS connected to the server.
In all three configurations, there are very few drops (usually corrected by adjusting HQPlayer), so there is no issue there.
The issue is that, in the server configurations (2 & 3), Roon itself is very slow. Loading an album can take nearly a minute and searches even longer. This occurs primarily directly after adding a file. I know that moving files over the network is relatively slow and that Roon has to process the album and look for metadata, but I am finding this slowness to persist well after the newly added album is identified. On one occasion, in the NUC configuration, Roon completely froze.
I don’t have these issues in configuration 1.
Is this normal behavior in a server environment, or is there something in my setup that I’m missing? Is the problem related to the size of my library or something else?
Just to be sure, when you say this, you mean that you are also running HQPlayer on the same machine. Well, there are a number of things I would do, begin by simplifying your setup. Alnd you didn’t specify your storage nor how it was connected to these machines, nor, what OS was on the NUC.
turn off HQPlayer completely remove it from the chain, reboot, and then test if it is slow. If it speeds up then split Roon Server and HQplayer onto different machines.
Copy some files to an internal Storage location, disable the DAP storage and just use the internal storage, test to see if things speed up.
Run a system monitoring tool to watch RAM usage, CPU Usage, and connection/network saturation to give you clues as to what may be causing issue.
100k is getting close to the "you really should be using an i7’ threshold.
Yes, HQPlayer is on the same machine. The NUC is running Linux Mint. It has 16g RAM. Storage is Thunderbolt on Macs USB 3.0 on NUC.
I have tried removing HQPlayer. I will try the other things you have suggested.
Your last statement (4) leads to what I think is the real issue. Is it more beneficial to increase the RAM to 32g on the Mac or move to an i7 Skull Canyon?
To answer your question directly, 32 GB is overkill, imho. The fastest i7 in terms of single core speed is what I would get.
However, I would wait until 1.3 has come out before investing in any more hardware.
I am assuming that all these machines have SSDs for the OS drive, one of the best ways to speed up Roon is to have the OS, and by default the Roon database, on an SSD. That said, when you are looking for a new computer, get an M.2 SSD. The extra speed is useful in Roon’s case.
If you are just using this for Roon, I would suggest taking the NUC and loading Windows 10 Pro 64 on it. Roon is native .NET code which Mono is used to get it to run with Mac and Linux. So, asfaik, there is an overhead to running Roon on Mac and LInux which Windows does not have.
Interesting. I was under the impression that Linux would perform better since it has less overhead in general than Windows 10. That’s the reason I loaded the NUC with Linux.
I have read of problems with Macs, especially with larger amounts of data.
I was not trying to imply that Linux doesn’t run well. It can and does; although I prefer Ubuntu 16.04 server over Mint. Not being intimately familiar with Mono I assumed that it was not as efficient and thus adding processor usage over the Windows native implementation. Which was in part based on this forum comment:
Although Mono does perform well, many components (most notably the GC) on the Microsoft .NET perform much better. This gap is shrinking since Xamarin was acquired by Microsoft but it is not the same still. Our customers with 300k+ tracks are pretty much required to use Windows right now.
I am in the process of installing Windows 10 Pro 64 on the NUC and will see what happens. As I stated earlier, I have no slowness issues when Roon is run directly from my iMac. The slowness that I have seen occurs after adding new files to the storage (Thunderbolt on the iMac and Mac Mini, HDD on the NUC, all directly attached). I have also replaced the 2.5 inch SSD on the NUC with an M.2 SSD.
Unfortunately, everything I have read on this forum and elsewhere indicates that with close to 100,000 tracks, I need a more powerful machine to act as server.
Clear. I just got the impression from the OP that he thought Linux (or Mac for that matter) is a bad idea in general, but he made it clear that was not his idea at all.
@danny: just out of curiosity: are you guys looking with one eye at the efforts from the .NET Core team? We’re playing around with it, and I have to say I’m really impressed so far. I can imagine that for a product like Roon it’s just ‘not there yet’, but none the less for RoonServer or RoonBridge this could be on the horizon… or not?