DB / Tag Mismatches in majority of library [#19480][#19483]

[tbm72]

Looks like the latest update (5.0.4.2675) is supposed to fix a bug with the DB/Tag Mismatches function (https://www.ventismedia.com/mantis/view.php?id=19483) but it's still throwing up lots of mismatches that I can never fix. It's always done this for me but I've never really worried about it as it doesn't seem to affect anything.

When I run the DB/Tag Mismatch function it always throws up the same tracks and it only ever shows the Extended Tracks column with errors despite it appearing empty:



If I run the [update tags] function it never does anything. As I say, not a problem for me but doesn't seem fixed.

[Peke]

Hi,
Thx, reopened.

Please supply full debug log using 2675 so that we can analyze.

[IanRTaylorUK]

Hi Andre,

Yes I agree that there is still something odd.

For example, I have on music mp3 that appears to have no extended tags, but when I sort by extended tags, it appears at the top of the list above those with visible tags!

Tried some WiFi synching and that does not seem to interfere / add extended tags.

Will keep investigating!

[Peke]

Hi,
Can you please supply few of those files in Support ticket so that we can analyze it further. This is strange issues and should be handled ASAP (if possible before 5.0.4. release).

[Ludek]

I think I replicated it.

This happens for tracks that were imported from MM4 database (MM.DB), but were not re-scanned into database thus inludes ExtendedTags = null in MM5.DB (while it has extended tags in the file tag).

Anyhow sharing a sample file(s) and MM5.DB would be helpful to ensure that the cause is same as in my test cases.

[IanRTaylorUK]

Hi Peke,

I managed to clear ALL my "Extended Tag" issues over the weekend and so turned my attention to Auto-Tagging!

During "Auto-Tagging" I found that some files showed "Failed" in the status column. So, what I did was use right click properties and added a comment to the Custom 1 field. The comment was "Failed During Autotag". I then created a new Collection for "Failed During Autotag" with just two criteria 1). Custom 1 contains "Failed During Autotag" and 2). Lyrics is unknown. I reckon I added custom field comments to ~40 files today.

OK, so just to make sure I am not getting things out of order, I just stopped playing music, shutdown MMW5, checked no processes hanging around in task manager and re-opened MMW5. In my case, this causes a complete re-scan of my Music / Audiobooks / Podcasts and Downloads folder.

Some interesting things to note when I select the "music" node / files to edit / DB Tag Mismatches:
1). 17 files have "returned" all with a timestamp of "today" (after all 2618 folders processed).
2). 16 of the files have the "Failed During Auto tag" entry in Custom 1
3). The "Extended Tags" field / column is highlighted BUT when I individually select files. No other column / field highlighted.
4). Appears to be nothing in the extended tags
5). One file (the last one in the list sorted by Album) is shown twice ***
6). If I right click / find more of the same / Folder (explorer), this last file has some empty columns in the display e.g. #, title, contributing artist, album - even after pressing F5 in Explorer. ***

*** - This last file is one of seven in my library that I have noted as "ID3 v.23 Error - MP3 header parse error". It might be an idea for me to just delete these from the library?

Whilst I run the debug version of MMW5, I was not running DeBug View.

My feeling is that something is not quite right when you "write" to some tags. I will start to put some stuff in the One Drive folder I created for Ludek recently!

[IanRTaylorUK]

I think I replicated it.

This happens for tracks that were imported from MM4 database (MM.DB), but were not re-scanned into database thus inludes ExtendedTags = null in MM5.DB (while it has extended tags in the file tag).

Anyhow sharing a sample file(s) and MM5.DB would be helpful to ensure that the cause is same as in my test cases.

Hi Ludek,

Yes, my tracks were ALL imported from a MMW4 database BUT I rescan everytime I start MMW5 as ALL my media folders are set to be scanned "At Startup" except my downloads folder ("At Startup" PLUS "Continuously") and Playlists ("Manual").

I like the downloads folder to show new files promptly as I typically "unpack" album ZIPs to this folder. I then work on the album e.g. Analyse Volume, manually tag, add BPM using Foobar and check artwork etc. I then finish off by using Auto-Organise and create a new Playlist for the album. Typically done once a week / fortnight. After I have done a batch, I will then sync my Android devices i.e. All Playlists.

Maybe once a month, I will export all Playlists (extended M3U format) so I can copy the work to another computer and have MMW import these new playlists.

[Andre_H]

I think I replicated it.

This happens for tracks that were imported from MM4 database (MM.DB), but were not re-scanned into database thus inludes ExtendedTags = null in MM5.DB (while it has extended tags in the file tag).

I don't like being the bearer of bad news, but that can't be the (only) reason:

- i'm pretty sure i never used MM4. i used iTunes until i switched over to MM5 in Januar 2021, one of the earliest releases, but MM5.
- i rescan my library quite regularly, because of: https://www.mediamonkey.com/forum/viewt ... 07#p499907, Part 3.
- i have affected tracks that has been added barely 2 weeks ago.
=> it's not (only) about old and not rescanned tracks.

