Hi @noris,
Any update from the QA team?
Thank you,
MM
1 Like
Hi @Mark_Mitchell,
Thanks again for the report! I spoke to QA regarding your case and yes, they agreed that the difference in character sets between Windows and Mac could be the cause of this issue.
We plan to schedule some testing to see if we can reproduce your findings in the QA lab, and if so, weāll put in a ticket with the devs to look into it further.
I canāt comment on a timeline of when the ticket will be reviewed but thank you for your patience here!
Still running into this issue. Finding now that I also cannot delete items from my library if the filenames have accented characters. In the attached screenshot I attempted to delete an album, and Roon successfully deleted all files except for those with accented characters. Even a workaround would be acceptable.
I just migrated my Mac-based Roon Server to ROCK and am having the same issues with accented characters. Albums in folders with accented characters will not play and individual tracks with filenames containing accents will not play either. I get a ātrack failed to loadā error. All I have to do is replace the offending characters with their non-accented counterparts and the tracks work perfectly. These are files that have imported into Roon without a problem and the sound files play fine when I access them with my Mac via the SMB share. These same files worked fine when the files were still on the old HFS+ formatted drive (attached to the ROCK). But, since that was read-only, I copied them to an exFAT formatted drive and now accented characters are a problem.
I have two concerns about batch changing the accented characters:
- will I lose play counts, edits or other details if Roon thinks they are new albums
- will this be necessary with 1.8 (i.e., will this get fixed, obviating my need to do this)?
2 Likes
Hi @Mark_Mitchell,
I spoke to the team regarding your case and we are still looking into this ticket, a manual workaround for now is to locate the files on the hard drive and remove them that way or try the accented characters replacement suggestion @meATroon mentioned.
@meATroon - We are looking into this, and the ticket is in the QA queue, I canāt comment on a timeline of when it will reach the dev queue, so I would manually correct the files for now if thatās working on your end.
@noris thanks for getting back to me about this. Before I do the mass filename changes, could you reassure me that the chances are low for previously imported files to be seen as newly imported after the filename changes. I use the original import date extensively when listening to music as it indicates what I liked at a particular time (regardless of when it was actually released). I would also not like to lose my play counts, manual edits, or other information. Once again, thanks for getting back to me especially during the holidays. Have a wonderful new year and I canāt wait for the new release.
1 Like
In my experience the songs will be recognized as new using the workarounds described. All track play counts and metadata edits will be lost.
Accepting that, I am having trouble getting windows to filter down to a list of files with accents, so not sure how I would even implement the workaround. I might see whether the next update fixes things, and otherwise scrap my Roon library as migrated and start fresh on Windows 
1 Like
Hi @meATroon / @Mark_Mitchell,
Thank you for the feedback here and sorry to hear that manually correcting the files didnāt also import the metadata.
Iāve let QA know of @meATroonās report as well and we have an active investigation into reproducing this behavior in the QA lab.
I canāt comment on when exactly the ticket will be ready for dev review, but thank you for your patience here while the ticket is in progress!
While we wait for resolution, can a note be added to the migration document that files with accented characters will fail to play after migration?
1 Like
In my case accented filenames play after migration of Roon core from an MacMini to a NUC and ROCK. What does not play are files in folders with accented names. Can you confirm that your files with accented filenames do not play when they are on the drive in folders that have no accents? After migration to ROCK I transferred my files from a HFS to ExFat and even then the files in accented folders were skipped. Renaming the folders e.g. Ƥ to ae made them play immediately within a second. I have reported this here in the forum and also commented above in this thread. Iām asking for clarification because a note in the migration document should also reflect this behavior. It can be that different accents behave differently. In my case itās Ć¤Ć¶Ć¼ from German in folder names that caused the problem before I renamed the folders.
1 Like
Hi @Mark_Mitchell,
Thanks for your interest into this issue! I have recently discussed your case with our QA team and we are still actively looking into this issue and trying to get this reproducible for a development ticket. Work is in progress, so thanks in advance for your patience as this ticket makes itās way through the queue!
Thanks @noris
Happy to work with the technical team, share screen, provide additional diagnostic logs etc.
1 Like
Iām seeing exactly the same issue after migrating from Mac/iTunes to Nucleus with Internal Storage SSD. After migration, Roon cannot load files stored in folders with names that include accented/special characters. Changing the folder name to eliminate the accented character fixes the problem.
Bjork, Kodaly Quartet, Jose Gonzales, Bela Fleck, Bernard Lagace, Janelle Monae, Jeno Jando are just a few of the problems Iāve found so far. I have no idea how many album folder names are similarly afflicted. Not sure how to search and replace every special character that causes this.
Folder names all created by iTunes automatically (most recently by OS High Sierra, although my iTunes music library goes back to 2001).
2 Likes
More re my post above: Roon successfully analyzes the tracks and displays the file path in the āfile infoā display, but wonāt play the track, showing a āfailed to loadā message.
Here's what Roon shows as the filepath via "copy filepath to clipboard": /roon/sys/storage/mounts/InternalStorage/iTunes/iTunes Music/Music/Janelle MonaĢe/The Electric Lady/01 Suite IV Electric Overture.m4a
Hello @Fred_von_Lohmann1 ,
Thanks for letting us know about the issue on your end as well. There is an existing ticket regarding this behavior, so I have added your report to the ticket. Weāre looking into this, thanks in advance for your patience!
Same problem hereā¦
Imported files on my iMac using iTunes (now Music) and files are stored on a NAS.
Iām using Roon on Rock (NUC), accessing those files.
They have been imported in Roon library (with all meta data).
But those files with accented characters cannot be read by Roonā¦
And I have plenty of them.
1 Like
Is this the same problem ? It has been there for a few years and not fixed.
If a track is imported in windows if the track has an accented character the macos cant read it. However vice versa works.
When you check the filenames in a command window the file names are different in macos and windows
Noris, Iām sure the team is busy with 1.8 revisions, but please let me know if thereās anything I can provide to help move this ticket forward. If thereās not a fix forthcoming, Iāll probably give up my Nucleus and go back to a Mac mini for my Roon core.
This should also be added to the Nucleus migration document, so others coming from Mac iTunes libraries are aware of this limitation for migration to Nucleus.
Just confirming that this bug also applies when the special character appears in an album folder name (e.g., Live at Sine-Ʃ), as well as when it appears in an artist folder name (e.g., Bjƶrk).
This is really frustrating, as it causes many tracks to silently get skipped in playlists and shuffle. Itās like some of my favorite artists and albums are just disappearing from Roon.
And the bug also applies when the special character appears in the song title, even if there are no special character in any of the folders that contain it (e.g., Rue du DĆ©part).
Any update on this ticket, @Noris?