Roon on macOS not working with huge library


I tried to use Roon for large library of 70k albums (DSD, HiRes, and CD in AIFFs).
After completing the import of all albums Roon took 5 min to launch, 3 minutes to search anything, 1 minute to start playback of a song, and was having dropouts on playback of any song. Set-up: 2015 Mac Mini, i7, 16GB RAM, 512GB PCIe flash SSD, OS X El Capitan 10.11.6, music on Synology NAS and internal PCIe SSD.

I decided to erase macOS, re-install Roon alone on Mac, import music from zero step by step.

  1. I imported first 10k albums - all was working perfect: launch of Roon on macOS, search, start & running of playback on 5 endpoints simultaneously, importing & analyzing of new tracks - all at the same time smooth, fast, and without dropouts.

  2. I imported totally 25k albums - now it takes 2 minutes for Roon to start, search of any artist takes from 20 seconds to 1 minute, music plays with 3-4 dropouts per song, stops, and jumps to next song. That is happening exactly same on songs locally stored on PCIe SSD or on Synology NAS - so it is not NW issue, and I can’t have much more powerful HW for macOS (unless go for MacPro, but I doubt TOP TOP HW is the issue here). If I restart Roon, then after launch it plays w/o dropouts, but after some time dropout problems re-start. Start and search is now always very slow.

  3. I’m continuing to add music files to the library and will report progress how system is performing when reaching 70k albums to be imported.

At same time JRiver on the same library, HW & macOS is one second fast to launch, 3 second to find search, and instant start of playback without dropouts.

For reference - another Roon user having similar size of library just migrated from Roon on macOS (because of same problems) to similar HW configuration on Windows, and now the Roon server is running fine.

So seems, Roon is having database search, and playback shortcomings for very large libraries specifically on macOS.

Also, think about music streaming services like Tidal that can handle simultaneous searches and playbacks from millions of users in fraction of second without dropouts.

I just love magic music exploration experience with Roon, but how to get it to work with large library on macOS? I could, but really don’t want to set-up another Windows Roon server to fix the issue…


1 Like

70k is an extreme library I would say. It will be hardware vs library. Roon does a lot more than other music apps so you should expect differences. Not really sure you can really compare local performance with something like Tidal.

@brian might want to take a look. There may be some specific hardware recommendations for your library.

1 Like

I am experiencing the exact symptoms using either a MacPro with 64GB memory and 512GB SSD, or a SonicTransporter with an i7 and 256gb SSD as servers. I also have a CA Zuma 16GB with 256GB SSD running Windows 10 that performs flawlessly when used as a server. My NAS is Synology 1815+, the library size is smaller than Janis with 40K albums, 604,000 tracks.

There may be differences between OS and Win here as I also run a NUC on Win10 with 30k+ albums and it has no issues at all.

Give the team a chance to comment and provide some guidance.

Jesus! How on earth can you listen all this music in one lifetime!?

1 Like

30k albums imported.
Roon server on macOS stopped performing. Dropouts and jumps to next sound each 10 seconds.
Gives message like this.

Please let me know if there is way to get it to work on macOS. Or shall I move the server to Windows 10?

Hi Janis,

70k albums that’s quite some music collection and may welll be pushing Roon so I’ll leave a flag for @support to follow up with you.

In the meantime this may help:

Roon performs audio analysis on each new track added to the library … It’s quite a heavy operation to perform and can take severial days to complete … however the results are only used if volume normalisation is activated.

So as an experiment try switching off background audio analysis to reduce the work load of Roon and your NAS and network.

Hi Carl,

I’ve turned off audio analysis and it makes no difference. I still get frequent dropouts, approximately every 20-30 seconds. I frequently get the error message Janis posted with skipping to the next track. This happens with both OSX and Linux, however, Window 10 works great, even with audio analysis turned on.

Thank you Carl!

Same with my OS X set-up. Audio analysis doesn’t have any impact.
On <15k albums both with on and off all works perfect, but with >15k issues start in the OS X version when server has been running for some time.
When restarted with 30k albums, it plays OK without dropouts and analysis on for some time but after 6-12 hours of adding some more albums dropouts start again and are very often.

