View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017774 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2021-04-20 14:08 | 2021-04-29 00:28 |
| Reporter | drakinite | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.1 | Fixed in Version | 5.0.1 | ||
| Summary | 0017774: Auto-Organize does not update linked album artwork | ||||
| Description | https://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. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2400 | ||||
|
|
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... |
|
|
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. |
|
|
Verified 2400 Unable to replicate. NOTE: Described workaround works also. |
