MediaMonkey forum

Build 1249

The Files to Edit/Unsynchronized Tags node is not populated correctly.

Steps to replicate:
1- Using Windows Explorer, set a track/file Read-Only
2- In MediaMonkey, go to Files to Edit/Unsynchronized Tags and verify that the track is not unsynchronized
3- Right click track, Properties, Details tab, change "Involved people" property
4- Dialog box with title "Error" pops up (side note - strange/wrong title) stating
File <...> is read-only. Do you want to change it?
Answer No.

At this point, MediaMonkey has one value for the "Involved people" property in the database/library and a different value is stored in the track/file. Thus, the track is now "unsynchronized".
5- Go to Files to Edit/Unsynchronized Tags

Expected behavior: track is displayed in Files to Edit/Unsynchronized Tags
Observed behavior: track is not displayed in Files to Edit/Unsynchronized tags

Thus, one is lead to believe that all information that MediaMonkey displays is in the tags, yet it is not. If the library is wiped out at this point and re-scan the tracks, information have been lost - the new value of "Involved people" is now lost.

This was observed using both FLAC and WMA Lossless files.
This was observed with several of the properties on the Details tab, e.g. Involved people, Encoder.

Fourteen,

Thanks. Tracked at http://www.ventismedia.com/mantis/view.php?id=5727

note: this is a bug for FLAC but not for WMA (wma doesn't store the involved people field to the tag).

-Rusty

fourteen wrote:This was observed with several of the properties on the Details tab, e.g. Involved people, Encoder.

rusty wrote:note: this is a bug for FLAC but not for WMA (wma doesn't store the involved people field to the tag).

I observed this behavior with a WMA Lossless file and the Encoder property. According to MediaMonkey's help file, MediaMonkey stores Encoder in a WMA file.

Sorry I meant that the specified case of Involved People/WMA isn't a bug.

In fact, as you'll see in the bug, the usnynchronized tags node is limited to ID3v1 fields at the moment That's high on the list to fix post 3.1.

-Rusty

rusty wrote:Sorry I meant that the specified case of Involved People/WMA isn't a bug.

OK. I just wanted to point out that your description of the bug at http://www.ventismedia.com/mantis/view.php?id=5727, "If the Involved People field is doesn't match the involved People Tag for a FLAC track, MM doesn't indicate the track as 'unsynchronized'.", is too specific - the behavior is the same with other fields and with other file types, please don't overlook that when addressing the bug.

rusty wrote:In fact, as you'll see in the bug, the usnynchronized tags node is limited to ID3v1 fields at the moment That's high on the list to fix post 3.1.

I didn't know that. Is that documented in the Help somewhere? It would be VERY helpful, and important, to document what is, and what is not, reported under that node.

Are you saying that only "Files to Edit/Unsynchronized Tags" only looks at: Song Title, Artist, Album, Year, Comment and Genre? (This list of fields is from http://www.id3.org/ID3v1.) I do see that the Help file states that differences caused by id3v1 length constraints are ignored, so at least that part is clear.

Looking at MediaMonkey's Help says in the section "Synchronizing Your Tags", it says:
"If MediaMonkey is set to write ID3v2 Tags: Only Tracks whose ID3v2 properties don't match the Library are shown".

Given your statement above that "usnynchronized tags node is limited to ID3v1 fields", does this mean that MediaMonkey still only looks at the six id3v1 fields and not all id3v2 properties (assuming MM is set to write id3v2 tags)?

Given your statement above that "usnynchronized tags node is limited to ID3v1 fields", does this mean that MediaMonkey still only looks at the six id3v1 fields and not all id3v2 properties (assuming MM is set to write id3v2 tags)?

Yes. I'll correct the online help.

-Rusty