Ludek - I just confirmed that it's fixed for me in 1630. Thanks!

I discovered that I have the same issue after adding album art to a number of songs last night. I was using build 1627 and upgraded to build 1629 this morning and ran a test and same problem, several song names get converted to 8.3 format. In this case it was 3 files out of 11 but it seems to vary. I am running Windows 7 Pro SP1 64-bit.

Thanks Ludek. I just uploaded a debug log for you at ticket id DTV-349172. Let me know if that wasn't the right thing to do and I'll send it wherever you specify.

Thx, I added it as http://www.ventismedia.com/mantis/view.php?id=10692 and will look into it.

Well I can list the steps, but I don't think you'll be able to peform them due to the strict conditions. So tomorrow I'll do a debug log.

1. Install Parallels 8 under OSX 10.8.3 on your Mac.
2. Create a Windows XP SP3 virtual machine.
3. Install MediaMonkey on the WinXP VM.
4. Map a drive letter in the WinXP VM to a directory on the Mac's hard drive.
5. Add an MP3 existing in that directory to MediaMonkey.
6. Note the MP3's filename.
7. Edit the MP3's album art field (add an image, remove an image, any edit).
8. Note the MP3's filename has changed to 8.3 on disk (though not in MediaMonkey), for example from "02 - Don't Cry.mp3" to "02-D~UZ1.MP3".

I know very few people run MM on their Mac using virtualization software like Parallels, VMWare, VirtualBox, or Wine. So I'm guessing this won't get the priority I'd like it to. Still, it should at least be tracked, since it results in immediate database corruption. Especially since it was introduced in a specific build (4.1.0.1609) after working properly since at least 3.0.1.

I did find some interesting behavior when trying to find another way to reproduce. Here are the steps I took:

A. Map a drive letter to a networked drive (in my case a directory on my NAS).
B. Add an MP3 existing on that drive letter to MediaMonkey
C. Note the MP3's filename.
D. Edit the MP3's album art field (add an image, remove an image, any edit).
E. Note that while "1 file to tag" is displayed, a file appears in the same directory with filename in the format 8.3.XXXXX, for example, "020D~UZ1.mp3.XXXXX".
F. When the tagging operation is complete, only the original file (with correct name) remains.

The similarity in filenames seen in steps 8 and E may just be a coincidence, but maybe not.

At any rate, what should I do with the debug log once I create it?

Scott wrote:Well, darn. Should the Mantis entry be changed away from resolved, or should a separate entry be created?

I also cannot reproduce (build 1629, using Windows 8 ) given the steps you gave in the original post. Could you provide more concise steps to reproduce or a debug log? Thx.

Well, darn. Should the Mantis entry be changed away from resolved, or should a separate entry be created?

Scott wrote:I went ahead and confirmed that the issue appears in build 4.1.0.1609, the first public beta build. I confirmed that it doesn't appear in 4.0.7.1511, but unfortunately that's a big gap in builds. If you point me at any intermediate builds I can help narrow down exactly when the bug appears.

There are no builds between those.

I went ahead and confirmed that the issue appears in build 4.1.0.1609, the first public beta build. I confirmed that it doesn't appear in 4.0.7.1511, but unfortunately that's a big gap in builds. If you point me at any intermediate builds I can help narrow down exactly when the bug appears.

Installed 1628 today, and unfortunately I've confirmed that this didn't fix the problem. Any change to album art from the virtual WinXP machine changes the filename to 8.3 format on the host drive.

No other tag changes cause the rename.

Should I start testing older builds to find out exactly when the problem was introduced?

No I'm using Windows XP, but it's in a virtual machine using Parallels 8 for OSX.

The check makes sense, I'll verify in 1628!

I guess you are using Windows 8 ?

There is something wrong in Win 8 that sometimes it returns 8.3 filenames.

I cannot replicate, but I will add a prevention/check to our code so that MM always ensure that it is not 8.3 filename when moving/copying and will auto-convert from 8.3 to full filename.


Will be fixed as http://www.ventismedia.com/mantis/view.php?id=10626

Did you map your OSX host system to a drive letter or access it from MM in Parallels some other way?

I'm unable to replicate

Hmm... related in that both involve truncated 8.3 filenames, but I think that's about it. I actually think they're polar opposite problems, though as you say they could be related somehow down in the code.

If I read it correctly, in the linked problem MM is leaving the file alone but creating or changing database entries to point to a truncated 8.3 version of the filename. In my problem, MM is leaving the database entry alone but accidentally changing the actual filename (if album art is touched).