Pre-existing tags are not removed

[bassstorm]

I love to keep my library metadata at bare minimum. Hence I was happy to enable "Remove any pre-existing tags" option on Tagging tab. However, I see a minor issue with that functionality.

Use case:

1. Make sure STYLE and VINYLTRACK tags are disabled in Tag Mapping.
2. Run Discogger over an album with STYLE and VINYLTRACK tags present.
3. Check resulting tags.

Expected:
STYLE and VINYLTRACK tags aren't present.

Actual:
STYLE and VINYLTRACK tags are still present.

There's a workaround: to have an empty value for these mappings and set 'em to write+update. But I'd like to keep actual formatting expression for any potential need, but have it just disabled.

Plugin version: 1.0.20_beta

[ghuDaYuYu]

A new option 'Delete also disabled tags' to the right of 'Remove any pre-existing tags' should solve it. But I never missed that feature and sincerely I am not very fond of it.
Could you think of any adverse effects for users who might just occasionally use it? Also it seems out of the component scope. But will give it a second thought at some point.

[bassstorm]

Well, I see it as follows.
What current name suggests to user: remove all existing tags, then apply whatever you configured in mapping (and disabled ones shouldn't be applied obviously). In other words, original values are removes, new values (from Discogs) are applied. Though some values may be the same in the end, but technically these two are atomic operations.
Having another checkbox is maybe a proactive try to keep backward compatibility (if any), but sounds a bit unnatural as per above.

Could you think of any adverse effects for users who might just occasionally use it?

Not much tbh. One either uses the feature or not. Luckily user can configure exception list, and I personally use that - so re-tagging goes smooth for me (for example, I don't loose my ratings). But as always, powerful tool in careless hands can do harm.

Also it seems out of the component scope. But will give it a second thought at some point.

Sure. You did a great job already! And as I said, I have a workaround I can live with :)

[ghuDaYuYu]

Yes, that label needs to be reworded.
I do not see options much as 'one either uses the feature or not'.
There is also the consideration that configuration should be as little error prone as possible.
But as I said, the feature might finally get included in next releases, along with some warnings and confirmation message boxes : )
Cheers!

[ghuDaYuYu]

Added to TODO list

[bassstorm]

After giving it a moment of thought, I see your point. What you see crucial is complete control over data configured in mapping table.

But then what confuses me is the following. "Write" mode is intended for just adding a missing field. So re-tagging won't touch it anymore. What's the purpose of "Disabled" then - never touch the field (no matter if it's present or not), correct? But what we have currently is that due to some tricky implementation "Write" and "Disabled" have intersection in case of pre-existing tags which configured in mapping table. I.e. "Disabled" effectively means "Preserve" or "Keep", which is really counterintuitive.

With that said, remove any pre-existing tags shouldn't deal with mapping table at all. If disabled, we can cover all use cases by Write/Update/Write+Update/Disable modes (properly implemented). If enabled, we deffo want to actually remove all pre-existing tags as preliminary step, exactly as I personally expected.

That solution obviously relies on removal exception list, which, as you correctly outlined, could be source of surprises. But this IS already, may I say, source of surprises for tags which aren't in the mapping table (like my rating). New checkbox wouldn't (and couldn't) fix that.

So again, I'm not sure if adding more complexity to configuration would make sense. Maybe rewording and a tooltip with more detailed explation of behavior would work better.

No pressure, just shared my opinion. Peace!

[ghuDaYuYu]

You can also consider that the "Update" mode also deletes. It might also sound counterintuitive deleting a tag by 'Updating' it with an empty value, 'Write' can also delete with the 'Force write and update' command.
About 'Disable', now you may get outraged (just joking... no offense intended... peace 🥇), 'Disable' effectively means to me 'Hide' or 'Don't run'. In practice, I am using 'Disable' to filter rows in the results view. If I am working on credits, I disable most unrelated tags so I can focus on credits, another day I may be going for track#, disc#, total tracks, total discs and formats, therefore again hiding any unrelated tags by disabling them. Most times I am not concerned about unrelated tags that should be deleted but just working on additions and updates and incidentally some deletions.
Probably I am being quite ineffective, tbh, I still never attempted to go to the depth of reasoning you do in your previous post. I sincerely appreciate you spend the time to share it here!
I will post here some proposals if they come to mind, and will be glad if you are still interested to provide your expertise, collaboration, etc.
I will also need some time to quietly read your post again... hope we can find a solution that is practical, intuitive... and fun to work with.

Best regards!