Files with accented characters do not play [Fixed in Roon 1.8 (Build 806)]

[Mark_Mitchell]

Core Machine (Operating system/System info/Roon build number)

Windows 10 Pro 10.0.19041
Core i5-6500T 2.5GHz 8GB RAM
Roon 1.7 build 610

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Netgear nighthawk router, unifi wifi, all components on ethernet where possible, ios devices on wifi

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

iMac, iPad 7 headphone jack

Description Of Issue

After migrating library from Mac to Windows files with accented characters do not play with error, Playback was interrupted because a track failed to load.

Have tried restarting core, and forcing recheck of files, but error remains. Screenshot attached.

[Martin_Webster]

Filenames with accents arwe not a good idea for interoperability, especially when moving from MacOS to Windows/ Linux. Your best bet is to rename the files with a batch renamer and subsitute ü with u etc. You can do this using Finder on your Mac.

[killdozer (Brutalise me with music)]

Rock having problems with special characters (German äöü) in folder names

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 equa…

[streamy68]

The problem I have after migration from Mac to Rock might be similar but is not the same. Files with accented characters play well. All files in accented folders do not play. And in my case it happens when the external drive is exFat formatted. It does not happen when a HFS+ is attached. In both cases the files and folders were copied to the drives on MacOS. Also, through Samba all accented characters read well on both drives independent on formatting, both from folders and files, and can be copied without problems.

[noris]

Hi @Mark_Mitchell,

Where are the media files now stored? Are they on the Windows-formatted drive or still on a MacOS drive?

[Mark_Mitchell]

Files are on the windows (NTFS) formatted drive

[noris]

Hi @Mark_Mitchell,

Can I please ask that you upload a few example of files which have this issue (to Dropbox / Google Drive / ect) and private message me a link (click my name -> message)? I would like to try to import them on my end, thanks!

[Mark_Mitchell]

Sample files sent. Finding more and more artists impacted. Röyksopp, Björk, etc. The file seem to be recognized if removed to a directory without the ö character, quit roon, restart roon. A force rescan didn’t seem to pick up the change. With the above workaround all play counts and track customizations are lost. Any recommendations on how to preserve this information on tracks with a ö during a Mac to Windows migration would be very much appreciated!

[noris]

Hi @Mark_Mitchell,

Thanks for the files! I have made a ticket for our QA team and have requested some feedback regarding your case. I’ll let you know once I have more info!

[Mark_Mitchell]

Hi Noris,

Any update from the QA team?

Thank you,
MM

[noris]

Hi @Mark_Mitchell,

Thanks for your patience here. We have tested the files on 3 Windows QA machines on NTFS drives, on the latest public Roon release, and we have found playing these files.

It is possible that the issue is stemming from where the files are being stored, can you try to upload the files to a flash drive, add the flash drive as a storage location, and see if you have the same issue in Roon?

[Mark_Mitchell]

Hi @noris,

I agree. Per my note above the files play on Roon on Windows after removing the files and re-adding them. The problem piece is that all the metadata and track edits are lost in the process. Re-adding the files via a flash drive results in the same behavior, songs play, but metadata is lost.

Is there a recommendation for how to retain the metadata for these artists when migrating from Mac to Windows?

[noris]

Hi @Mark_Mitchell,

@Mark_Mitchell

The problem piece is that all the metadata and track edits are lost in the process. Re-adding the files via a flash drive results in the same behavior, songs play, but metadata is lost.

Is there a recommendation for how to retain the metadata for these artists when migrating from Mac to Windows?

The Metadata Roon stores lives in the Roon Database, and if you want to transfer this between two Cores, we have a Migration Knowledge Base Article you can follow!

Basically, this involves creating a Backup in Roon on one of the PCs and then Restoring it on the other, the Migration Guide provides more in-depth information.

[Mark_Mitchell]

Hi @noris

Thanks for pointing me to the migration documentation. After following the documented migration steps to move my Roon Database from Mac to Windows, the files identified will not play.

