Puzzled and looking for answers from Smart People

Good morning Roon Brainiacs! I am very puzzled with the results of some testing and was hoping that someone could explain the “why’s”.

I started using room with my MacBookPro that was setup to pull files from three locations: Local drive, attached drive (to MBP) and a Melco NAS that is hardwired to the network, In total I have 255,000 tracks in lossless>DSD formats. I started using the Roon as my primary music source and was connected to the nertwork via WIFI and using an Ayre QX5 twenty as my "approved endpoint’ that was also hard wired to the router w/o issues; in fact, I have run it flawlessly for periods exceeding 24-hours of mixed materials (NAS/attached storage & Tidal),

Having had success with Roon, I decided to purchase a Nucleus which I thought would take it to the next level and hard-wired to the network. I attached the external drive, added the NAS drive which resulted in the same number of tracks (255k). This turned out to be a disaster- partial tracks and skips and stops from the get go. In speaking with Support, they monitored my unit that resulted in issues that they were unable to address. Working with Support, they suggested that I re-build my Nucleus with a new DB and the latest SW build. I was instructed to add only 10,000 tracks and test the unit… Unfortunately, the results were the same and reported it to Roon Support… They glossed over that interaction and concluded that the issue was that it was the Nucleus and suggested that I upgrade to a Nucleus + as it would handle the number of tracks in my library. I disagreed with their response and pointed out the contradictory info stated above:

  1. MY MBP had zero issue with the library size (255k) and worked flawlessly. It was connected via WIFI
  2. I had the same issues with the Nucleus regardless of file size (255k - full library and 10k with a much smaller library and 10% per-cent of it’s capability).
  3. I’ve got a 300MB pipe that measures 243MB via wifi so it’s certainly not a bandwidth problems
  4. replaced cables as another test.
  5. rebooted my router and reset it to factory defaults.

Because of the reasons above, I returned the Nucleus and went back to my MBP solution w/o an issue.

Can someone please explain? I methodically tried and tested many scenarios w/o changing anything in the test environment and am ambivalent with Support’s conclusions (@support) and extremely disappointed.


What are the cpu specs on your Mac Book pro. Anything well over 100k in tracks pretty much needs an i7 processor. I think the base Nucleus is an i3.

Hi @Rugby - Thanks for responding… My MBP is an i7 which speaks to your point BUT that’s where thinks get a bit confusing because of the following:

  1. The MBP is connected via WIFI VS the Nucleus was hard wired. One can say the integrity of a wired connection is far superior and less problematic than a WIFI connection (in an environment with 17 WIFI devices)
  2. I had the same issues with the Nucleus regardless of file size (255k - full library and 10k with a much smaller library and 10% per-cent of it’s capability). So much for the processor argument…

This is why I’m so perplexed. If it was as simple as the i3 VS the i7, I would had upgraded and be done with it BUT it’ stated/proven that it’s not that simple.

To your point 1, yes hardwired is much better than WiFi, but the pipe throughput has little to do with the processor. Processor power is mainly for library management, DSP and multiple concurrent streams.

My initial suspicion is when you set up a new library, Roon does an audio analysis scan. During this time processor function is limited and can cause issues like you describe. Even at 10000 tracks the analysis function can take hours with an i3.

You might try setting Roon back to the test 10k tracks and going into setting/library and if the analysis is running, turn it off (the setting is called Background Library Analysis Speed). Then try playing music again.

1 Like

@Rugby- Hi Daniel… maybe i didn’t explain it properly; the Nucleus with the 255k tracks was also used for testing with 10k tracks. I rebuilt the DB, reloaded the software and added 10k tracks. Roughly fourteen hours later, I cued up the same tunes that I was testing with the larger DB and the results were the same; it skipped and transitioned to new tunes after 1/2 playing the one before. So in conclusion, the Nucleus was set-up according to their specs with 1/10th of the max tracks for testing. The results were the same as with 255k tracks, I don’t think the processor speed was an issue here.

But it may well not have finished analysing 10k tracks in 4 hours.

The nucleus was on 24/7 and didn’t play any music until the next evening which is roughly 14 hours so there was plenty of time to analyze the tracks

In your previous post you said four hours hence the suggestion.

@ged_hickman1- yeah i did… thanks for pointing it out and will amend the prior response. it was “14” hours and not “4”.

In case even the support runs out of ideas? Perhaps it’s something nothing to do with the roon software at all. For example …

Ever considered to have a quick check about S.M.A.R.T. diagnostics on every drive being involded (internal, external, nas, …)
If a drive reaches it’s end of live there comes the point where it isn’t able to remap defective sectors any more, And then what happens is that the system tried to read and/or write to that defective sector more but just ones but a couple of times. Which causes a huge delay.

On Windows and Linux I would recommend Hard Disk Sentinel since it offers a readable frontend of what all these values might mean to the enthusiasts. Can’t say if there’s something similar for the Mac, but monitoring the health of drives is always a good idea.

Having been on the forum for a while, the behaviour you experienced is seen off and on in different scenarios. They tend to break down into a few categories none of which are amazingly obvious with your install.
You are carrying on using the storage with your old/renewed server so that is unlikely.
Often the problem is networking but you moved from wireless to wired so again, unless you had a dodgy network cable, unlikely.
Leaves hardware problem. Maybe you just had a broken Nucleus…

