Original post seems to have gotten lost in cyberspace and mixed with other posts. I’ll try again.
Description:
Nucleus+, all audio is wired ethernet including to router (Linksys Velop). Other traffic does not pass through audio network. I have disconnected everything else- wired and WiFi- with no difference. Problem (software and / or hardware) began around the Build 528 update time frame. Symptom was extremely long time to do update- more than 10 hours for download. Playback to devices was fine. Then Build 571 did eventually update- many hours. However, playback now pauses for 5 seconds every minute or so. Playback is unusable. Cannot write audio files to drive ‘internal storage’- summary below. My path is smb://nucleusplus/data/storage/internalstorage/Hi Res Music Nucleus/… audio folders. ‘Hi Res Music Nucleus’ folder has spaces- is that an issue? Seems to be supported in audio file folders, but I thought I’d ask.
Actions:
I did some more poking around after my reply about a possible SSD failure explaining my nucleus+ symptoms. I’m now not sure the SSD is sick, but who knows.
Looking at the Data path, there are / were three volumes- Internal storage (SSD), USB SSD for backup, another USB flash drive for more backups.
I can create a folder in any of them ‘instantly’. I can rename it, I can delete it.
I can copy files FROM any of the three volumes. However, copy time seems a lot longer- 800 MB takes about 3-1/2 minutes.
I removed the two USB drives; no difference.
If I play an audio file from ‘internal storage’, I now get the ‘file reading too slow’ message on my desktop Roon client. Playback stops for 5 seconds, then resumes for a minute or so. Eventually dies.
If I attempt to copy a file (2 to 3 MB test file) TO ANY of the three volumes, it either takes forever (hours), or fails completely. Pressing ‘stop copy’ takes a bit over 3 minutes to cancel the operation.
Maybe my Roon updates take so long (hours) because the file is written / buffered to a drive, and my write operation is hosed?
SO…
Is my hardware sick (disk I/O)?
Can a SSD failure present this way in your experience?
Is it something in build 528 onward? 571 is MUCH worse. Maybe my problem is just escalating and the update issues are coincidental?
How about a re-install of the Roon OS? It’s at v1.0, build 219. I assume disk I/O is coded there.
Any help would be appreciated- I’m having withdrawal!
Thanks, Bob
What are you using to write the files to the Nucleus with? A PC? A Mac? What version of the operating system?
What is your networking setup (e.g. router model)?
This additional information will help diagnosis by the Roon Labs Support Team. Thanks.
That sounds more like a network issue than a disk problem. You would be doing the file copies from a remote over the network. Reading too slow is often network. Long time to update etc.
Mac OS Catalina v10.15.5 on a desktop MacPro and MacBook Pro. I also tried an iMac running High Sierra 10.13.6. All have smb in Sharing enabled. Two are wifi, one is wired ethernet. All 3 can see the storage files. All 3 can copy files FROM nucleus+ to the machine in about the same time. When copying from any machine TO nucleus+, the folder is created quickly. The copy dialog pops up and hangs. STOPPING copying takes about the same time on each machine- 2-1/2 to 3-1/2 minutes depending on the file size I tried to upload.
The router is a Linksys Velop model WHW03Bv1, mesh, two Velop nodes. Nucleus+ is at 192.168.1.224, and Velop reports no issues in the diagnostics panel. Router is wired ethernet to switch; 1 port to nucleus+, other ports to PS Audio DAC Sr, Naim Qb, and MacPro computer. Internet speed is 112 Mb down, 12 Mb up, 7 ms ping. Router firmware is up to date. UPnP is NOT enabled. No settings (that I am aware of!) have changed since the problem started about 6 months ago.
It’s hard to say for sure just yet what the issue might be, but there are some things we can try to help narrow things down.
There is no issue with doing a reinstall of Roon OS — Your database is not touched during this process, so you can definitely give it a try and see if there is any change. It’s unlikely that this will help, but generally it is a pretty quick test that might be able to resolve some system-level issues if they exist.
It’s unlikely that this is related to the updates — There are many Roon users with similar setups who are not receiving issues along these lines.
The length of time that it takes to update would not be related to the Internal Storage SSD either, so it’s likely that there is some type of networking issue at play here causing this to go a bit slow. The other issues, however, could stem from issues on that drive.
Does this happen with content stored anywhere else? USB drives, network shares, or streaming content?
What if you play to a different endpoint like System Output of a remote? Same thing?
All other network traffic- moving photo files to disk, files between computers- work just fine; no slowdown. No streaming content issues- Apple Music, Tidal (except through Roon) plays fine direct through iPad. Apple TV / Netflix, etc are all OK.
Roon clients on iPhone, iPad and MacPro desktop all load fine. Music is displayed quickly. Scrolling through library is quick.
Using my iPad Pro Roon client (wifi) set to play through the iPad itself chokes after about 1 minute with the “An audio file is loading slowly. This may indicate a performance or hardware problem”.
Same warning with MacPro wired directly to switch and playing through said MacPro. Distance from desktop to switch is about 3 meters. Switch to nucleus is 1/2 meter.
So firmware updates are NOT buffered through the internal storage? It must be stored temporarily somewhere- is that in system RAM?
Hi Scott-
The router feeds a ‘local’ (< 2 meters) switch (Linksys SE3016). Ports on said switch feed Apple TV (wired) and various other wired stuff (duh). The Linksys Velop router is a mesh network to a second Velop with a wired back channel for coverage in a far part of the house; that keeps the wifi traffic through the Velops. One port on the ‘local’ switch runs about 5 meters to another 8 port ‘audio’ switch (Linksys SE3008). All the switches are reasonably buffered for throughput. Said ‘audio’ switch connects to the Nucleus+ (internal SSD), the PS Audio DAC, PS Audio Direct Stream CD spinner (for track info), MacPro, and Naim QB (longest run, about 20 meters). There are two ethernet ports on the MacPro, so I can segregate traffic there if need be (one ethernet port goes directly to the router local switch, which I sometimes use), along with WiFi if I choose to use that to connect to the Velop network and get the MacPro off ethernet entirely. Example: I’m listening to tunes and the MacPro is doing software updates and I’m minimizing traffic with the Nucleus+. Note: MacPro and Nucleus and listening is in the same room.
Clearly the ‘audio side’ of the local switch can talk to the ‘other’ side- as in Roon WiFi clients on iPad and MacBook pros. In general, though, using a highly scientific method of a beverage and watching the port lights on the two switches (local and audio), even when the ‘regular’ network is carrying heavy streaming traffic (Apple TV, other users in the house streaming), the ‘audio’ switch is pretty quiet beyond the usual housekeeping traffic.
For what it’s worth.
I’m not going to get in the way of @dylan helping you here. But Roon does have a thing with managed switches, subnets, etc. After that, I don’t know enough to be helpful. Just wanted to bring that forward if it helps with the troubleshooting.
I am also a keen believer in the scientific method.
Just to confirm here, there is internal storage for media (that would have been installed separately) and then internal storage that comes installed with Nucleus that houses the database only. Firmware updates would go through this drive, not the internal storage for music.
Gentlemen:
Stand down. Sorry to suck up your time. After a seriously strange interaction between the Naim Qb and Nucleus+, I spent the entire day yesterday going through my network (extensive for other reasons). There are a number of switches. I tested EACH port of every switch in a pragmatic way- I used a 366 MB audio folder, copied and timed the copy to the Nucleus+. The copy was from a MacBook Pro on wifi. I shut off (powered down) anything that had WiFi- including one of my mesh router nodes- so I could control the access point and routing. MANY, many ports, hours and tedium later, I discovered one 8 port switch with the following ‘oddities’. Note that ‘copy time’ means FROM the laptop TO the Nucleus+:
Port 8- connected to Nucleus+
Port 7- connected to router with WiFi access to laptop. Copy time = 15 seconds
Port 6- copy time 15 seconds
Port 5- copy time 15 seconds
Port 4- copy time 6 MINUTES 13 seconds! **** Yowza! ****
Port 3- copy time 1 MINUTE
Port 2- copy time 40 seconds
Port 1- copy time 1 MINUTE 30 seconds
The real torment is that ALL ports copied data FROM the Nucleus+ to the laptop at roughly the same time- about 16 to 17 seconds. I have seen a lot of switches fail, but never one like this!
Predictably, when I was substituting / troubleshooting in the past, I was always using ports 1 through 4 because the switch in question- and those ports- were easy to get to. Just goes to show ya…
$50 later and a new switch, all is well. It also dropped copy to and from times by about 3 seconds- to 12 to 14 seconds, depending on direction.
Sorry I used up a chunk of your time and for questioning the Nucleus+ virtues. I get why 4 of the 8 ports can choke (the 4 port silicon controller building block thing). However, in my defense, this asymmetrical failure is- at least to me- an odd one!
Cheers!
-Bob