If I remove the files and re-add them to the library, the songs will play, but the Roon Database metadata (track customizations, play counts, etc) are lost.

I am looking for support on how to successfully migrate these tracks and retain their metadata when moving Roon Database from Mac to Windows.

I suspect there could be a bug in the way the database export/import process works when crossing platforms. Is migrating from Mac to Windows supported functionality?

[streamy68]

My experience is that the files only do not play when they are in folders that that have accented characters in the folder name. Taking out the accents of the folder names immediately solves the problem. Tracks with accented characters in the file name play well and all metadata is still preserved. At least this is my experience with Rock handling files that are migrated from Mac to Rock on hard drives. In my case it is not to NTFS but to ExFat, but I think it is the same.
Roon needs to fix this bug, I have reported it in another thread and got confirmation that they will look at the issue, so far no further feedback. I think it is an easy to solve problem, but not so obvious in USA where since1980 ASCII is sufficient.

[ToneDeaf (Ozzie)]

It’s a very hard nut to crack for Roon, perhaps even impossible, because problems with character sets in file and folder names can manifest at file system and OS levels, and in different guises. The issue is not at all restricted to folders.

Just an example:

The other week I added an album purchased on Bandcamp to Roon. Of the 15 tracks, one had filename:

“05 i can see my country from here., ii. liberté, égalité, fraternité…M4A”

The ingest process was:

• download zip file with archive to android phone.
• unzip into local folder on android phone
• copy folder from android phone to NAS storage (exfat formatted), automatically scanned by Roon

In Roon, running on MacOS, I noticed that the track count was off by 1, and on closer inspection this track was missing. The MacOS file manager did also not show the file.

In contrast, from Android it was visible without any issue, and on a Windows 10 PC it showed, but with 2 ‘funny characters’ for each é. For additional joy under Windows, editing the filename was not possible, because the complete path was longer than it appeared happy to write to.

In this case, the obvious fix of replacing accented characters with unaccented ones from the android phone worked wonders: the file immediately showed up in MacOS file manager, and the missing track appeared in Roon.

Subsequently changing the offending characters back into é, but from MacOS, was not a problem for Roon.
This makes me suspect that the underlying issue is how different OS / file system combinations deal with (intended) decoding of multi-byte or variable width character encodings in file and folder names, or fail to deal with them. A bit like IS0 8859-1 and the like versus UTF8, 16 etc. In this case, I would struggle to see how Roon could do better than the OS it is running on.

Although it’s not, I believe, simply about ascii / non-ascii, the safest thing would likely be to stick to subset of printable ascii, or at least to revert to it as soon as there appears to be problems like this in your ingest of files - especially when the setup and workflow involves different operating and file systems.

[streamy68]

I agree, to a certain extent. But Roon/Rock handles files in folders with accented characters quit well. They are perfectly readable through a samba share, including the folder name. They are correctly imported, analyzed for metadata generation, loudness correction etc., but do not play. So, there must be some inconsistency in the Roon implementation (I would call it a bug) of the player module.

[noris]

Hi @Mark_Mitchell,

Thanks for those additional details. One thing which might help here is seeing the Roon logs right after the issue occurs.

Can you please reproduce the issue, note the exact local time + date + track impacted and then use these instructions to send me a set of logs?

I can check if there’s a specific error being outputted.

[Mark_Mitchell]

Logs sent. The issue it seems is the file path where Roon is expecting these files to exist. Basically the ö character is being represented as two characters in the Roon database, where windows uses a combined ö character. Hopefully there’s an easy way to find and replace the incorrect characters in my Roon database.

[noris]

Hi @Mark_Mitchell,

Thanks for sending your findings and logs over, this is very helpful!

@Mark_Mitchell

Basically the ö character is being represented as two characters in the Roon database, where windows uses a combined ö character.

I’m also seeing this in the files you sent, so I’ve noted this on your ticket and I have let QA know of this aspect. Once QA has had a change to review your case with the new information, I’ll let you know!