View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001666 | MMW v4 | Properties/Auto-Tools | public | 2004-12-14 05:10 | 2008-12-01 22:15 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0001666: Album Art & Auto-Organize: Linked Images are lost | ||||
| Description | If the user has Album Art images linked to tracks, and then Auto-Organizes the tracks, then: a) The links to the images aren't updated and the images are lost b) If the images were in the directory with the tracks, they're not moved Idea: perhaps the easiest way of rectifying this would be to automatically/always move linked images to the track directory as suggested in item (5) at /UI Mockups/Album_art.pdf on the ftp server (also a requirement for 0001633). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1130 | ||||
|
|
This can't be ever completely fixed, the idea behind linking of images somehow expects users to behave 'correctly' and don't make dead links. However, I was thinking about a way how to simplify user managing linked images (and actually any non-media files). My idea was as follows: When user does any auto-organization, check whether all tracks from a folder were moved. In case all were moved and there remained some non-audio content (.jpg, .txt, ...) move it to the same folder as tracks were moved. This helps not only for linked images but is kind of general solution of already requested 'buddy files'. In addition, after such actions empty folders could be removed. Both these suggested features would be configurable from Options dialog. |
|
|
I don't think we can rely on 'good behaviour' from the user (especially since many users would not consider the behaviour in question to be 'bad'). If we combine your suggestion with 0001633, then the problem will be completely fixed. i.e. if MM automatically moves linked covers to the directory containing the tracks (on any tagging operation or file operation), and renames the artwork to '<Artist> - <Album>x.jpg', then whenever tracks are auto-organized, all you'd have to do is check for a cover by the name of <Artist> - <Album>x in the same directory and move it as you suggested, or copy it if some tracks from the <Album> remain. In the absence of a fix to 0001633, another alternative would be to have 'hard' links rather than relative links so that the links wouldn't disappear. |
|
|
As for requiring 'good behaviour', we really have to require it partially, e.g. if user moves/renames a cover outside of MM, the link will be damaged. As for your suggested solution, I think that it wouldn't work for many users because there is too many usecases, for example: - User wants to store covers in several file using own naming conventions, e.g. 'Covers\Front.jpg', etc. - User has an album in a folder, all tracks link to one jpg file. Then user moves only half of the tracks elsewhere. I think that in this case MM doesn't have any clean way of managing the links. So I still think that my previous comment is right as it would work for the most important cases well and would also manage other types of files (e.g. album lyrics stored in an external .txt file). |
|
|
Note: related issue to this bug: clean DB and rescan --> many linked images are lost (whenever the images are saved to a directory other than that containing the file). In my opinion, this goes against much of MMs UI experience philosophy, which is that metadata should be preserved even in the event that the db is lost. I'm working on a suggested implementation. Coming soon. |
|
|
As discussed, we'll take the approach you proposed for now, although it would be good if it could be made to work for all cases of linked album art. I was thinking that this could be done as follows: -For any track that is being auto-organized, copy the images linked with it to the new folder to which it has been copied (regardless of whether all tracks in the original directory were copied). If the same album art exists in two directories, it doesn't really matter--that's better than having album art go missing. -If all tracks in the directory are copied, then proceed as you'd originally described. |
|
|
As indicated via e-mail this has been fixed: -Accompanying files are automatically moved -Empty directories are automatically deleted |
|
|
Auto-delete of directories and automove of accompanying files is working fine, so far (though I still want to test it further), however I have a couple of suggestions: 1) Given the way the functionality has been implemented (with user control over which accompanying files should be moved), I would suggest that it would make sense for the 'Move accompanying files' functionality to appear even in _any_ case where the user moves all files in an Album (even if all files in the directory have not been moved). The only difference in this scenario would be that no accompanying files should be selected by default. Not a huge issue, but if it's simple to add... 2) The wording can be changed to: The following accompanying files were found. Please select those which you would like to move. |
|
|
Fixed in build 725: - Files are properly sorted in the dialog 1) I tried to design it so that it doesn't annoy user much, i.e. the dialog is shown only when there is reasonably high change that user really wants to move some non-media files as well. Your proposal might be useful in some cases, but I'm afraid that it could rather become quite annoying, particularly when tracks aren't properly tagged and it isn't clear what is full album. 2) Fixed. |
|
|
Verified 825 |
|
|
Tested 1129 and this is failing for many folder.jpg files--whenever they are system files (which is how WMP seems to label them). |
|
|
Yes, this didn't work for hidden and system files. Fixed in build 1130. |
|
|
As discussed with Ludek over IM, this should be consistent with automatic empty folders removal. So the algorithm was slightly modified to: - Show all (including hidden) files as being Accompanying files, but exclude hidden Thumbs.db or Desktop.ini files. |
|
|
Fixed in build 1130. |
