It may be an issue if [Artist] = “Various Artist” but [Album Artist] = “Various Artists” is a common way of grouping an album where artist is more than one name eg in JRiver . So leave it alone
Why would anyone use RAID 0 then? All disks are striped - none is used to provide access to data if there is a failure of one of the disks. RAID 1 would give no improvement to speed - but would provide access to data in case one disk fails. RAID 10 provides both features and the ability to recover from a two-disk failure.
1 Like
I think Geoff is suggesting that very few people use (have use for) RAID0 and that it’s inherent fragility is one of the main reasons.
Still, i would wager that your slow search hasn’t got the slightest to do with your media storage. A defect storage unit might well cause issues though.
Still, nice powered USB drives is plenty fast enough (and cheap enough to replace when necessary) for even a lib a size of yours.
1 Like
I can log into both drives with Windows file explorer and view the files with little delay. That tells me there is likely no defect in the drives. Since I see I’m not the only one having this issue, perhaps there is a bug in Roon? Are they working on this? I’ve been a Roon user for many years.
Roon have done lots on search mostly behind the scenes. They employed a search specialist developer then to utilize the most advanced tech theymoved search to the cloud servers to utilize the power of such infrastructure.
Search has improved but if will never be Google
Experiment a little, try keeping the search string simple, the more complex it is the more difficult it will be to parse and match. Eg a simple Artist name normally works fine , an Arist then Album adds more processing requirements and more complex the slower makes sense ?
As for searches, try using Filter instead, if what you are looking for is in your library. Go to the library page and use filter and type in “Harry”. See if it is faster than using search.
Well, as I said, I’ve been with Roon for many years now and this is a new problem. Perhaps this “specialist” isn’t quite that good. I used to brag about Roon. I am embarrassed by it now.
Yes, that is definitely faster. Thank you.
Well, things are getting better! I used MP3Tag to look for “artists” named “Various Artists.” There were 238 of those, and I renamed them all “[unknown].” (I left “album artist” with the “Various Artists” name.) There was one file with a bitrate of 28, and I just deleted that one. There were a number of files with the “genre” tag blank. I didn’t have time to guess - so I marked all of those “[unknown]” too. Three of the files had artist names in Chinese characters. I looked up the meaning of those Chinese characters and replaced them with English characters. I don’t know if any of these things helped, but today I find speeds have improved substantially - for whatever reason.
2 Likes
Just an observation, when you made the said file/meta-data changes, did you happen to turn off roon services, shut down roon - basically make the file changes while roon was not actively referencing the files?
1 Like
No, everything was left running.
If I got it right on one of your hard disks you have a folder with more than 70k tracks taken from different albums, many of those tagged with „unknown/various artist„.
If that`s the case, what you expect from a search?
I dont wanna be rude just tryin to understand your case.
I do believe editing data in this fashion does/can create a sort of mess with the DB (dead/invalid links).
Someone more knowledgeable on this “method” can chime in, but if you go to “Settings, Library, Clean up” you will prob see a status of a lot of missing files or something.
Bottom line “I think” is when directly editing file metadata is to do it without roon active and then re-scan those files modified in roon - something like that.
1 Like
If that’s the case, what do you expect from a search?
My case was that Roon was very slow in searching and loading. Someone mentioned that there had been an issue with artists named “various artists.” I have a large collection - and I have an entire disk drive with albums that have multiple artists. I have an even larger drive with albums each of which has a single “album artist.” Quite by chance, while I was exploring suggestions made here, I found that it was the smaller drive (with only 70,000 + tunes) that was causing the slowness. I checked the songs on that drive and found a few (a couple hundred out of over 70,000 tracks) that listed the “artist” as “various artists.” (The “album artist” on that drive was always - and still is - set to “Various Artists.”) I didn’t have time to change those few tracks - or to search out who the actual artist was for those - so I just changed the “artist” on those few songs to [unknown]. Plus, I fixed a few other items while I was there. I didn’t expect that to do anything, and maybe it didn’t, but my problem with slowness has gone away - and I’m accessing all 284,960 tracks from both disks now without too much delay. Finding albums / artists / etc. without too much delay - that is what I expect from a search.
Well, this time it worked just fine with Roon running. I have fixed files for years with Roon running and have never had this problem before. BTW, I did a cleanup before I posted here the first time.
Not too many months ago Roon went “Internet always on” with V2.0 , this was due to a major change in the whole search mechanism. Does that coincide with your problems.
If it does it may point to the structure of your specific library. My library is 99% Identified and in virtually all cases my files are grouped in the original albums or in some case box sets .
When the transition happened , VERY large sets g Mozart 225 = 200 CD were identified as problem areas , presumably the sheer number of tracks being searched.
A whole drive of individual Non-album tracks is going to give Roon some headaches. Roon is fundamentally Album based. Identification is based on Albums not specific “singles”
If you can do it , have you tried “disabling” the singles drive and retest… Just Disable NOT Remove, that way you can reconnect with no loss.
Yes, I did that. Look back a bit here and you’ll see the whole saga. Yes, that drive with “various artists” albums (yes, they are whole albums which can be purchased as such but which have songs from various artists) is causing the problem. Yes, the problem is recent, as you say here. And as I’ve said several times, I’ve been a Roon user for many years - this is something new.
Well yesterday late afternoon here in UK Roons search was dog slow for me and I don’t have a huge library only 60k. From ny experience issues like this tend to be not local and normally points to a server load issue Roon side. This has occurred many times in the past for me and doesn’t affect all users and often not the affected ones all the times. It can be quick then all of sudden take 30secs to return a query. This has occurred so many times since they started to move to cloud more and more. Every time you will get the run around from most saying it’s a network or local issue. Yet when it finally gets down to investigating its been Roons side. Public holidays and weekends is where the issues start to rise and show more latency as more it’s under a heavier load.
6 Likes
I have to concur that here in the USA search turned to a dog slow effort for myself and a couple of times I even got the message “could not connect to Roon Search” which I have never seen before.
So at times there is something strange occuring with Roon Search Servers.
I just had one slow search, on the next try “could not connect” and a few seconds later it worked again. Cloud for you, just like other online services are sometimes slower and sometimes faster.