View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016683 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2020-06-02 18:47 | 2025-05-22 17:29 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 2024.2 | Fixed in Version | 2024.2 | ||
| Summary | 0016683: Artwork: no way of knowing when linked artwork is missing | ||||
| Description | If linked artwork is deleted from Windows Explorer: - Track Properties > Artwork continues to display (presumably cached) artwork. It should probably display it in the same manner as cached artwork normally displays i.e. as 'unsaved'. - Files to Edit > Missing artwork doesn't display the track with the missing artwork. The logic of that node should probably be revised to also display tracks with dead artwork links. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3156 | ||||
| related to | 0013741 | closed | jiri | Album Art: Handling Linked Album art |
| related to | 0013742 | feedback | Ludek | Album Art: inaccessible artwork should be superceded by available artwork |
| related to | 0016604 | new | rusty | Album Artwork: Improved handling of invalid and non-readable Album Art |
| related to | 0021575 | resolved | Ludek | Ability to mass edit artwork |
|
|
We do not have "Missing artwork" node. We have "Inconsistent artwork" (different artwork for tracks in the same album) and "Unknown artwork" (tracks without artwork). Maybe we should add "Inaccessible artworks" node for this, as this is different kind of problem and could be significantly time consuming to detect. OK? |
|
|
Michal confirmed that in such cases: - Artwork will stop displaying in MM if the user clears the thumb cache folder in temp - Artwork will not sync i.e. although the user may sometimes see the artwork, in other cases they won't, and in all cases there will be side effects of the artwork not syncing. With that in mind, based on discussion with Michal: 1) In cases where MM has 512x512px 'thumbnails' cached, then MM can automatically treat such artwork in the same manner as 'unsaved' artwork. 2) MM should just automatically delete links to artwork that doesn't exist. Then it can be (auto) looked up using whatever approach the user uses for other files. This can occur: a) Automatically during scan/rescan operations, to the files being scanned. b) Automatically when the user visits the 'unknown' artwork node. To minimize perceived performance impact, MM would - First display unknown artwork (as it does today) - Update the list with unlinked artwork (first 'fixing' tracks with changed images as 'unsaved' artwork so that they will appear with artwork in the node, and then displaying all of the tracks) c) Manually during Manage Database > 'optimize db' (or as a separate function 'Clean image cache') The above approaches would negate any need for changes to the nodes although it does raise the issue that it would be useful to have a means to quickly 'Save' all unsaved artwork (currently mass-edits combine art from all selected tracks). We'll want to create a second issue for this, but a possible approach would be to have a filter for 'Unsaved Artwork' (Artwork is [unsaved] | known | unknown) and a context menu in Edit tags > Save unsaved artwork. |
|
|
Fixed in build 3151. Now it checks existence of original artwork files during loading coverlists (like in properties dialog or during rescan) and added checking of this to Files to Edit -> Unknown Artwork. In case 512px or bigger version is cached, it is offered as "unsaved" artwork, the link to the lost artwork is removed. I did not add batch saving of unsaved artworks yet, it could sometimes save some unwanted artworks ("unsaved" are also lookuped suggestions, which are not always correct). Also artworks should be better saved on per album basis, so one shared artwork file can be saved for all tracks from the same album. I did not add it to Manage Database, as visiting Files to Edit -> Unknown Artwork does in fact the same. In case whole medium with artworks is not accessible, it is considered to be "not checkable" and should not be changed , we expect that such artworks exist. Please test, whether it is usable such way, for me it looks ok and worked quite quickly. |
|
|
Tested case 2a) and the artwork behavior is strange in the sense that the artwork status isn't updated and artwork gets looked up even when lookups are disabled: 0 Opened MM in Music > Albums > The Rythm of the Saints [Browser view with info panel enabled] 1 Deleted linked artwork from all tracks in an album 2 rescanned the folder containing the album 3 Opened the Properties > Arwork for a track on the album --> Linked artwork still displays (cached)! 4 Restart MM --> Artwork is automatically looked up (unsaved image)!! I'm not sure why as all lookups are disabled!! One other question: why did we say that this issue should only be fixed if Artwork > 512x512? The confusion occurs regardless of the size of the artwork?! |
|
|
rusty: it is done in a way, that cached thumbnails >= 512x512 are considered as usable to be original artwork, as big enough, so they are automatically offered as "unsaved" (so it is not searched again, it only finds this cached version and user can such lost artworks save again). Small thumbnails like 200x200 are not offered, so it is fixed only by removing link to already not existing artwork and it should not show any "unsaved" suggestion, if lookup is disabled. |
|
|
Improved in build 3154. There was bug causing, that in some situations artwork was downloaded from Internet even with all lookup options were set false. It should also better clean cached/notsaved versions. |
|
|
Reopening, we need some optimization, it seems, it can be quite slow during rescan, especially when used NAS: https://www.mediamonkey.com/forum/viewtopic.php?t=108005 We could reduce number of artwork file existence queries by temporary hashing result of the first test (assuming, the state of every artwork file is the same during whole rescan). |
|
|
Improved in build 3156. |
