Replies: 7 comments
-
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. |
Beta Was this translation helpful? Give feedback.
-
Well, I see it as follows.
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.
Sure. You did a great job already! And as I said, I have a workaround I can live with :) |
Beta Was this translation helpful? Give feedback.
-
Yes, that label needs to be reworded. |
Beta Was this translation helpful? Give feedback.
-
Added to TODO list |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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. Best regards! |
Beta Was this translation helpful? Give feedback.
-
I think both me and yourself are talking about the same -- an ultimate goal to have full control over tagging process. The tricky part is to come up with a solution that fits everyone :) Agree on disabling part. Maybe a new mode is needed, e.g. "Ignore", but I'd have a hard time to explain difference to a random user :D |
Beta Was this translation helpful? Give feedback.
-
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:
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
Beta Was this translation helpful? Give feedback.
All reactions