I’ve PM’d the mp3 file.
which one’s out of a matter of interest?
SJB
I’m having another issue which I’ll start a different thread on. When I look at an Artist and then All Albums, I don’t see all albums. But if I search for the album by name, it shows up, and the artist name is exactly the same. I understand the cool connected metadata point of roon, but it also should show you basic things (like albums of an artist) that are meticulously tagged correctly. Anyhow…another thread.
There is already a thread on that subject.
Well the ZZ Top mentioned above and there are guaranteed to be others as I have almost 11,000 albums.
I’m not tracking them down.
One of the problems Jeff is that unlike other music software, Roon has to maintain interoperability between Cores and Remotes running on various operating systems. I understand it currently does that by ignoring all symbols deprecated by any supported operating system, meaning the Roon library is consistent regardless of OS. So the Windows naming rules are only part of the equation; Mac and Linux have to be considered also.
This isn’t a user interface consistency issue. A compiler preprocessor directive in this case would be appropriate as it’s all behind the scenes and the distros for each OS is different.
I’m still wondering why it should not be possible for Roon to prompt a list with skipped files or folders after every import process. It would make the Roon life so much easier and clearer in these cases.
2 Likes
Correct. And I have had Windows, Linux, and OSX operating systems importing the exact same music files using the various flavors of LMS running on all 3 operating systems and never had a problem with any of the three automatically importing all my 90,000+ files. Roon is the first software server to choke on anything for me.
I’m pretty sure it’s related to Roon using folders and file names first for identifying albums. Most other software looks at the file tags so it’s as simple as importing every music file it finds and extract the tags.
It’s cool for people that don’t curate their collection and unfortunate for those that do.
As @andybob mentioned, we don’t have the luxury of developing just for Windows. Everything in Roon needs to work cross-platform, and we have plenty of people scanning Mac and Linux-based storage from a Roon Core running on Windows.
These folders have caused all sorts of issues, complaints, and stability problems in the past, and people using Roon in these cross-platform setups can’t change what’s considered a hidden or system file. Everyone has the option of renaming folders so, for the moment, we’re putting together a list of the folder names we ignore, which will be published soon.
I understand your point, and you’re right that we could put a bunch of effort into determining whether a folder called “Recycler” is a system folder or legit media. Hopefully you can understand this isn’t a super high priority right now, and there are almost certainly edge cases where the detection would go awry and cause more issues. Personally, I’m going to search my storage devices for the 11-odd folder names that are verboten, and be done with it 
We will be implementing this in the future. Right now, Roon skips anything that’s not audio media, M3U playlists, or cover art, including corrupt/unreadable files and system folders. In the future, we plan to make a change allowing for importing of other file types (like PDF liner notes). I don’t have a firm timeline for when this work will kick off, but it will happen when we’re making that storage change and putting it through the weeks of testing we typically kick off when we make changes to storage.
Hope that helps guys!
I’m sorry Mike, it really doesn’t help. You shouldn’t skip folders or their recursive child folders if they have music files in them, there is absolutely no valid reason to. Roon should know if a folder is a hyperlink or hidden or a system object or contains weird characters, whatever was causing you these issues you mention. If that means you have to use some compiler directives for each supported OS so be it. An implementation that is consistently bad across all platforms isn’t a good solution.
LMS runs on OSX, Window and Linux. JRMC runs on OSX, Linux and Windows. Neither of these software packages skip folders because they have a particular name.
This needs to be addressed. You now have a bunch of clients on these forums that are wondering what albums and tracks am I missing in Roon?
I agree with Jeff’s comments. This is 2016 and the problems with directory names was solved long ago across every platform I’m aware of. This shouldn’t be an issue in modern music library software. And unrelated to this (I think), I’m becoming frustrated with the idea that my carefully tagged and very organized library can’t even show all albums by an artist within roon (even though all albums are in subdirectories under the Artist parent directory and all the albums have the correct (and same) artist listing in the metadata and the albums actually exist in a search in roon with correct artist name and album title. Any random music server can perform this task. Roon should do the cool stuff, but it has to nail the basics too.
But do these applications communicate with other instances of themselves running under different OS’s ?
What does that have to do with scanning local to a server or core?
I hear you, and I agree with the reasoning regarding other players. We should not be worse. We are willing to re-think this approach in the future with this feedback in mind.
In regard to some of the technical points, they rely on the assumption that we can query the operating system for attributes and reliably get correct answers about special folders and files. Under the best conditions, this is definitely possible. Under the worst, it can be very tricky. Our current approach is sloppy, but safe. Since Mike brought this discussion to my attention, my head has been swimming with the edge cases that we’ll have to nail to get this right.
For example:
- The filesystem that Roon is looking at directly is not always from the same platform that Roon is running on right now. This can happen due to network-based mounting, USB drives, FUSE, Paragon drivers, and other reasons.
- Sometimes system files are copied from place to place using tools that destroy their attributes/metadata.
- Sometimes filesystems are mounted over network protocols that aren’t capable of conveying the attributes/metadata of the system files contained within.
- Sometimes, filesystems are viewed through mechanisms like FUSE plugins that lose metadata along the way.
- It’s possible to re-bind filesystems or segments of filesystems at any location–so it’s possible to have a folder called D:\Artists$RECYCLE.BIN that is actually a recycle bin from another drive, or a network drive–so subdirectory based reasoning doesn’t always work as you’d expect.
I think it’s worth it to be more precise here. I’m not sure exactly what form the solution will take. And I’m not sure when it’s going to happen–we won’t make changes that immediately re-exposes us to known issues from the past without coming up with an alternative/better approach.
@brian Thanks for the reply. All I ask is that it’s something you guys look at again, hopefully in 1.3, because I really don’t want to have to go through 15,000+ folders. 
Perhaps I’m being simplistic, but I’d think you’re entitled to assume that every folder and its sub-folders Roon is pointed to are intended to be part of the user’s library and scanned for content. Make mounting network shares using an appropriate protocol and location the user’s problem and let it do any cross platform translation required. Incorporate a directory browser so users can point Roon to their music. If there are corner cases that cause problems or limitations within Roon, point these out so users can address them in their collections. Make it the user’s responsibility to ensure their storage isn’t a mess.
[quote=“DrTone, post:37, topic:8617”]
I really don’t want to have to go through 15,000+ folders.
[/quote]i doubt you’d have to, as it would seem there are only a few exceptions that would cause Roon not to import a folder’s contents. Use a file manager to count music files and compare results with Roon’s count. If there are differences there then you may need to check by file type, but the first thing I’d check are file permissions to ensure that Roon has access to all folders and files, especially if they’re hosted on a *nix system.
We need to know what the rules are that cause something to get excluded first. At that point I’d just write a program to find them in my collection.
I have no intention of renaming stuff at this point as it should work as is. I’ll wait for a Roon fix or a log they produce indicating what got skipped. I’m working with a small subset of my albums right now anyway until Roon gets some better inherited Artist<->Album tagging, my collection is to large and unruly and I need a way to flag albums as well mastered and only show those artists for those albums when I filter on it. I don’t see this in the road map any time soon so now I’m forced to pull those well mastered albums out and duplicate them in a seperate folder and have Roon only pointed at it.
In all honesty it’s been fun, researching album release versions, dynamic range and other information about certain content in my collection.