I'm not aware that Windows treates files/folders with leading dots as hidden, Linux does, but Windows doesn't as far as I know.

Hmmm - I'm not using Linux, I'm using Windows 10. I'd argue that MM should understand that a directory or file beginning with a dot would be taken as hidden in Windows, and therefore shouldn't need any further attention by a user, especially one with limited techincal tendencies, who'd not want to fiddle with .ini files!

Anyway, that said, I did some more analysis, and the issue is reproducible, as follows :

1. Rip a CD with leading periods/dots, eg ...And Then There Were Three.

No problem. It's there in your library, and MM has an explicit pointer to the directory ...And Then There Were Three, and the files within. If you look at the actual directory in Windows Explorer, you see it if you enable viewing of hidden files. So if you never have to do anything from there, no issues ......

The issue comes if you have to rebuild your library should the MM database become corrupt, or you have to reconstruct your MM environment for whatever reason.

I've just done that, and voila : MM has ignored it because it is a hidden file ........so I'd suggest this is a design fault which you only see if you rebuild your database?

To resolve see: http://www.mediamonkey.com/support/inde ... o-organize

This is a Linux thing, where leading dots cause folders/files to be set as hidden.

I am a new user of Media Monkey , and have been building my library from scratch. I noticed that it wasn't showing ...But Seriously, by Phil Collins. This was after a rebuild after I had a DB corruption and I rescanned the music library, so I can't recall whether it was showing when I first ripped it. It's there in my file system, and I can see it as a hidden file, so MM obviously created the file as ...But Seriously. My SONOS system wouldn't see it either. I've renamed the album folder with one leading comma instead of the first period, and rescanned that album, and now it's visible (in both MM and SONOS), and showing the metadata title with the three leading periods. So I'd suggest this is a bug, in that MM is creating the folder with a leading period, rendering it a hidden folder. Interestingly looking at my legacy iTunes folders, it is in there as _..But Seriously, so I have to assume that is something iTunes did when I first ripped it.

I can reproduce: http://www.ventismedia.com/mantis/view.php?id=14539

I have an update on this issue.

This is actually a Windows issue. You can create folders with trailing periods but if you use Windows functions to view the directory the periods are automatically removed. Trailing periods are actually illegal but no error message is raised. Leading periods are however allowed. See this quote:

A 'dot' or 'space' at the end of a folder name are considered illegal characters for a folder name.

However, unlike other illegal characters, Windows does not display an error when you use these 2 characters. It will let you name the folder with a space at the end and it simply removes the space. In the case of the dot, when you press the F5 (Refresh) key, the illegal character (dot) is removed and the folder will display.

I'm not sure 'why' Windows 7 does this?

Ronnie Vernon MVP

Perhaps MediaMonkey should prevent you from adding trailing periods or spaces so that the issue of not being able to access the files does not happen.

MediaMonkey 4.1.19.1854 and Windows 10 64 bit.

In the location tree if you rename a directory to have a period or multiple periods at the end it causes issues with MediaMonkey. Here is an example:

I have a Black Era album called ...Then...

In the file location tree it was named Then

I decided to rename it in MediaMonkey (F2) to have the correct name of ...Then...

After the rename MediaMonkey showed the new name as ...Then... but the actual directory on the hard drive was ...Then i.e. no periods on the end. The MediaMonkey database and the actual directory structure no longer agreed and so the songs in the folder were no longer playable. I had to delete the folder in MediaMonkey and rescan it before the files were accessible again.