Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ncjay]

Summary: "Portable Library" conversion from Mac to Windows fails with accented characters in path/filename.

Details:
I have my rules set up and the Windows library works beautifully for Artist, Album or Name with no accented characters.  However:

Situation #1: accented characters in Artist or Album: the album and songs will display, but with the "no entry" icon in far right column of the Files view.  Attempting to play one of these selections results in a "file could not be found" error. 

Example: Artist: Alizée; Album: Gourmandises; none of the files in album are found.

Situation #2: no accented characters in Artists or Album, but accented characters in one or more song Names on that album.  The song Names with no accented characters are found and play, the song Names with accented characters result in the same error as in Situation #1. 

Examples:  Artist: Zaz; Album: Paris; Title: La Parisienne is found and plays, but Title: Champs Elysées is not found and results in the same "file could not be found" error.

Other info: all of these work perfectly on the Mac.  So something is likely going wrong with the different character sets between the two OS'es.

thanks
ncjay

[Matt]

Do you have an example filename in MC (before and after Portable Library) and what it should be instead?  Thanks.

[ncjay]

Do you have an example filename in MC (before and after Portable Library) and what it should be instead?  Thanks.

Sure, Matt, and thanks for replying.  I'll use an example from Situation #2 above.

The filename in MC (Mac version) is /Volumes/public-1/iTunes/iTunes Media/Music/Compilations/Paris/05 Champs Elysées.m4a - and what it should be in MC (Windows version, and according to my "Portable Library" rules) is \\192.168.1.210\public\iTunes/iTunes Media/Music/Compilations/Paris/05 Champs Elysées.m4a (or, I guess, \\192.168.1.210\public\iTunes\iTunes Media\Music\Compilations\Paris\05 Champs Elysées.m4a to be precise.  You get the idea though).

For comparison, another track on the same album in MC (Mac version) is /Volumes/public-1/iTunes/iTunes Media/Music/Compilations/Paris/03 La Parisienne.m4a - and in MC it should be \\192.168.1.210\public\iTunes/iTunes Media/Music/Compilations/Paris/03 La Parisienne.m4a .  And it plays without a problem.

Two screencaps attached - the Mac version and the Windows version.  The Windows version has the "no entry" icon for tracks 5 and 12, both of which have accented characters in their names.

[Matt]

Thanks.  Could you mail a log to matt at jriver dot com showing failing to play one of the files with accents?

I would have expected our filename stuff to replace with UTF-8, but maybe that's not happening in some cases?

Thanks.

[bob]

I just tried this with the samba server on my Id and it worked fine.

Started in windows, created a library of 2 albums with various accent marks in the folder and filenames.
Backed it up.
Restored on Mac M1.
Library->Portable Library
Set the rule
exit that dialog

Stuff plays.
I do get the (-) on all of the files I imported but when I exit MC and restart it the (-) is gone.

[ncjay]

Thanks, Matt.  You went from Windows to Mac, right?  I'm going in the other direction, Mac to Windows.

[bob]

Thanks, Matt.  You went from Windows to Mac, right?  I'm going in the other direction, Mac to Windows.

Ok, that was me (Bob).

Do the rest of the parameters to this test add up?
Are you using SMB on both ends (not AFP on the fileserver for the Mac share)?

[ncjay]

Whoops, so I see, apologies, Bob.

The rest of the parameters add up, and in fact I reproduced your test here - in both directions.

Test #1: Windows to Mac

• I created a new library with two albums: "Zaz - Paris" and "Alizée - Mes courants électriques", on the Windows machine, with the source being my NAS (192.16.8.1.210 - more about that in a moment).
• Backed it up
• Restored it on the Mac and set my Portable Library rules
• Everything played fine, including all songs with accented characters in the title in both albums.

Test #2: Mac to Windows

• I created the same new library with the same two albumswith the source being the same NAS.
• Backed it up
• Restored it on the Windows machine and set my Portable Library rules
• Nothing played/was found on the Alizée album; the two songs with accented characters on the Zaz album similarly were not found/did not play.  The other songs on the Zas album were fine.

Regarding the share types on the fileserver:  hmmm.  It supports both AFP and SMB, and I have them both activated.  The Mac mounts its shares via AFP, and the Windows machine mounts its shares via SMB, the default protocols for each platform.  Might this be the source of the problem?

Thanks
ncjay

[bob]

Whoops, so I see, apologies, Bob.

The rest of the parameters add up, and in fact I reproduced your test here - in both directions.

Test #1: Windows to Mac

• I created a new library with two albums: "Zaz - Paris" and "Alizée - Mes courants électriques", on the Windows machine, with the source being my NAS (192.16.8.1.210 - more about that in a moment).
• Backed it up
• Restored it on the Mac and set my Portable Library rules
• Everything played fine, including all songs with accented characters in the title in both albums.

Test #2: Mac to Windows

• I created the same new library with the same two albumswith the source being the same NAS.
• Backed it up
• Restored it on the Windows machine and set my Portable Library rules
• Nothing played/was found on the Alizée album; the two songs with accented characters on the Zaz album similarly were not found/did not play.  The other songs on the Zas album were fine.

Regarding the share types on the fileserver:  hmmm.  It supports both AFP and SMB, and I have them both activated.  The Mac mounts its shares via AFP, and the Windows machine mounts its shares via SMB, the default protocols for each platform.  Might this be the source of the problem?

Thanks
ncjay

I think that the filesystem mapping differences might explain it.
If you could try a test with SMB on your Mac instead of AFP it would be interesting.

[ncjay]

I think that the filesystem mapping differences might explain it.
If you could try a test with SMB on your Mac instead of AFP it would be interesting.

I did this test this morning.  I repeated Test #2 below, but first I unmounted the file share on the Mac, disabled the AFP service on the fileserver (leaving only SMB), remounted the fileshare, and confirmed that it was mounted via SMB.

The results were exactly the same as in Test #2 - anything with an accented character in the Artist, Album or Name is not found, and will not play.

So I started thinking about this.  There should be no filesystem mapping difference going on, since the exported library is a .zip file.  As far as I know there's no system to system translation that goes on with a binary zip archive.  Once the target windows machine unzips it, it should be the same as was created on the Mac.

I unzipped my test library and couldn't figure out which file held the pathnames, so substituted another test:  I exported a playlist (from iTunes and also from MC) with just the tracks from the album "Alizée - Mes courants électriques" included.

A sample line for one particular from the MC Mac playlist .xml looks like this:
<Field Name="Filename">/Volumes/public-1/iTunes/iTunes Media/Music/Alizée/Mes courants électriques/11 Cœur déjà pris.mp3</Field>

...but in the playlist exported from iTunes, it looks like this:
<key>Location</key><string>file:///Volumes/public-1/iTunes/iTunes%20Media/Music/Alize%CC%81e/Mes%20courants%20e%CC%81lectriques/11%20C%C5%93ur%20de%CC%81ja%CC%80%20pris.mp3</string>

Ugh.  So if the same thing is happening in the exported library, then it's the way the data is being written out.

Let me know if you need a copy of that playlist, or if there's anything I can do to assist.  And thanks for your attention to this issue.

[bob]

Ok, we got that. It's because of how MC Mac handles those characters internally.
Fixed in the next windows build.

[ncjay]

wonderful.  Thanks Bob!

[ncjay]

A couple of quick tests here indicate that this problem has been resolved with the new 28.0.53 version (although I didn't see it explicitly called out in the change log).

Thanks to you and all who worked this issue!

ncjay