Bye Nucleus, back to Mac Mini Core

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).

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)?

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 :wink:


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).

1 Like

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.

Debugging other people’s code sucks anyway :wink:

1 Like

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.

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

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.

I don’t believe it is a generic thing at all, that would be easy to detect in the first place. There are a lot of potential differences between different copy chains and they won’t all involve the same underlying software libraries. I’ve seen this problem introduced by using errant zip software, someone zips the files from one system and the names are mangled when they’re unzipped on another.


I don’t know how ROCK/Nucleus set up their CIFS/SMB smb.conf… Here’s what I use on my Ubuntu server(s). It definitely allows macOS to write paths with accented characters.

path = /media/FLAC
valid users = **REDACTED**
read only = no

I think I had some issues involving macOS, Linux, and exFAT some years ago, but I can’t remember the details now.

In my researching this issue, I’ve only seen it reported on internal drives for Cores running ROCK/Nucleus, as specified in the original post. So I agree that it doesn’t appear to be a generic MacOS/Linux/Roon problem.

If this isn’t occurring with the Mac (and, incidentally, I can’t remember ever having a characters-in-name issue with a Mac), then what is different from Mac to NUC? If there are library sets that work, why aren’t they universal? (I don’t know much anything about modern programming).

Well, quite a bit. But I don’t know what version of Unix the Roon OS is based on, nor what a Nucleus version of it does or does not contain. Or how the files were transferred, exactly. Clearly one drive was SMB mounted on the other computer, but I don’t know if it was the Mac drive or the Nucleus drive. And then there’s a DB restore from Mac to Nucleus, as well. Some interesting possibilities for happenstance there, as well.

That is a crazy anomaly. I recently switched from a Mac mini core to a NUC and found the same issue.

What I have found is that it is not necessary to change the metadata in the audio files themselves, you only need to remove the diacritical marks in the folder’s filename.

So, perhaps others, like I, import music into a Mac and do metadata editing in Apple Music (a woefully and increasingly terrible application), before moving to your music library’s main storage. You don’t have to go into, say, all of your Bjork albums and edit the artist’s name. Just go to the mail folder and name the artist Bjork instead of Björk and rescan your Roon library.

1 Like

Rereading the thread, this seems the key passage. The Roon db contains references to file paths for each track. If those file paths change under it, Roon won’t be able to find them. Simple changes such as changing the path prefix for the whole library seem to be handled by Roon, but less regular changes might not be.

There are two places (at least two) where this could be going wrong.

  1. iTunes uses file paths that do not transfer exactly to Linux. In that case, when the iTunes folder hierarchy is copied over SMB, paths are mangled in the Nucleus, and the Roon db file references won’t find them. I do move folders with accented file paths from macOS to Linux over SMB, but I don’t use iTunes and I don’t know if it uses Linux-incompatible character encodings.
  2. Nucleus/ROCK sets the SMB share for an internal disk with a restricted Unix charset (unicode and unix charset smb.conf flags in particular). I don’t know why Roon would do that, but who knows…

Just LOVE it :heart_eyes: :heart_eyes: :heart_eyes: :heart_eyes:

It is so true , how about Classical Metadata