Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unlocked tags not removed on metadata refresh #1689

Closed
5 tasks done
jvkohler opened this issue Sep 6, 2024 · 3 comments
Closed
5 tasks done

Unlocked tags not removed on metadata refresh #1689

jvkohler opened this issue Sep 6, 2024 · 3 comments
Labels

Comments

@jvkohler
Copy link

jvkohler commented Sep 6, 2024

Steps to reproduce

  1. Scan comic into Komga with embedded ComicRack data that includes tags.
  2. Edit the embedded data with ComicRack and remove the tags, update the embedded data.
  3. Refresh metadata in Komga

Expected behavior

Unlocked tags should be removed when not present in the embedded metadata

Actual behavior

Tags not present in the metadata are kept in Komga, with no way I can find to mass remove them.

Logs

No response

Komga version

1.12.1-master

Operating system

Docker on Debian Linux

Installation method

Docker

Other details

This seems related to #1498, but I can't add to that report directly.

That issue was closed due to ComicInfo not differentiating between missing and empty fields. I put forward the idea that when building metadata for an object, these are equivalent. An empty field is the same as a missing field, in that it has no information to be added to the accumulated metadata model. It's not meant to use blank entries in ComicInfo to suppress lower priority metadata layers, and responsibility for the correctness of the ComicInfo metadata would fall to the owner of the file. Komga can safely assume that the ComicInfo is authoritative with the only higher priority metadata source being locked fields in the Komga database. This would free Komga from having to provide bulk data management to the same extent as external tools.

Acknowledgements

  • I have searched the existing issues (open AND closed) and this is a new ticket, NOT a duplicate or related to another open issue.
  • I have written a short but informative title.
  • I have checked the FAQ.
  • I have updated the app to the latest version.
  • I will fill out all of the requested information in this form.
@jvkohler jvkohler added the triage label Sep 6, 2024
@gotson
Copy link
Owner

gotson commented Sep 6, 2024

that's not how things work in Komga. Metadata fields that are collections are added upon. Metadata fields that are single field are overriden.

There could be multiple metadata providers contributing to one book or series, that's why it's additive.

@gotson gotson closed this as not planned Won't fix, can't repro, duplicate, stale Sep 6, 2024
@jvkohler
Copy link
Author

jvkohler commented Sep 6, 2024

That's how I was assuming it worked so perhaps I'm not being clear on what the issue is as I see it. Komga is retaining unlocked information sourced from the Komga DB during metadata refresh. This is unintuitive, as one expects a refresh to build a new metadata set from the configured providers. Komga's existing DB unlocked metadata fields should not be used in any part of the metadata refresh. Locked fields should obviously work as you described.

@gotson
Copy link
Owner

gotson commented Sep 6, 2024

you're understanding is incorrect. Metadata providers only add data. If a field is single valued, it would override the value. If a field is a list/collection, it only adds to it.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants