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

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: 1228 Add/Rescan failing to see tag deletions [Bug #1502]

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

by chrisjj » Sun May 01, 2011 6:50 pm

Good news - thanks.

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

by Lowlander » Sun May 01, 2011 12:59 pm

This has been fixed in build 1368.

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

by chrisjj » Sun Feb 21, 2010 7:54 pm

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!

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by chrisjj » Tue May 05, 2009 7:32 pm

> 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.

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by rusty » Tue May 05, 2009 4:16 pm

fyi, this issue has been deferred :-(

For rationale, please see the bug.

-Rusty

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by chrisjj » Wed Apr 29, 2009 5:55 pm

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.

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by MattTown » Fri Apr 24, 2009 6:39 pm

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

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by chrisjj » Fri Apr 24, 2009 12:09 pm

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?

Re: 1228 Add/Rescan failing to see tag changes [Bug #1502]

by MattTown » Thu Apr 23, 2009 7:33 am

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.

Re: 1228 Add/Rescan failing to see tag changes

by chrisjj » Fri Apr 03, 2009 7:17 pm

> 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.

Re: 1228 Add/Rescan failing to see tag changes

by Mizery_Made » Fri Apr 03, 2009 6:14 pm

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.

Re: 1228 Add/Rescan failing to see tag changes

by chrisjj » Fri Apr 03, 2009 6:13 am

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

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

Re: 1228 Add/Rescan failing to see tag changes

by REIKA » Thu Apr 02, 2009 11:30 pm

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.

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

by chrisjj » Thu Apr 02, 2009 10:57 pm

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

Top