After migrating from a Mac mini Core to a Nucleus, I’m now migrating back, thanks to a bug that makes the Nucleus a nonstarter for me (the bug also afflicts ROCK). So I’m posting this a warning to those looking to migrate their Roon Core from Mac to Nucleus (or ROCK):
IF your music collection started on a Mac, and was originally ripped and curated using iTunes; and
IF you migrate your music over to internal storage inside a Nucleus (or NUC/ROCK);
THEN Roon will not play any files contained in a path that includes accented characters (such as é, ö, ü, which includes, for example, anything by Cécile McLorin Salvant, or Wilhelm Furtwängler, or Björk). Oddly enough, Roon can see and analyze these files (they show up in “file info” and display dynamic range, track gain, bit rate, correct filepath, etc.), but it skips them as unplayable.
So, if this is your situation, then a potentially significant part of your music collection will basically become unplayable by Roon after you migrate. Sigh.
You can try to search-and-replace all the accented characters (a bit hard to know how to find them all, and automatically fix them), but then Roon will then see all of those files as newly added, which means you will lose any accumulated metadata about them (date added, plays, etc).
This is a known bug (see here, here, and here), apparently resulting from how differing file systems handle these accented characters. Oddly, however, Roon can still see the files and analyze them, but can’t seem to play them. Anyhow, still no fix timeline.
I wish I’d known before I made the migration (and now having to migrate back). Hopefully this post will let others know who are considering this move. I and others have asked Roon to update the migration docs to describe this bug, but so far no action on that either.
Anyhow, soon my Nucleus will show up in the “for sale” section. Back to the 2014 Mac mini for me. Still love Roon. But disappointed nonetheless.
Thats strange. Sorry you are having this issue. I use a NUC running the Roon OS ROCK and it plays songs from Bjork just fine. I use an iMac to purchase, download and convert all my files to ALAC. Everything gets tagged using a program called Yate. When I originally transferred my music to my NUC all my files were ALAC that were tagged in iTunes and they also played fine. all of my files are in the path Artist>Album>tracks. The track files are named with just their position number and the name of the song, like 01. Hyperballad. I have other artist s with all sorts of Northern European names with accents and symbols all over them. I type the symbols using the option + u keys for ö and or anything else that needs an umlaut character and have not had any issues. How are you getting them? Are you using Unicode? Trying to see what is different
There have been numerous reports of accented words causing issues in importing files , I am sure someone out there must have some experience to share .
Being English speaking I tend to de accent names anyway , otherwise you see 2 artist etc
I remember reading some where (?) here of a solution, binning Nucleus seems an expensive route !
Interesting. My entire music collection was either (a) ripped to ALAC on Mac using iTunes (various versions over the years) or (b) bought, downloaded, and then imported into iTunes. In other words, iTunes has always done all the tagging and file path naming for me. I expect this is true for most iTunes users on the Mac.
When migrating to internal storage on Nucleus, I followed the migration instructions, using SMB to copy from my Mac mini drive, over the network, onto the Nucleus internal drive. Then restored using the Roon db backup from the old Core. All worked well, except for playback any file with a file path that includes accented characters.
Based on the other threads that I linked to in my original post, it seems that this doesn’t afflict files stored on NAS or perhaps certain sorts of external storage (depending on how the external drive is formatted). But multiple people have confirmed the bug, and Roon acknowledges that there has long been a ticket in for it.
That is strange. I am not saying there is no bug, as there obviously is. I am just wondering if the bug has more to do with using iTunes to tag your songs opposed to using a different metadata editor. That seems to be the only difference between out set ups so it was just a suggestion if you wanted to try it before migrating back to the Mac mini. Maybe not worth the time though depending on how many songs are affected. But all that matters to me is that you get it working again
Yup, there are several renaming solutions out there, but they will result in Roon seeing the files as newly added, losing any metadata associated with the previous versions (date added, play count, etc). That’s a nonstarter for me.
I think you’re likely correct that it’s about allowing iTunes to do all the tagging and file path naming. The truly mysterious part is that Roon can still see and analyze the files (which means RoonOS can see these file paths just fine), but just won’t play them.
And no need to worry about me, my Core is once again working great on my old 2014 Mac mini, which I was using before migrating to Nucleus. In fact, since I was simply mirroring its drive to the Nucleus, the drives were always identical, making return migration pretty simple (knock wood, it’s working so far).
Forgive my ignorance, but can’t this be solved easily by updating the files’ metadata tags using a simple free utility as a one-off? My library started on a mac, via itunes and now runs perfectly fine with ROCK
It’s accented characters in the file path, not meta-tags, that causes the problem. So you need to change folder and file names. And while you can use renaming tools for that, Roon will then see all of those files as newly imported, which loses metadata like date added, play count, and the like (which are important to me).
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
13
Character set encodings are famously tricky to get right across multiple operating systems (like MacOS and Linux). If you really want to deep-end, the .NET documentation on character encoding is good:
In particular, look at the section on grapheme clusters. Note that there are two different ways to represent an “á”, either as one or two Unicode code points. Misunderstanding which is being used is a major source of string-mangling between file systems. Malformed UTF-8, or Windows CP-1252 mistaken for ISO-Latin-1, are other biggies.
I’ve read several posts about character set conflicts across platforms, but I continue to be puzzled by the ability of Roon to see and analyze the files (including showing the correct file path, with the accented characters), but inability to play them. Doesn’t that suggest a bug in the app, rather than a failure at the OS level (but I’m no programmer, so what do I know)?
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
15
No, you’re right, I think. I’m just guessing, too. But “the app”, the Core, is knitted together from dozens of different toolkits, some done in .NET, some in other frameworks, all of which have to work together. And in my experience, sometimes the assumptions one toolkit makes about character set encodings are off, or just plain buggy, or poorly documented, or undocumented. It’s the old saying – the nice thing about standards is that there’s so many to choose from.
Just got an RMA from Music Direct to return my Nucleus. I love Roon, but they’ve still got plenty of bugs to iron out. What’s most disappointing is the lack of support for their product. It’s back to my MacBook as a core.
I do have some professional experience in this area and I’m pretty sure that @Bill_Janssen’s “guess” is close to the money.
Character encoding on file systems is a bit of a poorly documented nightmare. IRL I have spent a lot of time analysing “digital donations” for collecting institutions which arrive from “international randoms” on hard drives. Usually the problems are caused by genuinely different encodings as Bill eludes to on his earlier post, but even when both systems share “straightforward” UTF-8 there can be issues, particularly if network access is added to the mix:
Finally, there’s an awful lot of code out there that pays little, if any, attention to character encoding at all. It’s the kind of issue that you only realise is a problem when it goes wrong. Given Roon uses a lot of different code libraries the chance of them all handling character encoding properly and consistently is slim to none. If you think this is bad, try file systems that use Asian characters
This makes a lot of sense. So some modules (like the ones that do the initial cataloging and signal analysis) might handle the Mac/AFS/iTunes character set correctly, while other modules (like playback) might be choking. That makes sense to me. Good news: maybe it can be fixed. Bad news: who knows how long it could take? So I’ll keep an eye on these threads and consider coming back to a Nucleus some day in the future.
But in the meantime, this really should be disclosed in the help center Mac-to-Nucleus/ROCK migration docs. It might not matter to every user, but it’s likely to matter to a significant number considering a move from a Mac Core. It took me several weeks, plus searching the forum, to realize this was happening (because Roon silently skips affected tracks).
The issue here is that it’s quite possibly not the Roon team’s issue(s?) to fix. Getting changes made to third party libraries is trickier. You can simply log the fault with the other project and wait but if nobody picks up the bug that can be a long wait. Alternatively you patch the code yourself and offer the fix, but even this has to be tested and fitted into the other project’s release plans. Running your own “fork” (alternative version of the project) with the fix can be fraught with issues as well. One fix in a fork is usually fine, but if you keep doing this you fall out of synch with the original and can’t upgrade when they finally do.
Just to note I don’t see this problem. Core(s) are Ubuntu Server(s) on NUC(s) or similar. Local storage is ext4. Whenever I buy digital downloads, I stage them via my Macbook and copy the folders to the core server(s) via an SMB/CIFS mount of the core’s local volume on the Macbook. Many accented characters in path names, eg.
/media/FLAC/HiRes Downloads/HDtracks/Cécile McLorin Salvant/For One To Love
Roon plays them.
There must be something more specific that causes the problem, it’s not just some macOS vs Linux vs Roon generic problem.
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
21
Exactly. I’ve lost count of how many bugs in other people’s libraries I’ve had to fix myself, then hammer on the maintainer to get the patch integrated upstream. And character set bugs are hard to explain, for some reason. Hard to get the upstream maintainer to understand what’s going wrong.
1 Like
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
22
Wonder if it’s an issue with ROCK, then? I’ve never tried it; anyone know what distro it’s based on?
I also have tracks with accented characters in them. But they’re rips from CD on an Ubuntu system (UTF-8 filesystem), transferred via SMB to my NAS (again, another Unix variant with a UTF-8 filesystem) where my Core is running. They play just fine.
