Erase comment field text, then it reappears [#1502]

[nohitter151]

doesn't matter whether your configuration is ID3V1 and V2 tags or either one.

If that was the case if I set & read V2 why does it display v1 information <----major bug. Or vice versa set & read V1, why display V2 information.... My setup was to read both version it still occurs

I advise you to contact the MM support team if you can reproduce it consistently. They will probably want you to send them a file that they can test on.

My guess is that the tags are corrupt so MM has a hard time to remove them. Maybe you should try Tools > Advanced tag management > Clean ID3v1 & ID3v2 tags

[Mizery_Made]

doesn't matter whether your configuration is ID3V1 and V2 tags or either one.

If that was the case if I set & read V2 why does it display v1 information <----major bug. Or vice versa set & read V1, why display V2 information.... My setup was to read both version it still occurs

You don't configure in MM which tag version is read, the setting in the options regarding the tag versions only affects what is written by MM. Most programs use an "all or nothing" approach to tag versions. If you set it to use/read v2, then it completely ignores v1tags even if no v2 tags exist in the file (others will fall back to the v1 tags if there's no v2 present, but if one tag exists in v2 then it uses that ignoring whatever is in v1 tags). MM however chooses to read from both with v2 trumping v1.

Therefor, if you have "Title 1" set in the v1 tag for the file, then have it as "Title 2" in the v2 tag, MM will display "Title 2" for the file. Now if you have "Artist 1" in the v1 tag, but have that field blank in the v2 tags, MM will pull "Artist 1" from the v1 tags as opposed to sticking strictly to the v2 tag (and therefor showing no artist). Why this route was chosen, not sure. Maybe it's viewed as some sort of data loss protection, or just an attempt of showing "complete" tags. I think this (and the fact MM respects data in the Database when it's been removed from the tags) as being the culprit for most of the reports such as these.

If you're certain that only one tag version is present in the file (such as making sure the v1 information is deleted if you have MM set to only write v2) or have it set to write both tag versions and this is occurring, perhaps as nohitter suggests, the files tags are corrupted somehow.

[Guest]

The problem always occurs in the Comment field and no where else. Does not occur in any other field that you mentioned.

I have no use for the Library functionality (I think the Library thing sucks). Thanks for the tip on cleaning both Tags, I will give that a try. Instruction say after a cleaning you should perform a synchronize of tags (probably the library...will get out of sync my guess). I'm reading to understand just what a "cleaning" does?

[richjoh]

Cleaning your files wipes out your tag information... not a good idea, since I'm looking to fill in tag information. Who wants to wipe out there entire collections....

If I delete the comment field the comment field information should not reappear if I press F5 or reopen MM. That is the problem.

[nohitter151]

Cleaning your files wipes out your tag information... not a good idea, since I'm looking to fill in tag information. Who wants to wipe out there entire collections....

If I delete the comment field the comment field information should not reappear if I press F5 or reopen MM. That is the problem.

The info will still show in the MM grid view after you clear the tags (as long as you don't refresh). You can immediately Synchronize tags and then it should all be updated.

[richjoh]

I have a batch of files right now (I download music every week). I delete the comment field on the batch, watch for it to complete from the progress bar, then hit F5 to refresh, all the deleted commment fields reappear, WOW the contents of the Comment field should be null, nothing nadda. I can repeat this over and over. V1 & V2 tags are enabled.

Any one else SEE THIS???

CORRECTION! MY BAD - i only had V1tag enabled. I changed to V2 or v1&v2 problem does not persist, BUT does still occur on occasion.

[nohitter151]

I

CORRECTION! MY BAD - i only had V1tag enabled. I changed to V2 or v1&v2 problem does not persist, BUT does still occur on occasion.

Again, if you can consistently reproduce the problem with a certain file, send it to MM support. I'm sure they would be interested to see it.

[ChrisJenkins]

I've been experiencing exactly the same issue but not limited to the Comment field. It seems to affect many of the 'text' tags such as Grouping, Custom1-Custom5 as well as Comment. It may affect other tags too but I haven't investigated it. Here is what is happening in my case; I think this is a bug.

In my home setup I have a common set of audio files (about 7500 or so). Each person (4 in my household) has their own separate MediaMonkey library (database) which contains details of all the audio files. The library contents are maintained using File Monitor with startup scan so that any changes person A makes to any file tags will be picked up by person B, C and D's libraries next time they start up MM.

This seems to work fine, except for the 'problem tags'. It seems that for these tags (identified above, plus maybe others) it is not valid to write the tag to the file when it's data payload is empty (e.g. an empty string). So, if you clear one of these fields in MM and then update the tags, the tag is actually deleted from the file on disk and the value removed from your library. This is fine provided that (a) only you are ever modifying the tags and (b) you only modify them through MediaMonkey. If either of these conditions is not true then you have problems.

Consider the following scenario (which I have tested very thoroughly, verifying file contents using MP3Tag at each step of the way):

There is a file on disk, MyMusicFile.m4a, where the 'Comment' tag has the value 'ABCD'.

Two people have this in their (separate) MediaMonkey libraries and in both libraries the Comment filed is, correctly, 'ABCD'.

Person A uses MM to clear the comment field (i.e. set it to an empty string). The comment value is cleared from the entry in their library and the Comment tag is *deleted* from the file on disk. The file on disk now does not have a comment tag at all. Person A now exits from MediaMonkey.

Person B starts up MM and the startup scan does its thing. It sees that the file MyMusicFile.m4a has changed and reads the tags. However, since the file does not contain a 'Comment' tag it leaves the current comment value, 'ABCD', set in the library. In my view this is a bug; it should remove the COmment value from the library. So now Person B's MM library is inconsistent with the file tags. But things get even worse. If Person B now modifies some other tag for this file (maybe track number, anything will do) then when MM writes the tags back to disk it includes the Comment tag with the value 'ABCD' (because it is still [erroneously] present in Person B's library). So, even though that tag had previously been deleted from the file suddenly it has 're-appeared'.

