View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003773 | MMW v4 | Properties/Auto-Tools | public | 2007-10-16 22:08 | 2007-10-29 20:01 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0003773: Linking/Unlinking/Removing of Album Artwork is Buggy | ||||
| Description | When testing adding/removing artwork that is linked, it seems that MM has a number of significant bugs: 1) When performing link/unlink operations on an album MM often fails on some of the tracks. This problem occurs most frequently when an album is split between multiple directories, but is also quite common even within a single directory: a) D&D Image to the AA Window with a single track selected (linked to folder.jpg) and apply to all tracks on an album b) Remove Image via AA Window applying to all tracks on an album c) Remove Image via Properties > AA Tab and applying to all tracks on an album d) Using Auto-tag from Amazon and saving to folder.jpg (occurs less frequently) 2) Image file isn't removed if the artwork is deleted from all tracks (this may be because MM somehow 'knows' that the artwork hasn't actually been deleted from all tracks even though it was supposed to have been). 3) Multiple Album Art images appear in the Properties panel for links to a single image (MM prompts 'are you sure you want to overwrite folder.jpg, but when it does so, it doesn't also overwrite the previous link). NOTE: These tests were all performed with OGG files (not sure if it's related to 2744 or not--need to test with MP3s as well). | ||||
| Steps To Reproduce | Video illustrating this is posted to ftp | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1097 | ||||
|
|
Note: tested with: -OGG files in a single directory -MP3 files in a single directory In both cases, 1c and 1d were observed, though less commonly than when the directory is split. Note also that the bug didn't seem to occur when saving to a tag. |
|
|
Assigning to Ludek for a review, suggestions and fixes. |
|
|
2, 3, 1d fixed in build 1092. Tested with MP3 files (album splitted to 3 directories). I am going to further test with OGG files. |
|
|
Tested with OGG and fixed also the remaining issues of 1). Fixed in build 1092. |
|
|
Tested 1094: 1 a, b, c are all consistently reproducible (tested on an Album with OGG tracks in a single folder). Basically any operation in which the user checks 'Apply to all tracks on the album' doesn't work correctly--the operation is applied to only some of the tracks on the album. (note: in contrast when the user performs operations on multiple tracks via Properties > Album Art > Apply to all selected tracks, everything works as expected). 3) This still isn't fixed. To explain better: -Select a Track from an Album -Add album art (folder.jpg) for the selected track -Add album art (folder.jpg) for the selected track again -->Two links to the same Album art are associated with the track! What should happen is that if the user tries to link to an image that is already linked, no additional link is created (since folder.jpg is already linked!). 4) I believe this is a regression: -Select 5 tracks on an album -Click Properties > Album Art -Click Add, select folder.jpg from the directory -->Apply to all selected tracks is Automatically checked off -Click OK to commit the change -->AV (2 Eurekalogs were sent for this) |
|
|
Tested with OGGs and yes, there still were some issues / need for a dups prevention. i.e. Items 3 and 4 fixed in build 1095. Re: item 1a, 1b, 1c This seems to be reproducable very occassionaly and in addition the fact is that all is written correctly, but not updated correctly. i.e. hitting F5 solves this issues. |
|
|
Verified 3 and 4. Re. item 1, the problem sometimes occurs sporadically, but other times occurs very frequently, and although the problem can be corrected by a refresh, users won't realize this. Moreover, if they don't try to refresh, but instead go to Properties > Album Art, the _incorrect_ art is shown!! (i.e. even though it may be a cache/refresh issue, the issue affects various portions of the UI so it's almost impossible for the user to know that the problem isn't real). |
|
|
Re: 1a,1b,1c Fortunatelly after some investigating I've found exact steps to reproduce this issues: i) Select a song from the tracklist and go to Properties -> Album Art ii) Leave props dialog iii) Select another track in the tracklist, but from the same album iiii) perform 1a or 1b or 1c -> for the song previously edited in props. the AA is not updated. So now I know exact steps to reproduce it is relatively easy to fix. Fixed in build 1096. |
|
|
1a)b)c) are still occuring with a fair amount of regularity. To be clear on the repro steps for a/b, they are much more generic than the steps you described: -Go to Artist > Album > in the tree, and select one (OGG) track from the album -Add/Remove Album art to the one track by clicking Add Image / Remove Image in the Album Art window (to add, select folder.jpg and enable _only_ 'save image to Album Folder' and 'apply to all tracks on the album) -->Art is added/removed from only some of the tracks on the album (refresh 'fixes' the problem) IMPORTANT: in build 1096 'Remove' operations appear to fail far more often than Add operations. |
|
|
Ok, I'm sorry, I forgot to fix 1b. But I am sure that 1a, 1c are fixed in build 1096. i.e. 1b fixed in build 1097. |
|
|
Verified 1097. |
