View Issue Details

IDProjectCategoryView StatusLast Update
0001502MMW v4DB/FileMonitorpublic2011-05-01 18:05
Reporterrusty Assigned To 
Status closedResolutionfixed 
Target Version4.0Fixed in Version4.0 
Summary0001502: File Monitor/Manual Rescans fail to detect tag property deletions
DescriptionIf 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
TagsNo tags attached.
Fixed in build1368


related to 0002606 feedbackpetr Track metadata disappears from view on playback 
has duplicate 0007271 closedjiri Add/Rescan Tracks doesn't update existing tracks in database always 
related to 0001412 feedbackjiri Changed capitalization not recognized in some cases and is inconsistent with MMA 
related to 0001327 closedLudek Properties are inferred erroneously on rescan of tracks already in the library 
related to 0002364 resolvedpetr 'My Computer' node infers properties even when 'infer properties' is completely disabled 
related to 0002165 closedpetr 'My Computer' node infers properties of tracks that are already in the DB 
related to 0006282 closedjiri iPhone/Touch: Unrated tracks do not sync back to MM 
related to 0005224 feedbackLudek Scanning .m3u files fails to update the DB properly 
related to 0008503 closedjiri 'My Computer' & Device nodes change properties on selection if tag doesn't match Library (regression) 
related to 0008508 closedrusty Rescan of tracks already in the DB triggers inferences 



2004-08-02 06:03

administrator   ~0004423

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)


2004-08-03 03:51

administrator   ~0004431

Last edited: 2009-05-05 21:10

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.


2009-04-24 17:39

administrator   ~0017579

Last edited: 2009-05-05 21:14

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).


2011-04-27 03:32

administrator   ~0024508

Last edited: 2011-04-27 03:36

Detailed description of the problem at:

Raised priority to 'urgent'.


2011-04-27 08:31

administrator   ~0024509

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.


2011-05-01 18:05

developer   ~0024688

Verified in 1368.