View Issue Details

IDProjectCategoryView StatusLast Update
0017774MediaMonkey 5Tagging / organizing (properties / auto-tools)public2021-04-29 00:28
Reporterdrakinite Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0.1Fixed in Version5.0.1 
Summary0017774: Auto-Organize does not update linked album artwork
Descriptionhttps://www.mediamonkey.com/forum/viewtopic.php?f=30&p=480464
As user reported, when album artwork is linked to a file instead of embedded, and the track is moved via Auto-Organize, the linked album artwork is no longer found.
This is likely because album artwork is linked with a relative path instead of an absolute path.

Example steps to reproduce:
C:/Music/Foo - Bar.mp3
1. Link artwork to C:/Music/Baz.thm
2. Auto-organize -> move track to C:/Music/Foo/Foo - Bar.mp3
3. Restart MM
4. Open file properties, and hover over the album art path -> it is searching for C:/Music/Foo/Baz.thm and cannot find it.
TagsNo tags attached.
Fixed in build2400

Activities

Ludek

2021-04-20 16:25

developer   ~0062888

Last edited: 2021-04-20 17:06

View 6 revisions

For me the "Accompanying files" dialog is shown and the artwork files are moved (once I click [Move]): https://www.dropbox.com/s/ghcxb6lzuj2eisd/screenshot%202021-04-20%2018.15.38.png?dl=0
But the dialog is shown only when all audio files from that folder are moved, which probably wasn't your case?
Testing further various scenarios...

EDIT: ok, the issue is that the files are moved, but the links are not updated. i.e. like the original user report here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&p=480464

EDIT2: Seems to be caused by the fact that in MM5.DB the artwork path is stored absolutely (DB table: Covers, DB column: CoverPath), but in MM4 it used to be stored relatively (e.g. only 'folder.jpg'), to be found why this was changed...

Ludek

2021-04-20 17:21

developer   ~0062889

Last edited: 2021-04-20 17:44

View 4 revisions

The issue is that the paths are stored absolutelly after scan, but after editing a property the path is converted to relative as expected.
The absolute path creation during scan is a regression introduced in SVN revision 28067 by fixing 0014011 (4 years ago)

Fixed in 5.0.1.2400

The paths (Covers.coverPath) are stored relatively again after adding the file into library (like in MM4) and thus resolves also the original issue.
Workaround is editing a track property to make the paths stored relatively.

peke

2021-04-29 00:28

developer   ~0062972

Verified 2400

Unable to replicate.

NOTE: Described workaround works also.