1228 Add/Rescan failing to see tag deletions [Bug #1502]

[chrisjj]

If in Mp3tag I change trackfile tags of MM library WMA tracks, and then Add/Rescan tracks and playlists in MM, MM library fails to pick up the tag changes. If I first delete the tracks from the library, it succeeds.

IIRC this bug has been present for a long time.

Is there a plan to fix it?

EDIT: Sorry, I find this bug is specific to removal/emptying of tags i.e. does not strike edits (unless they result in an empty tag). EDIT: Subject adjusted accordingly.

Hence this is indeed a bug that was first reported over a year ago. Devs, is there some particular problem in fixing it???

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

[REIKA]

MP3Tag : 'Preserve file modification time when saving tags'
MediaMonkey : 'Only for files with changed timestamp or size'

I can reproduce it only when I check 2 of the above.

[chrisjj]

> I can reproduce it only when I check 2 of the above.

... or empty the tag? See my edit to the original report above.

[Mizery_Made]

Is the problem here that you're deleting (thus completely blanking) a field? So if the title was once "Test" and you change it to "" or delete it in MP3Tag, MM keeps the old "Test" data? I read the thread right quick and wasn't exactly sure if this was the problem or not. Though if it is, when I reported it way back in 2.5, the suggestion by some members was that it was a kind of "Data Loss Fail Safe" or something. If the information is deleted in the file, it uses the information from the database.

[chrisjj]

> if the title was once "Test" and you change it to "" or delete it in MP3Tag, MM keeps the old "Test" data?

Yup, that's it.

> the suggestion by some members was that it was a kind of "Data Loss Fail Safe" or something.

Ho ho!

> If the information is deleted in the file, it uses the information from the database.

Good that doesn't work on a per character basis

Seriously, I want the internals to accept a null value just as they do any other.

[MattTown]

Same problem for me. Update tags in MP3Tag ('cause I can import from a text file, but that's another story), Save tags in MP3Tag, close MP3Tag, open MM3 (3.1 beta, Gold, File monitor on), tags same as before, even after "rescan files". Delete files from library, and "rescan files" finds the new info.

Will check and report status of control parameters above and MP3Tag version.

[chrisjj]

Matt, My problem is specific to nulled tags, whereas it sounds like you're saying your problem hits other updates too.

Do you have Options, Library, [x] Update Track info from Tags when rescanning files?

[MattTown]

Chris,

I had replied before but now can't find that post. Here is an updated version.

My settings in MP3Tag and MM3 were as per REIKA's post, ie MP3Tag NOT modify date, and MM3 only scan for modified dates. Hence, MM3 wasn't finding updated files to read the updated tags from. I changed MP3Tag to change file date and MM3 now finds the updated tags.

I was curious about your particular issue, MM3 not overwriting a tag value with a blank, because I will at times have a requirement for the same thing. In a simple test I have reproduced your results. My test was as follows.

I blanked the Artist field of one file in MP3Tag and Saved the tag. Windows Explorer properties then showed the Artist value of that file to be blank, and the file date to be modified. Opened MM3, Gold licence with file monitor set to scan for files with changed dates/sizes, and the Artist value of that file was NOT changed to a blank. Back into Windows explorer and MP3Tag, Artist value still blanked as intended.

If this behaviour is intended then there shoudl be an option to suppress it (ie allow overwrite with a null) if required. If it is not intended then it is definately a bug.

Matt

[chrisjj]

Thanks Matt.

> If this behaviour is intended then there shoudl be an option to suppress it (ie allow overwrite with a null) if required. If it is not intended then it is definitely a bug.

I cannot imagine why it would be intended.

[rusty]

fyi, this issue has been deferred

For rationale, please see the bug.

-Rusty

[chrisjj]

> fyi, this issue has been deferred

Disappointing - this behaviour is a serious handicap.

> possible solutions to this were briefly discussed:
> 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).

Well, yes How else MM thought it could get its two-way sync to work properly, goodness only knows!

Thanks for the heads-up.

[chrisjj]

Given there's no imminent fix to this bug, can anyone suggest a workaround? Deleting the tracks from the library before rescan is not an option since it breaks playlists.

Any amelioration welcome!

[Lowlander]

This has been fixed in build 1368.

[chrisjj]

Good news - thanks.