As mentioned very large library works fine on Windows 10 server with both background and on-demand audio analysis switched on to FAST and not finished yet for all songs.

If your files are on a NAS make sure to set smb type to 3 and also iirc turn off jumbo frames

Thx. It is SMB3.
Issue is with music stored both on PCIe SSD and NAS after some time of use of sever with >20k albums.
I have tried with Jumbo frames on/ off. No difference.
When I restarted today server with 30k albums and it played without dropouts for some time, just search was very long ~30 seconds. But after it started adding more songs, also dropouts restarted on PCIe SSD music.
It feels like after some time of running stack is overflowing with something, and it gets into errors.


Are you using 32 or 64 bit versions ?

Hi Nick,

For OS X there is only one download I see and can get on Roon web.
Is it 64 or 32?


Short update after last reboot of Mac and restart of Roon (when it reached 30k albums and multiple dropouts in each song were happening).
It has been running well for last three hours without single dropout, scanning folders, and by now it has added to library 1.5k new albums.
Search is slow (~30 sec), but otherwise works perfect. AIFF 44.1/ 16 analysis done fine in FAST (~4 sec) upon demand.

I will keep monitoring it, and report when dropouts again restart.


I reached 32k albums, then server because of unknown reason started to delete imported files.
After seeing some 2k albums to disappear one after another, I restarted the server.
For some moment it stopped deleting albums, but then again started. It deleted from 31k some 10k albums down to 21k, and then because also of some other unknown reason stopped further deleting.

I had to restart it few times to get all SMB3 shares properly established, it was missing one or another each time.
Now it has reconnected deleted albums, and has reached already 33k.
After two days of busy work dropouts again started after each 5 seconds.

Today I updated server to the latest build 157, and rebooted the OSX and restarted Roon.
At current moment it is actively adding new albums, and playing w/o dropouts still 2 hours after the restart. Will keep you informed if and when they again restart. I hope not… :slight_smile:


Roon build 157 on OS X was working for 1 day. Then crashed and stopped adding albums. After restart another day of fine work without dropouts while adding albums.

Now again large deleting of added albums!
After reaching 39k albums added (it took three days), Roon decided to delete around half of them - 18k.
Now only 21k are left in the library.

No NW issues visible in setup, all watched folders are SMB3 connected, in status of watching for new file in real time.
Dropouts are now again happening each 5 seconds.

What to do?

  • move Windows Roon server
  • wait for Roon to fix OS X issues, but when
  • drop it, and use JRiver

FWIW I have found Jriver unreliable/unstable and under featured in the past on OS X compared to on a windows platform…as much as I hate to run a windows box it seems to be a more stable option for both Jriver and Roon in my setup.

Latest update.
After launching new scan last night, Roon server started to add new files, but finally deleted other 11k albums. So, now number of albums is down from 39k to 9k…

Hi Janis,

I’ve not see any comments from the Roon guys, so I’m leaving an @support flag for them to follow this up with you.

Hey guys, @eric just brought this to my attention, so I thought I’d come and explain where things are.

Disappearing Tracks

We’ve investigated this about half a dozen times over the past year. It’s actually more of a problem with OS X than with Roon (which is why Roon on other platforms does not suffer this symptom), and it is relatively rare, meaning we have many users using network storage on Mac without this symptom, and only a handful who see it. This suggests that it’s in some way correlated with setup details or habits of those users.

The script is basically like this:

Roon: Hey OS X, is the network folder mounted?
OS X: Yup. Mounted
Roon: Ok, tell me the directory listing for my watched folder
OS X: That folder is empty, buddy
Roon: Really? That seems wrong. Are you sure the network folder is still mounted?
OS X: Yup, mounted.
Roon: Ok, tell me the directory listing for my watched folder again
OS X: That folder is still empty, buddy
Roon: Double-check that it’s mounted for me, OK?
OS X: Yup, it’s still mounted. Jerk.
Roon: OK, I’m gonna trust you on this…

Anyways, it’s clear to us that OS X sometimes lies to us about the status of mounted network folders, the contents of their directories, or both.