- i don't see ANY extended tag in MP3Tag on the affected tracks. i use all custom fields, but non extended tags (or neither MM5 or MP3Tag doesn't show them. Any other way to verify this?)

- i had those missmatch view clean sometimes ago (https://www.mediamonkey.com/forum/viewt ... 64#p482964), i checked this a few times then, and a few tracks within my 226 hits are (date added) by far older than the post. they were "clean" someday, and went to missmatch again.

My feeling is that something is not quite right when you "write" to some tags. I will start to put some stuff in the One Drive folder I created for Ludek recently!

Without being able to prove it: I believe that too. ALL my tracks under "missmatch" have a timestamp between Okt. 2021 and Okt. 2022, which seems to be consistent with the tracks being clean in the past (link above, Jan 2021) and now re-appearing in "missmatch" through changes/saves.

Final remark: Please don't take this as a rant, the finds under "missmatch" can be played without any problems, I don't see any impairments in MM5. I just wanted to add some additional info.

If you/support want a copy of my database and a few sample tracks, leave me a note.


Edit/Add: as we speak, last scan (21.Okt.2022) brought up 226 tracks, scan today shows 229 tracks.

Andre.

[IanRTaylorUK]

Edit/Add: as we speak, last scan (21.Okt.2022) brought up 226 tracks, scan today shows 229 tracks.

Andre.

Hi Andre, yes I agree that this issue - whilst a little annoying at the moment - does not stop us from playing and synching etc.

In your 229 tracks, are there any duplicate "lines"?

If you were to delete the 229 tracks and rescan (perhaps after taking a backup of the MM5.DB) what happens?

I will PM you the link to my One Drive folder related to this. I think we are seeing a "Database" issue and not a "MP3 File" issue

[Andre_H]

In your 229 tracks, are there any duplicate "lines"?
If you were to delete the 229 tracks and rescan (perhaps after taking a backup of the MM5.DB) what happens?

Haven't found any duplicates.
I will try the delete & rescan idea, but I won't be able to do that until later today. I first have to back up the database and all tracks.

I think we are seeing a "Database" issue and not a "MP3 File" issue

I could test a SQL statement that deletes all ET for my music, because i don't use them intenionally.
Would "UPDATE SONGS SET ExtendedTags = '' WHERE [TrackType]=0" in the SQL Addon do this?

[Andre_H]

So, i tested something ...

- closed MM5, backuped database, config files, media files.
- restart MM5, closed all open tabs, went ot "music node", opened "missmatch view": 229 hits. 2 of the tracks are pretty new added, 1 really old.

- started a file rescan: 3 files added.
- closed MM5.

- restart MM5, on "music node", opened "missmatch view": 226 hits. the deleted ones were not in list.
- checked media files: no changes made.

- recovered database from backup.
- restart MM5, on "music node", opened "missmatch view": 229 hits, including "the 3 ones".

- searched the [songs].[ID] for "the 3 ones"
- checked "SELECT ID, AlbumArtist, SongTitle, SongTitle, ExtendedTags FROM [Songs] WHERE [ID]=???" for "the 3 ones": they all show "[]" as content for "ExtendedTags"
- checked 10 random tracks. no content in "ExtendedTags" there.
- executed "UPDATE SONGS SET ExtendedTags = '' WHERE [ID]=???" for "the 3 ones"
- executed "SELECT ID, AlbumArtist, SongTitle, SongTitle, ExtendedTags FROM [Songs] WHERE [ID]=???" for "the 3 ones": no contents (shown).
- closed MM5.

- restart MM5, on "music node", opened "missmatch view": 226 hits. "the 3 ones" were not longer in list.
- checked media files: no changes made.

I see a "database thing". 2 of the 3 deleted and updates tracks are added in 2022, they definitly never seen a MM4-database or database-upgrade or something like that. i have no idea where those "[]" came from, but the must have been added by MM5.

[Andre_H]

... but if i look at "SELECT ID, AlbumArtist, SongTitle, SongTitle, ExtendedTags FROM [Songs] WHERE [ExtendedTags]='[]'", i get 270 hits, and different tracks than that from the "missmatches view".

Until there's any syntax error I stumbled in, from this point on I'm out here because it's now beyond my understanding and imagination ...

[Andre_H]

i did something ...

- closed MM5, backuped database.

- build a list for all songs with extended tags. (all extended tags had '[]' as content)
- executed "UPDATE SONGS SET ExtendedTags = '' WHERE [ID]=???" for all those IDs.
- closed MM5

- started MM5
- did a full database rebuild
- startet the "missmatch" search: they are completely gone.

i will tracks those now and then.

[MiPi]

Andre_H: problem was in saving empty extended tags, it is fixed in upcoming build.