View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010692 | MMW v4 | Properties/Auto-Tools | public | 2013-03-27 10:20 | 2013-04-07 14:38 |
| Reporter | Ludek | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | unable to reproduce |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0010692: MM 4.1 creates 8.3 filenames while tagging when running in VM on Max OS (regression in 4.1) | ||||
| Description | As reported by one user: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=70513#p363112 MM creates 8.3 during tagging when run in VM under Mac OSX See steps to reproduce or the forum link. | ||||
| Steps To Reproduce | 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. 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. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=70513#p363112 DTV-349172 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1630 | ||||
| parent of | 0012868 | closed | michal | MMW 5 | Ability to support long filepaths (> 260 chars) on Windows |
| related to | 0011799 | closed | Ludek | MMW v4 | Scanning: Full filename and path larger than 260 chars can result in MMW crash |
| child of | 0008020 | closed | michal | MMW v4 | f_video: MM is not importing/playing some MOV Files |
|
|
Seems to be caused in 0008020 by SVN revision 14866 by adding ExtractShortPathName() to MP3manage.pas Assigning to Michal (author of the SVN revision) |
|
|
Fixed in build 1630. |
|
|
Confirmed by the user: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=70513&sid=e7c33e17fb29db72adef9dbba4867eeb&start=15 |
