Print

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

[MartinG]

I just want to let you know a problem and it's solution, when working with a MAC, Windows and NAS in a network.

Situation:
I am using JR 17 in the revision 122. I am ripping many CDs - and the majority has classical content - via the little MAC freeware tool XLD. It is a very powerful tool, that is able to do high speed accurate rips. That I do not use the JR integrated ripping tool has nothing to do with the quality of the integrated ripping tool, it is just that I use my music server solely for music reproduction. Nothing else. It is optimized for that kind of work and there is no mouse or keyboard.

However, XLD uses e.g. MusicBrainz.org to identify the CDs. Very often the tracks do have special characters like ", | or ?. With classical music a typical track name would be 01-01 "Nessun Dorma".flac. Also Pop songs here and then are ripped with a question mark at the end, e.g. What is the 411?.flac. When ripping the CDs and checking the entries on the mounted Synology NAS drive, everything worked fine. At least checking it via the MAC it looked like being OK.

When mapping the NAS via Windows and importing the files to the JRiver library, you will get no error report at all nor will you get any information about reading problems ... till you start listening to the music and find out, that Puccini's Madama Butterfly does consist of only 3 tracks (track 3, track 5 and track 18) instead of 33! On the other hand JRiver imported aha's CD "minor earth | major sky" (exactly written like this, but without double quotes) without problems, only the path of the files looked somewaht strange. Going back to the iMAC all directories and files were listed correctly, so that I wondered why JRiver did not inport all the tracks correctly.

Long talk, short sense, the reason for this behavior is as follows:
MAC's work with an HFS file system. Synology works with an ext3 file system and Windows uses NTFS. That means, three diferent file systems. All of them communicate via a Samba share, that is emulated by the Linux operating system of the NAS. While file names or folder names with special characters like ?, " and | cause no problem in Linux or MAC surroundings, Windows can't work with files like this. This kind of characters are prohibited for use in filenames or folders. The Windows Explorer will show them similar to this: ~µMQHJW. That means the Windows system interprets this kind of files or folders as corrupted. Unfortunately JRiver does not inform about this kind of problems during import procedure and I just found out, that the listed music on my iPad is incomplete in many cases.

That means, if you do it in the same way like me and work mainly with MACs, you'll have to take care a lot that there are no special characters in the track or folder names. If you do so, everything works fine with JRiver.

Martin

[Vincent Kars]

This is indeed due to differences in file name conventions between the different operating systems.
Strictly spoken this not related to the file system but to how the OS deals with special characters.
It is also a matter of how Samba is configured.
This is called Mangled names.



If you manage to add this to the global section of SMB.conf
[global]
mangled names = no

You probably get

[MartinG]

Hi Vincent.
Thank you very much for this explanation/ hint. I didn't know that it is possible to manipulate this. I should have know you any earlier as that would have saved me a lot of time, grey hairs and bitten fingernails. 
Now I made it in a more aggressive way and killed all the special characters in the complete directory (more than 700 CDs) with the freeware tool Name Munger.
However, thanks a lot.

[Vincent Kars]

It is indeed a nice SAMBA option and indeed I discovered it to late too.

At one hand it is nice to have all those special character in the file name.
The moment one does “Generate tags from file name” it is much appreciated.
The moment you use a NAS (Linux) you will hit problems.

A nice new MC feature would be “Write OS independent file names”

[Listener]

A nice new MC feature would be “Write OS independent file names”

Martin ripped his CDs with XLD.  He needs such an option in XLD.

You and Martin focused on file system issues.  Differences in the way applications handle special characters, long file names and other boundary conditions can cause problems even with one file system.  Such differences may not be well documented. 

Using a single program for ripping, tagging and playback makes life simpler.  For a beginner, there is less to learn and fewer gotchas.

Bill

[MartinG]

Bill.
You are absolutely right. This is a file system issue. And - of course - someone would avoid problems like this in using the integrated ripping solution of the MC or just working inside a homogeneous Windows network. But I don't and I assume that there are more than just me, who don't.
So what surprised me was that there is not even a single hint by the summary window you'll get at the end of the import procedure. The information about "no errors occurred" is somewhat missleading.
I wonder if there is a way to identify problems like this by the import procedure and document it in the final window.

Martin

[Vincent Kars]

But I don't and I assume that there are more than just me

Sure, the combination Win on the PC, Linux on a NAS is a common one.

[Listener]

Bill.
You are absolutely right. This is a file system issue. And - of course - someone would avoid problems like this in using the integrated ripping solution of the MC or just working inside a homogeneous Windows network. But I don't and I assume that there are more than just me, who don't.
So what surprised me was that there is not even a single hint by the summary window you'll get at the end of the import procedure. The information about "no errors occurred" is somewhat missleading.
I wonder if there is a way to identify problems like this by the import procedure and document it in the final window.

What MC sees is filtered by Windows and the software on the NAS that responds to the network file I/O requests.  MC may not know that anything is wrong. 

If I were trying to solve this problem on the MC end, I'd start by looking at what Windows returns from API calls for a directory listing.  Are all the files present or are the ones with illegal characters missing?  If the file names with illegal characters are in the listing, how have the names been changed?

If those files with illegal characters in the actual file name are present in the directory listing, I'd try to open one using the name as provided in the directory listing.

---
I pointed out practical realities.  When you mix tools and file systems, you as a user have to know more.  You have to be prepared to learn about pitfalls and to do extra work to avoid them.

Bill

[MartinG]

Hi Bill.
Yes, we do.
At least that is the reason for me working with PCs. Others do crosswords, I try to cope with nasty PC problems.
But to return to serious conversation:
Again, you are right and there is nothing to argue about. But please tell me why the MC returns an error message about the following file path:

    M:\16bit_44.1kHz\Modest Mussorgsky\Pictures at an Exhibition, Original Piano & Orchestral Versions (Philharmonia Orchestra, Ashkenazy)\09 Pictures at an Exhibition: Promenade 3 - Les Tuileries (Children At Play in the Garden of Tuileries) - Bydlo (Polish Oxcart) (Orchestra version).flac
    M:\16bit_44.1kHz\Modest Mussorgsky\Pictures at an Exhibition, Original Piano & Orchestral Versions (Philharmonia Orchestra, Ashkenazy)\03 Pictures at an Exhibition: Promenade 3 - Les Tuileries (Children At Play in the Garden of Tuileries) - Bydlo (Polish Oxcart) (Piano version).flac
    ...

No, you do not need to tell me, that the path name length exceeds the Windows maximum of 255 signs. My question is, why does MC report this kind of failure while it does not give an information about special character problems? And this is - sorry for me insisting on this point - somewhat missleading.

Martin

[Listener]

Hi Bill.
Yes, we do.
At least that is the reason for me working with PCs. Others do crosswords, I try to cope with nasty PC problems.
But to return to serious conversation:
Again, you are right and there is nothing to argue about. But please tell me why the MC returns an error message about the following file path:

    M:\16bit_44.1kHz\Modest Mussorgsky\Pictures at an Exhibition, Original Piano & Orchestral Versions (Philharmonia Orchestra, Ashkenazy)\09 Pictures at an Exhibition: Promenade 3 - Les Tuileries (Children At Play in the Garden of Tuileries) - Bydlo (Polish Oxcart) (Orchestra version).flac
    M:\16bit_44.1kHz\Modest Mussorgsky\Pictures at an Exhibition, Original Piano & Orchestral Versions (Philharmonia Orchestra, Ashkenazy)\03 Pictures at an Exhibition: Promenade 3 - Les Tuileries (Children At Play in the Garden of Tuileries) - Bydlo (Polish Oxcart) (Piano version).flac
    ...

No, you do not need to tell me, that the path name length exceeds the Windows maximum of 255 signs. My question is, why does MC report this kind of failure while it does not give an information about special character problems? And this is - sorry for me insisting on this point - somewhat missleading.

You continue to assume that MC gets enough information to know that files whose names contain illegal characters are present in a directory.  It is quite possible that Samba (or the equivalent) or Windows are failing to pass on such file names.  If that is the case, MC has no way of knowing that some files are missing from the listing.

An experiment might be useful.  Two possibilities:

- Look at the contents of the directory on the server using Windows Explorer.  Are all the files you expect to see listed?  Are the files with illegal characters in the name listed with the exact name or have some characters been changed.  Double click on such a file and see if Windows tells MC to open the file.

- I think a <1 page command line C program using the directory enumeration API functions would show what information Windows is passing to  an application for a directory containing such files.

---
Your example of a path name that is too long fits my point about users needing to take care to avoid problems with boundary conditions.

Bill

[MartinG]

OK.
To make it short and also to sum it up: There is no way to deal with this kind of problem with inside MC.

This is a pity. Really. But nevertheless, even if I really love the JRiver MediaCenter ... and I think it is the best audiophile program available ... you never (!) will be able to lead me back to a Windows network.
Thank you for explanation and your time, Bill.

Martin

[Alex B]

The problem is with the Samba software on the NAS device. Apparently it does not handle the character conversion in a usable way. It should provide the Windows users legal and accessible filename paths even if it allows other operating systems to save names that do not follow the Windows standard.

If the files are inaccessible by the Windows operating system, neither MC can see or use the files.