@StefanB - good idea! As an FYI, the tune that i used for testing was Shine on you Crazy Diamond which runs for ~11 minutes (24/192). It bombed out each time after about 8 minutes being played from the Nucleus. For comparison, I played it perfectly (off my Melco N1) via multiple apps (mControl & Linn Kazoo) and it played straight through w/o issue. The only really difference between the two test was that I played the track Melco>Ayre QX5 Twenty VS Melco>Nucleus>QX5 Twenty so it certainly points towards a bad Nucleus (or code).

My greatest issue with @support was that they tried to diag the issue and let them tap my system (to review the logs) plus several rebuilds.

Unfortunately they decided to change direction and state that the issue was the Nucleus suggesting that I upgraded to a Nucleus+ which based on my tests whichI shared above, wasn’t the issue. @SteveSilberman was added to the chain but again, their end to this required me to spend an additional ~$1k. Makes you think…

very disappointing because I see so much potential here,

P.S. I challenged them by suggesting that they send me a + to test their theory and if they were correct, I would had purchased it but thy never responded.

Which dealer sold you the Nucleus? They shouldn’t have sold you a Nucleus if you have more than 100-120k tracks.

It’s not the CPU that’s the problem, although it’ll be slower. It’s the RAM – your library is going to push boundaries of the RAM installed in a Nucleus – while it might work for a while, it’ll blow up in random ways as the memory indexes are built up.

Does your MacbookPro have 16GB RAM? MacOS is a hog, so while it may work on a 8GB MacbookPro, I’m guessing it’ll fall over when MacOS decides to do something requiring a lot of memory.

The @support team isn’t upselling you to make some extra money. This is a matter of being realistic about the gear you have and the library you want on it.

Wait a second, your name sounded familiar so I looked up a unit I had delivered to a doorman 5 weeks ago. Yup, that’s you!

Ciamara sold you the wrong unit. Please call them up and ask to change it to a Nucleus+.

first @danny I don’t fault the dealer and ask that you refrain from bringing them into this discussion; it’s not professional to call them out; I asked for that unit.

Second, I have a MBP that has 16MB RAM and has worked perfectly with the same number of tracks regardless of what else I’m using the laptop for although it mostly MS programs. If you review my account, you will see that I’ve been using it on the MBP for sometime and again, with zero problems.

It is my impression that you were unable to locate the issue through your log reviews as the logs showed inconsistencies. It’s easy to point the finger at “The wrong tool for the job” which I’ve clearly demonstrated that it’s not.

I’m happy to test a + as a “proof of concept” if that’ something that you’d like to try. I am open to help the community and if it means, testing/tinkering and such, you can count me in but please leave @ciamara out of the conversation…

Yes, you have 16GB of RAM! The Nucleus does not. I don’t doubt your MBP works – but the Nucleus is not the same spec as you MBP. The Nucleus+ is not either, but it also isn’t running MacOS or your “MS programs”.

My team wrote the software and designed the hardware specifically for the limits we know to exist. You are coming to a bad conclusion based on a completely different system. This has NOTHING to do with the CPU - there is also a RAM difference between the N and N+.

Unsure what you are saying here… I highly encourage you to try out a Nucleus+ when you are ready to test your full library, because there is no way a Nucleus is going to be stable for that library that large.

If your issue was with 10k tracks, it’d be best to start from scratch, reset the database/settings using the Nucleus web UI, import just 10k tracks, and then play. When it has errors, note what the errors are (there will be an orange/black popup when the track skips), and let @support know. The logs will be much clearer in this situation as well.

I’d recommend never connecting the other 245k tracks to the system, as that throws in a wrench that makes everything much harder to diagnose. For all we know, this is a simple networking issue with communicating with the audio endpoint and has nothing to do with the 10k tracks.

The other 245k, I can assure you will not be stable with a Nucleus.

Let’s resolve your issue with the 10k first, then if you want to upgrade to a Nucleus+, we can try your full library. No one is going to help you with a Nucleus with 255k tracks, but starting with a clean system and 10k tracks should be easy to resolve.

@danny- again I’m disappointed that you called out @ciamara and ask the you redact it.

What I read above are impressions but very little meat pointing out the reasons for the failure (other than track numbers). Bothe the Nuc and Nuc+ have 8GM Ram and a faster processor being the differentiator. Ultimately my MBP works and that is the only result I’m looking for. I offered to help address the issue for the community but am not plucking down $2500 and more time dedicated to do so.

That’s where this thread ends.

Thanks for your impressions.

incorrect. the N+ has twice the RAM of the N.

This is one of the web pages that features your products so if this info is incorrect, then I don’t know what to tell you.

Clearly you’ve taken the path of challenging me which is counter productive to where I was hoping we would end up. Clearly you product isn’t for me and I’m not a good fit for what you’re selling… Have a very Happy Holiday and suggest you apologize to @ciamara as your distributors are your life blood.

Which part am I missing? the thing you posted clearly shows 4GB RAM for the Nucleus and 8GB RAM for the Nucleus+ – one has twice the RAM as the other.

This is my entire point – the Nucleus will not support 255k tracks and the Nucleus+ will.

Your statement is in conflict with the information you just posted:

As for @ciamara, we will talk to Sanjay.