View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001502 | MMW v4 | DB/FileMonitor | public | 2004-07-23 12:32 | 2011-05-01 18:05 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0001502: File Monitor/Manual Rescans fail to detect tag property deletions | ||||
| Description | If the user edits a rating in Foobar by deleting the rating field entirely, and then rescans the track in MM, then the original rating field remains even though the user has deleted it and has tried to update the DB to reflect the change (via a rescan). | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=38522 http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=7390 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1368 | ||||
| related to | 0002606 | feedback | petr | MMW v4 | Track metadata disappears from view on playback |
| has duplicate | 0007271 | closed | jiri | MMW v4 | Add/Rescan Tracks doesn't update existing tracks in database always |
| related to | 0001412 | feedback | jiri | MMW 5 | Changed capitalization not recognized in some cases and is inconsistent with MMA |
| related to | 0001327 | closed | Ludek | MMW v4 | Properties are inferred erroneously on rescan of tracks already in the library |
| related to | 0002364 | resolved | petr | MMW v4 | 'My Computer' node infers properties even when 'infer properties' is completely disabled |
| related to | 0002165 | closed | petr | MMW v4 | 'My Computer' node infers properties of tracks that are already in the DB |
| related to | 0006282 | closed | jiri | MMW v4 | iPhone/Touch: Unrated tracks do not sync back to MM |
| related to | 0005224 | feedback | Ludek | MMW v4 | Scanning .m3u files fails to update the DB properly |
| related to | 0008503 | closed | jiri | MMW v4 | 'My Computer' & Device nodes change properties on selection if tag doesn't match Library (regression) |
| related to | 0008508 | closed | rusty | MMW v4 | Rescan of tracks already in the DB triggers inferences |
|
|
I think it's better to keep it this way. The current logic is that if a field isn't found anywhere in the tag, the value in DB is used. This prevents problem e.g. in case some tag type doesn't support some fields (e.g. rating) |
|
|
Good point. Other similar examples are if: o Metadata fails to save to a track's tag for one reason or another. o MM is configured to not save Track Metadata. In both of the above cases, this approach would result in scans deleting source metadata! On the other hand, users expect that in the case of fields such as 'Rating', which are saved to tags by MM, but not necessarily by other applications, if another app deletes the tag/field, why should MM add it back? (i.e. if the other application deleted it, and MM is set to rescan data from tags, then the user expects that the tag's data would be used). Similarly, in the case of fields such as 'Involved People' or 'Lyrics' where the tag isn't saved for all formats, users might expect that MM should only retain field data if MM doesn't support reading/saving the field to a tag for the format in question. |
|
|
Following discussion with Petr, we decided to defer. Two possible solutions to this were briefly discussed: 1) Dialog showing comparison of the two metadata sets (from the db vs from the file) gives user the choice of which metadata to keep. 2) MM automatically deletes the older set of metadata (i.e. compare last modified dates for the file vs that of MM metadata, and keep the most recent). |
|
|
Detailed description of the problem at: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=52836&sid=56b6ab0d6c8c05e6f5eb720664d69673&start=15 Raised priority to 'urgent'. |
|
|
Fixed in build 1368. The logic was changed, so that tag has priority over what's in DB. Note that in case some field isn't supported by given format, the value from DB is preserved. |
|
|
Verified in 1368. |
