I tried to find a corresponding topic but didn‘t. It could be that this is a bug in Rock. On an external USB attached exFat formatted drive Roon fails to play tracks that are stored in folders having special characters ä, ö, ü. Strange is that they play well when the drive is HFS+ formatted. From both drives (HFS+ and exFat) Roon Rock on a 10gen NUC imports correctly all tracks and albums from such ‚German language‘ named folders like ‚Züri West‘ or ‚Max Lässer‘. All files in subfolders are equally affected and do not play, but are well imported and analyzed. Could it be that I have something to change in the NUCs Bios settings or is it a bug in Rock. Really strange that with the Read only HFS+ in Rock all plays well. The problem is downtracked exFat formatting. When I change the folder to ‚Zueri West‘ the files play as before the move from a MacMini core to the NUC10 with Rock installed.
This isn’t a Roon issue but rather how Linux interprets non-ASCII characters–ö is two characters not one–on the filesystem. Unfortunately for you MacOS and Linux interpret them differently and it would seem that the folders were created on MacOS.
It’s the difference between U+00F6 (ö) and U+006F (o) plus U+00A8 (¨).
For interoperability it is better to remove these characters in filenames (and retain in metadata.)
File-system path encoding has always been a nightmare and the promised panacea of Unicode hasn’t really delivered. I’ve seen loads of problems over the years and plenty recently, here’s a starter for 10.
My favourite quote in the article:
Note that the invalid Unicode characters have been hex-encoded in this error message because otherwise trying to print them would result in another error.
Sure, I would agree with you, but why Rock handles the same dir names on an external HFS+ formatted drive correctly, but not on a exFat one? It is the same Linux OS?
By the way when accessing the exFat drive attached to the NUC running Rock through Samba shows perfectly correct folder names with German ‚Umlauts ä, ö, ü, no problem. Not like in old times with %xx how you could expect something Roon could fail to interpret when it searches to start playing the track.
That“s what I did and that“s why I‘m not filing this as support request. But still I‘m not convinced that this is a Linux problem Roon cannot solve. Still Roon perfectly imports all these files in the folders using ‚Umlauts‘ makes all the analysis, determines the Dynamic Range, but fails to play the files. And it seems to be about exFat vs. HFS+ both on Linux.
To add: It‘s not about file names. Files with ‚Umlauts‘ play well. It is about folder names with ‚Umlauts‘. Files in these folders do not play, independent on their names.
This is hard encoded on the disk. Both are UTF-8 but MacOS uses two characters not one. I suspect a folder scan works because it is simply recursive whereas to play a file you use the path … and U+00F6 and U+006F+U+00A8 are not the same or are they? That is, you could have two identical folders but they would have different paths and one won’t have a file in it!
Roon will use system commands to access the file system. Maybe Roon will comment, but as @killdozer says, this problem is not unique to Roon.
I appreciate all your explanations and agree. But still, I would expect Roon to scan the folders in the exFat drive from which I newly imported my library to remember the folder name how it reads it (with2chars instead of one, I would not care). But then why Roon can not play the imported track it found in the folder escapes my logic. Maybe, indeed it is time to ask Roon developers @noris or @danny.
Hi @streamy68 — I appreciate the detailed report. I’ve passed this information along to our QA team so we can do some internal testing and I’ll be sure to follow up with you when I have their feedback. Thanks!
Thanks for keeping me updated. In the meantime I had renamed the folders to remove all accented characters. Strangely, 2 days ago, I renamed one of the folders i.e. made a ‘o’ to a ‘ö’ and the tracks were still playing. Something, it did not do in Sept. 2020, with exactly the same folder. Could it be that in the meantime something had changed with updated ROCK, or has something changed in the database? I do not know. Anyway, for now I can play all my local files and might rename folders back or at least observe when new accented folder names enter my local library. And indeed I was using iTunes when ripping CDs to lossless ALAC at the time.
“something changed in the database” is a good way to think about it.
The bug that caused this is triggered by having a saved version of the file path (directory or file name, it doesn’t matter) in the database that is composed of different bytes from the path on disk but normalizes to display as the same characters. By removing all the accented characters and letting Roon import the files, you effectively changed the database entries to un-accented versions, and then when you re-added the accents the system saw the new accented paths and worked everything out.