MediaMonkey forum

I've got a problem I can reproduce 100% of the time, but the conditions are somewhat unusual.

I'm running MediaMonkey in a Windows XP SP3 virtual machine on my Mac using Parallels 8. I share drives between the virtual and host (actual) machine, and thus regularly scan my Mac's download directory (mapped to M:) in MediaMonkey for Windows. I never have any problems with this in MMW 4.0, but in 4.1.0.1627 (and in 1626 as well), there is a problem:

If I edit the properties of a file on M:, everything works fine - until I change the album art. If I add or remove album art, or even "apply to all selected files" without changing anything, the underlying file gets renamed to an old DOS-style filename. For example, "fun_-_02_-_take_your_time_coming_home_live.mp3" will become "FUN_~5ZI.MP3".

MediaMonkey itself doesn't realize it's done this - in the file properties it still says "fun_-_02_-_take_your_time_coming_home_live.mp3", so the file becomes missing (grayed out) as far as MM is concerned. If I rename the file back to what it was, MM is happy and I can see that the album art tag actually updated correctly despite the rename.

I can edit any of the other properties of files on the M: drive, and the tags get saved properly. I can edit the album art without problem if the file is on the virtual machine's virtual hard drive (C:) or even if the file is on the network (\\DROBO\Music\whatever). And I can do all of the above on the M: drive in the 4.0 release. Only when I edit the album art on a file on the M: in 4.1 do I hit the problem.

Does this explanation make sense?

I guess related to this previously reported issue:
http://www.mediamonkey.com/forum/viewto ... 87#p354449

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).

I'm unable to replicate

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

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

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!

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?

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.

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.

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

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 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?

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

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.