Overwriting a file removes its rating [#8573]

[Onweerwolf]

I'm not sure if this is a bug or just a setting that was consciously changed or perhaps it's even possible to change this manually and i'm not aware of it but when overwriting a file that file's rating is removed. To explain further: I have a number of tracks in my library that were ripped before I started paying attention to quality. I'm in a slow process of replacing all those files with new and better rips. In MM3 when replacing a file in such a way the rating would be preserved but in MM4 this is no longer the case.

When i'm replacing files I always have MM open.

Any thoughts on this? I would like to see this reversed to how it was in MM.

[Mizery_Made]

In MM3, if a tag was removed/missing from a file when it was scanned/monitored, then MM3 would retain information from the database (So if you had the title as "Title 1", and then were to delete it outside of MM, when (re-)scanned, MM would still associate the title "Title 1" with the file from the database... and when/if the tags were written by MM, would be re-added to the files tags). Now in MM4, this has changed upon the request of many users (myself included). Therefor, it could be a case of the new files not having a rating frame within it's tags and thus once replaced and re-read... it's removed from the database.

A better work flow in making your replacements would be to use Bex's "Advanced Duplicate Find & Fix" script. Scan the new copy into the database, and then use this script to copy tags and/or statistical and other information (such as playlist entries, play count, etc). Then proceed to delete the old copy. However, I'm not sure of ADF&F's status when it comes to version 4 of MM.

That all said... I could be wrong about the cause of this problem. However based on the information I have, this is my best hypothesis.

[Onweerwolf]

I do use the ADF&F script in certain cases, for instance when I've made a mistake and the filename of the original file and the new file differ. It's a great script in those cases and I couldn't live without it but to have to use it everytime i replace a file would add an enormous workload. It also isn't a solution, just a workaround. And I have already found a much better one, namely the fact that I've made static playlists containing all songs with a specific rating so I can easily look up once in a while if any songs that were rated lost their ratings and then I can mass rerate them. Still it would be nice if I didn't have to do this. When replacing files other DB specific stuff like date added, playcounts, etc. are kept intact, so I wonder why ratings are not kept intact anymore.

[nohitter151]

When replacing files other DB specific stuff like date added, playcounts, etc. are kept intact, so I wonder why ratings are not kept intact anymore.

Read Mizery_Made's post above, he's already described how the behavior was changed (at the request of many users).

[Onweerwolf]

When replacing files other DB specific stuff like date added, playcounts, etc. are kept intact, so I wonder why ratings are not kept intact anymore.

Read Mizery_Made's post above, he's already described how the behavior was changed (at the request of many users).

His post doesn't explain why everything is kept intact except for the rating.

[nohitter151]

When replacing files other DB specific stuff like date added, playcounts, etc. are kept intact, so I wonder why ratings are not kept intact anymore.

Read Mizery_Made's post above, he's already described how the behavior was changed (at the request of many users).

His post doesn't explain why everything is kept intact except for the rating.

Because in MM3, empty tags were never prioritized over something in the database. When you rescan tracks to the library, the tags are always updated, but in cases where the DB had some value but the tag was empty, MM3 always kept the DB value rather than erase it.

Many users felt it preferable that MM would always instead match the actual tag contents when rescanning, even if that meant deleting info from the database. For example, consider you have a batch of 30 tracks, all rated in MM. Using another program you remove the rating tag from all the tracks. Rescanning those files in MM would have no effect, even though you intended that the rating field be cleared for all of the tracks. That's why the behavior has been changed in MM4.

So in your case, you are essentially doing the same thing as the hypothetical scenario above. The track that replaces the original has no rating, so that "null" value is imported.

See:
http://www.ventismedia.com/mantis/view.php?id=1502
http://www.ventismedia.com/mantis/view.php?id=7271
http://www.mediamonkey.com/forum/viewto ... =6&t=38522
http://www.mediamonkey.com/forum/viewto ... 15#p294578

(You'll note that several users were vehement that the previous behavior was incorrect, and could hardly believe that the way it worked in MM3 was the intended behavior).

I hope that answers your question.

[Onweerwolf]

Then why doesn't the same thing happen for playcounts and date added field?

Is there any other tag field that gets erased this way aside from rating?

[Onweerwolf]

Also, imo, there is something missing in the logic behind this change; why not make it so that the rating field is only updated in the database based on what is in the file if the file actually has a rating? The files I replace into my DB all have no rating.

Now I can understand that if someone uses 3rd party software to handle ratings these should reflect in MM, however if the file has no rating and the database in MM does have a rating shouldn't the info from the database be preserved?

In 0007271 Jiri says:

The logic was changed, so that tag has priority over what's in DB. Note that in case some field isn't supported by given format, the value from DB is preserved.

Well this is currently not the case for ratings. There is no priority at all, because when the file has no rating in its tag the rating from the DB is deleted completely instead of being the back-up.

[nohitter151]

Then why doesn't the same thing happen for playcounts and date added field?

Is there any other tag field that gets erased this way aside from rating?

Playcounts, date added, timestamp, etc. are not "tag" fields, they are only saved in the database. So there is no tag to draw from to replace the database values.

All tags would be affected the same way as rating.

Also, imo, there is something missing in the logic behind this change; why not make it so that the rating field is only updated in the database based on what is in the file if the file actually has a rating? The files I replace into my DB all have no rating.

Now I can understand that if someone uses 3rd party software to handle ratings these should reflect in MM, however if the file has no rating and the database in MM does have a rating shouldn't the info from the database be preserved?

Because if you read the links I've posted, people want to be able to scan their files and have the rating or other field always take precedent over the DB, even if it is empty. It has always been the case that tag fields took precedent over DB fields when rescanning, EXCEPT in the case of the tag being empty. In those cases MM3 used to retain what was in the DB. The behavior was changed in MM4 at many users request.

In 0007271 Jiri says:

The logic was changed, so that tag has priority over what's in DB. Note that in case some field isn't supported by given format, the value from DB is preserved.

Well this is currently not the case for ratings. There is no priority at all, because when the file has no rating in its tag the rating from the DB is deleted completely instead of being the back-up.

That's the whole point. Rating tag is empty, so it will also be empty in the database upon rescanning.

Jiri's point is that for fields where MM does not support writing to tag for certain formats, that the DB field would be preserved. But that is never the case for rating, because it can be saved to tags for all formats.

[Onweerwolf]

I see, this change is then probably also responsible for the fact that the album artist tag is no longer automatically updated with the info from the artist tag if the tag was empty when the file was added?

I can see the point for this change but it makes MM much less effective in library management for me, and possibly for others.

So I strongly urge the developers to consider reintroducing the former way of handling this where the DB takes precedence and make this a user defined setting that can be switched on or off under library options, if possible.

That or change it so that the DB only takes precedence if the tag is empty.

Or have users be able to set which DB info for which tags should be preserved and which tags may be changed by 3rd party software.

I realize that this may be an advanced setting but MM is advanced software and imo it would be useful if users could decide for themselves how tags are handled.

[nohitter151]

That or change it so that the DB only takes precedence if the tag is empty.

You're basically asking to revert to the old MM3 behavior.

It seems to me that this is a matter of you wanting it the old way and several others wanting it the new way. Unfortunately, you can't please everyone.

Sure, theoretically you could make it an option. But that would not be trivial to implement (it would at the least require a new string which means there's no way it could be incorporated prior to 4.1), not to mention then there's the argument of what should be the default setting, plus it makes the behavior inconsistent which is not necessarily a great thing. And it's not a big mystery that the devs don't like to have to maintain a lot of different options.

But no one is stopping you from posting something in the wishlist. Who knows, maybe there are lots of other users like you who preferred it the old way.

[Onweerwolf]

That or change it so that the DB only takes precedence if the tag is empty.

You're basically asking to revert to the old MM3 behavior.

It seems to me that this is a matter of you wanting it the old way and several others wanting it the new way. Unfortunately, you can't please everyone.

Sure, theoretically you could make it an option. But that would not be trivial to implement (it would at the least require a new string which means there's no way it could be incorporated prior to 4.1), not to mention then there's the argument of what should be the default setting, plus it makes the behavior inconsistent which is not necessarily a great thing. And it's not a big mystery that the devs don't like to have to maintain a lot of different options.

But no one is stopping you from posting something in the wishlist. Who knows, maybe there are lots of other users like you who preferred it the old way.

Well be that as it may, the current behavior results in data loss and I don't think that is good advertising for MM.

[Onweerwolf]

Also, admittedly I haven't used iTunes or any other library management software in a while but when I last did I'm pretty sure that iTunes did not delete ratings from the DB if the tag was empty. I'm not sure if it updated ratings that were made with other software. So for new users that might want to migrate this can be a pretty relevant issue.

[nohitter151]

Well be that as it may, the current behavior results in data loss and I don't think that is good advertising for MM.

Yes, it results in intended data loss.

Anyway, I'm guessing you could avoid the issue entirely by disabling
Tools | Options | Library -> [X] Update Track info from Tags when rescanning files.

Also, admittedly I haven't used iTunes or any other library management software in a while but when I last did I'm pretty sure that iTunes did not delete ratings from the DB if the tag was empty. I'm not sure if it updated ratings that were made with other software. So for new users that might want to migrate this can be a pretty relevant issue.

Probably so. But iTunes often prefers it's own DB to the point of ignoring tags and for many users that is what drives them away from iTunes. So I wouldn't say that's a great example.

[Onweerwolf]

Well be that as it may, the current behavior results in data loss and I don't think that is good advertising for MM.

Yes, it results in intended data loss.

That depends on your definition of 'intended'.

Anyway, I'm guessing you could avoid the issue entirely by disabling
Tools | Options | Library -> [X] Update Track info from Tags when rescanning files.

I've considered that but wouldn't that also result in other tags not being updated? For instance if I replace old files with new files and the newer files have a spelling error in, say, the album title tag fixed, would MM then use the new tag or delete the new tag and replace it with the old erroneous tag?