This behaviour has been causing me serious grief for many weeks now and I have only just figured out what is going on. Luckily there is a workaround; instead of clearing the Comment tag (or any of the other tags that show the same problem) set the value to a single space instead. This ensures the tag remains in the file and snsures that File Monitor will pick up and apply the changed tag value.

Now, it may be that this behaviour is 'by design' but to me it seems like not the desired behaviour. In my view it is a bug and should be fixed. I'd be interested to hear what others think.

[Mizery_Made]

Actually, that is 'by design' and the developers have stated it's a kind of protection against (accidental) tag loss as well as because not all tag formats support the same information. Therefor if a tag type doesn't support custom tags for instance, than each time those files would be scanned in, your custom tags would be deleted from the database. That said, it's been reported as a bug a few times over the years, and I myself believe it is one. Though I can understand the reasons against that thinking as well.

EDIT: Relevant bug entry: 1502: File Monitor/Manual Rescans fail to detect tag property deletions

[richjoh]

Unbelievable this is intentional... I was also putting a space in the comment field as a temporary work around long before I post this. Surprise, I've seen the comment field reappear when the old text is replaced with a space (happens more often when you do a bunch of files at once. Easily replicated by deleting the comment field on a file then hit F5 to refresh and magic the dumb text (you thought was erase) reappear from the Library like you mentioned (I have sample file per request).

I always must remove comment field since my files are loaded with website, contact info, some third party garbage that has no connection with the song.

This is a stupid and dumb idea. This should not work this way. Put a configuration box it for us users to check... something, anything. I need the comment field empty on all my new songs. My DJ software writes information in the comment field, I don't need http://Www.ADumbWebsiteDotCom in the comment field.

If someone comes across a Good Tag editor please let us know here. I'll be the first to drop MM if the Tagger can write what I type in my tags and permanently leave it there.

[ChrisJenkins]

Actually, that is 'by design' and the developers have stated it's a kind of protection against (accidental) tag loss as well as because not all tag formats support the same information. Therefor if a tag type doesn't support custom tags for instance, than each time those files would be scanned in, your custom tags would be deleted from the database. That said, it's been reported as a bug a few times over the years, and I myself believe it is one. Though I can understand the reasons against that thinking as well.

EDIT: Relevant bug entry: 1502: File Monitor/Manual Rescans fail to detect tag property deletions

Thanks for this info. I looked at the bug (and the related duplicate bug). I don't really agree with the rationale for having it the way it is; to me it just seems broken. Anyway, this is a really big problem for me so I have logged a support ticket referencing my earlier long winded post and the two bugs. I have asked for a simple option to make the behaviour the more logical option of always updateing the library metadata from the tags when a file is read, including deleting any removed tags from the library. I can't see that would be hard to implement nor that it would be a problem since it is something you would need to explicitly select. That way the current (less than useful) behaviour could remain the default.

Not sure if I will get any traction with this but fingers crossed.

[richjoh]

Would someone check if this is fix for them. Go into your Options, under Tags & Playlist submenu and place a check in the box "Update tags when editing properties". It appears I have NOT had the erased comment field magically reappear whenever I do an F5.

Let me know if this is also the case for you. If so then this is a work around for this issue.

[ChrisJenkins]

I have had that option set since day one (a few years ago). It is not a fix for my issue.

With this options set, MM will work 'correctly' for the limited case where there is one MM user, with one MM library working aginst one set of media files and where that user only ever edits tags using MM and not any other external tag editor. In all other permutations MM is still broken (by design).

As soon as you have any one or both of the following situations:

1. Multiple different MM libraries (e.g. multiple users perhaps) sharing a common set of media files

2. You make changes to tags external to MM usign some other tag editor.

then you are potentially hosed.

Support confirms this is 'by design' and won't acknowledge it as a defect (in my opinion it is a defect; but a design defect not an implementatopon defect). They told me to raise an enhancement request. Not sure how to do that (I will ask support what the process is). Unfortunately, it appears that many MM folk are in some kind of denial on this issue. Most disappointing and unstaisfactory.

[Peke]

I do not think that, personally I think that this is the case where Two feature are in Conflict negating each other and we needed to make approach that will be the best.

There is no way to keep two sets of Tags in same file if file is used with different users. On my home PC LAN, my PC is set to update tags in files but all other PC on LAN only keep updates within Library. That is for me the best approach as I have control of music and others are capable to add their own notes to tags using same files.

[richjoh]

Jiri wrote" "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)""

I thought if a value is remove from the field its written to the database . When did Jiri make up his own rules on information technology. His reasoning is the problem. How would we store correct information if database always wins?
I want to move away from MM, its this it ain't broke mentality driving MM innovation ;().