MediaMonkey forum

Duplicate Year tags, and possibly others are not removed by Advanced Tag Management->Clean ID3 v1 and v2 tags.

e.g. See these screenshots from MP3Tag before and after clean & sync. (And Properties edit Date->blank->1960)



Edit: Just retested and checked that MP3Tag shows NO Extended Tags after just Clean step.

Perhaps this has to do with MediaMonkey's use of the TDRC frame? *Scratches Head*

Now that looks really promising. Off to do some testing.

Edit: Added section to MediaMonkey.ini The additional comment about Original Date looks a bit strange and inconsistent with the the section just added.

Initial tests show just a single "Year" in extended tags after sync tag.

Off to test whether this will fix symptom of some of the "permanent" unsynchronized tracks.

If this fixes the issues you're having, then I would suggest moving "TDAT" from disabled to enabled since it's a valid frame in ID3v2.3. The "TDAT" frame is for the saving of the Day and Month of release (in the format of DDMM), and is improperly suggested to be disabled in that help article in my opinion). The "TDRC" frame is the culprit for showing duplicate Year data in some programs (such as MP3Tag). Though, it is curious that in that first screenshot, you had years of "196" & "1960".

Yeah. I was wondering about that. I am fairly anal about release year but haven't worried much about release day to date. So..

Anyway,
Running Unsychronized Tags node as I type. Lots of date highlights with, on a quick spot check, the same truncated year.

Planning to clean and sync all tracks in the node with the exception of the non-numeric track numbers and then rerun the node.

later.

Looks like the problem is Songs.Year is incorrect in the database.
Still getting bad dates in Unsynch Tags.

Took a very close look at one track.
MP3Tag showing Year=196, MM showing 1960, Songs.Year="1960000" (Len=7)

Edited Properties to change Date to 1966. Songs.Year="19660000" (Len=8)

So, it looks like I can "fix" the symptom, but, MM may also need some clean up for malformed dates in the database.

FYI: The bad years can be found by browsing the Library->Years node. e.g. 190's

There is a real bug in MM. The year is displayed incorrectly in track panel and properties, plus the year compare is incorrect, e.g. "196" is compared to "1960"

Misery:
Removing the new section from MediaMonkey.
Want to leave MM closer to stock for future testing, and, it was not really part of the solution.

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

Posted by Jiri in mantis:

It's all as it should be:
1) There are two fields in ID3v2, 196 and 1960, MM prefers that 1960 in TDRC frame. There isn't anything incorrect about it.
2) It's in Unsynchronized Tracks because the value is 1960 in MM, but 196 in ID3v1 tag. So this is also correct.

Edit [Rusty]:
But that still doesn't explain the failed deletion

Edit2 [Rusty]:
Forget the first edit just a misunderstanding on my part.

Did one final test on a "bad" file restored from backups.

Add/Rescan of this track created "19600000" (Len=8) in the database. Whatever problem which caused the "1960000" in my database has since been fixed.

Ran Unsynchronized Tracks node. Restored file showed on track list.

Synchronized tags on the track.

Reran Unsynchronized tracks node. MM crashed. Bah.

That has got to be a red herring. Psigh. This system was acting strangley earlier today (WE restarted, Process Explorer won't run continuously). Off to reboot and rerun tests.

Did one final test on a "bad" file restored from backups.

Add/Rescan of this track created "19600000" (Len=8) in the database. Whatever problem which caused the "1960000" in my database has since been fixed.

Ran Unsynchronized Tracks node. Restored file showed on track list.

Synchronized tags on the track.

Reran Unsynchronized tracks node. MM crashed without Eureka Log, just the Windows alert. Bah.

That has got to be a red herring. Psigh. This system was acting strangley earlier today (WE restarted, Process Explorer won't run continuously). Off to reboot and rerun tests.

I probably contributed to the crash by aborting UT node as soon as the track in question appeared. And of course I don't have Debug View running. Double-Psigh.

Back to testing this.
This track no longer persists in Unsynchronized Tracks after Sync Track.
The problem I saw must be related to how an older version of MM handled Add/Rescan. That version caused "bad", ie. inconsistent with MM's current processing, values in the database. Manual Property edits to correct the database is the only available solution to that case.

So, no current bug, as Jiri stated. Just a very confusing journey along the way to that conclusion.