I mean when browsing albums and selecting one just to see what’s there?
Asking 'cause… I have the feeling it actually reads the track list, each and every time, from the actual files, not from its database
Feeling comes from the time it takes to diplay an album’s content: the higher the resolution and number of discs/tracks/stacked album versions, the longer it takes
All was fine until recently when I started buying/ripping SACDs, but now some albums (SACD ones) take a very long time to just open
One in particular, which I have both a SACD and 24/96 version, comprised of two discs with 70+ tracks each takes an unbearably long time to open
btw: dedicated Mac mini quad-core i7 2.3GHz, 16GB RAM, 128GB SSD, running mac OS 10.11.6 and Roon core only!
tracks on a Qnap HS-251 NAS (only used for music files, every service apart SMB disabled) connected via ethernet, by means of a 10/100 switch, to the Mini
It must be down to your network transfer speed. I thought Roon will read your file tags and go from there. What else can it do?
I have just installed a QNAP TVS 471 i3 4GB Ram and a 250GB SSD.
All the storage is local and it is fast.
Looking at the QNAP dashboard, the RAM sticks around 50% with 2% CPU playing a CD. With high res tracks the CPU usage may rise to 25% ish then drops back.
Your machine is much higher speed than mine so I don’t believe it is limiting performance.
in Audirvana opening the very same (or just any) album and showing its content is click-bam!
maybe Roon also checks, each and every time, files are (still) there :unknown:
Click-bam would be an apt description for my Roon opening albums. How may albums/tracks are we talking about here?
a little above 1600 total
though… really: the higher the resolution (file sizes) and/or number of tracks the longer it takes for Roon to show album’s content
click-bam only happens with redbook single-disc ones
I just tried to reproduce and can see a slight difference with HR / larger #s of tracks. For comparison: my version of Sleep (31 tracks, 8 hrs total, 96/24) shows "Loading album’ barely long enough to read (<0,5 sec.). Core i5 Linux, all storage at USB3 5400RPM spinners.
tried with the very same album and… takes 2-3sec here
same as (if not a little longer than) a 5 discs, 24-192 album (Rattle’s Beethoven Symphonies)
As this is discussing Roon architecture I think this is one for @Brian to comment on.
Have you tried copying that album to your local and see if it takes the same time. If it is quicker, or not, ocal that would be an interesting data point.
I haven’t, Daniel, as I do not keep any music file on my Mac mini’s local drive (nor I want to)
point is… looks Roon is doing something more, even when just displaying an album’s content, than only reading data from its database which is on the local SSD (as Audirvana’s which, instead, instantly shows any album’s content without any “slow down” related to file size and/or total number of discs/tracks)
ripping to DSF a 10 SACDs album now. we’ll see
During browsing Roon is reading from RAM or the local database only. It doesn’t go out to the files until you choose something for playback.
That machine is plenty fast, and your collection isn’t enormous, so things should not be unbearably slow.
It would be worth restarting the Roon Core, then restarting the machine to see if something has gotten bad in a temporary way. Check activity monitor for any CPU, RAM, or Disk hogs. Finally, make sure that the SSD isn’t nearly full–that can degrade performance considerably.
Speaking of the SSD… is this an apple SSD that was originally installed in the system? If not what manufacturer and model is it?
SSDs rely on a process called TRIM which is basically garbage collection after a file has been deleted or modified and it tells the OS to re-use the old blocks on disk for something else. Mac OS support for trim has been notoriously flaky for anything except their own drives (or most of the Samsung SSDs). Apple did finally add trim support for third party drives in OS 10.10.4, but it has to be enabled manually. Take a look at the following link for more information:
I’m not saying that this is definitely the cause of your issues, but given the disk activity involved in running the Roon Core this could be a potential source of slowdown. Drives that are not properly TRIMmed can exhibit severe performance issues.
my Mac auto-shuts down every night and I reboot it every day before starting a playback session
in fact there’s no issue at all while browsing albums in “Album view”: the issue is having a look at what’s inside a given album
as confirmed by RBM too, even if to a much lesser extent, there’s something in Roon that makes opening an album somehow related to tracks file size/number of tracks
@AMP SSD is a 128GB Samsung 840 Pro with barely 25GB being used and TRIM enabled and active (using DiskSensei)
again: just Roon has this “speed issue”
ok… ripped to DSF a 10 SACDs album (Gergiev/LSO’s Mahler Symphonies), loaded on my NAS and launched Roon: takes less than 1 sec. to open and show content
René Jacob’s St. Matthew Passion, though, still takes 10!
- Mahler’s set has no more than 4-5 tracks per disc (only disc 9 has 18)
- St. Matthew has 37 (disc 1) and 33 (disc 2) plus both a DSD and a 24/96 versions are stacked
I believe the latter is what makes opening this album a real pain: two stacked versions of a multi-disc album with high tracks count per disc
We took a look at this today, and were able to reproduce a striking difference in load times between single-disc and 10±disc albums. It matches up with what you’re describing.
It was tracked down to a performance problem related to how the core buffers data that’s bound for remotes. For some reason, these buffering details don’t really cause a performance problem when the Core is running on Windows, but Mac/Linux Cores are much more sensitive.
We did some optimization work to address the slowness. With these changes, details pages that were taking 5+s are now taking <500ms, and details pages that were loading “quickly” before are now loading so quickly that the loading indicator barely has a chance to draw.
These improvements will go out with 1.3.
Thanks for the investigation, @pl_svn and @RBM --we wouldn’t have had a reason to look into this otherwise, and the performance improvement will impact most of our users.
thank you all very much, Brian