The trouble is: if Roon thinks the network folder is mounted, but sees the directory as empty, it’s going to assume that those files are actually gone. And then the album count starts ticking down.

We have spent a lot of effort trying to provoke this situation in the interest of developing a workaround, and the chief barrier has been the difficulty we’ve had reproducing it in house, which makes the process of developing and testing a workaround a lot more murky.

We are working on some general improvements to folder watching infrastructure right now–part of that work includes our fifth or sixth attempt to work around this issue. This workaround is more crude than the past ones (which could be summarized as “making the above conversation even more annoying and pedantic and drawn out to try to be extra sure”):

Basically, we’re planning to write a hidden file into the root of your network folder, and if we ever list that folder and see the file missing, we’ll know not to trust what’s going on.

This breaks some fundamental assumptions of watched folders (mainly, that they are read-only), so we’ve avoided the it so far, but it’s fairly likely that it will work. Work on this is ongoing.

Performance of very large collections

@BahamaBob and @Janis, you have something in common: your library sizes are in the 99.9th percentile. Congratulations :slight_smile:

@BahamaBob’s observation about Windows is astute–extremely large libraries do work better on Windows.

This is a tricky thing to say out loud, because it isn’t really our intent to endorse one platform over another, and the vast majority of our users will truly never feel the difference–but in the interest of openness, I’m going to explain what’s going on here.

Roon is built on top of a framework called .NET. This framework is powerful, flexible and mature, and it’s suitable for building complex, demanding, long-lasting software on every major desktop, mobile, and server platform in use today.

Our choice to use .NET is what enables us to keep releases on five platforms in sync without having five copies of the software. It gives us access to a great ecosystem, and high quality tools to work with. There are not very many alternatives for a company/product like ours that tick the same boxes.

.NET was created by Microsoft, so it should not be a surprise that the best performing implementation of .NET is currently available on Windows.

For non-windows platforms, we use a community-developed .NET implementation called mono. This is a mature and stable project that’s been around nearly as long as .NET has. For almost its entire life it’s been stewarded by various businesses associated with the project’s founder, including Ximian, Novell, Xamarin, and as of recently Microsoft.

Yes, Microsoft. A few months ago, Microsoft acquired the company that stewards the mono project, with the expressed intent of leveraging mono’s technology in order to directly support .NET on all platforms. So the prospects for .NET on Mac, Linux, Android, and iOS are looking pretty bright.

Today, mono is good enough that virtually all of our users don’t have to care about what platform they run on. Looking towards the future, there is almost certainly going to be convergence between Microsoft and Mono’s offering, because they are now being funded and developed under one roof.

Unfortunately, when a Roon library gets up into the several-hundred-thousand-tracks range, it pushes mono’s memory management infrastructure so hard that bad behavior starts to result. Symptoms might include laggy screen loading, slow focuses/searches, audio dropouts, or other stuff like that. When the framework gets messed up like this it is literally standing in the way of the code we need to run to get things done.

A catalyst for this problem is the richness of Roon’s data model–500,000 tracks means we’re also keeping track of 50,000 albums, 750,000 performers, 20 million credits, and so on. Compared to most other music apps, we manage at least 10x more data–so we are starting from a more difficult position.

That said, there are definitely some areas where Roon could be optimized, and some specific performance oriented projects are planned. We are just wrapping up a round of optimization on RAAT–our next scheduled bit of performance work is focused on improving library related performance, with a focus on mac and linux, which should help here.

That said, I’m not totally certain whether it will be enough for libraries this large–the only way to find out will be to test once the work is done. Hopefully some improvements from Mono/Microsoft will appear in parallel with our work.

In Summary

Looking towards the future, it’s fairly clear that these problems will be behind us at some point, but that that point is not today.

In the immediate term, @BahamaBob’s solution–a powerful Windows machine–is probably the most viable workaround for supporting extremely large libraries like these with good performance.

Unfortunately, they are some of the more difficult and long-standing issues that we are doing battle with, and the solutions are not clear or crisp.

I hope this helped explain things, and I’m sorry that we don’t have an immediate remedy for these problems.