gotson / komga

Media server for comics/mangas/BDs/magazines/eBooks with API, OPDS and Kobo Sync support
https://komga.org
MIT License
3.96k stars 235 forks source link

[Feature Request] Import ComicInfo `Tags` element #541

Closed schemen closed 2 years ago

schemen commented 3 years ago

Is your feature request related to a problem? Please describe.

It seem currently tags from ComicInfo.xml are not imported

Describe the solution you'd like

I would love for them to be imported. I currently got a automated download system that places chapters into the directory komga accesses. Those have all their metadata in the ComicInfo.xml

Additional context

I'm not entirely certain if this is a bug, but I'll report it as a feature request for now

gotson commented 3 years ago

Hello, it's already implemented, check the documentation: https://komga.org/guides/scan-analysis-refresh.html#import-metadata-for-cbr-cbz-containing-a-comicinfo-xml-file

schemen commented 3 years ago

@gotson I don't actually see that actual tags, even on that wiki page

<ComicInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Manga>Yes</Manga>
<Title>testmanga</Title>
<Summary>test</Summary>
<PageCount>48</PageCount>
<Genre>manga</Genre>
<BlackAndWhite>Yes</BlackAndWhite>
<Year>2021</Year>
<Month>5</Month>
<Day>18</Day>
<Tags>shonen, hero, robots</Tags>
<Writer>cool mangaka</Writer>
<Translated>Yes</Translated>
<LanguageISO>en</LanguageISO>
</ComicInfo>

In this example, it would create 3 tags, shonen, hero and robots

gotson commented 3 years ago

Tags is not a valid element in the ComicInfo.xml schema: https://github.com/gotson/komga/blob/master/komga/schema/ComicInfo_v2.xsd

schemen commented 3 years ago

Hm interessting - some other tools I got read this ( I guess inofficially?) Is there a chance this could be implemented as a "addon" or plugin of some sorts?

gotson commented 3 years ago

The problem is that ComicRack format is old, not supported, and has a shitty schema. If every folk comes in and asks to add support for an element that doesn't exist, it will soon be chaos.

In order to bring a bit of clarity, can you please list the tools (with links) that write and/or read that Tags element?

schemen commented 3 years ago

Sure!

I see that https://github.com/RicterZ/nhentai/blob/8cd4b948e742739d4af7e7b6695c61b9246f9fb7/nhentai/serializer.py does do some inofficial stuff I suppose. I convert it into ebooks with https://github.com/ciromattia/kcc from CBZ -> MOBI. They don't seem to be touching the tags as far as I can see.

I see now where I make the wrong assumption. In the conversion to MOBI I manually (via automatic download pipeline) take the tags and put them into a conforming format for MOBI.

With that in mind, since the download script uses a non-conforming tag, would you have an idea how to go forward? It would be fine if we just close this issue but it would be cool if reading tags could be supported.

gotson commented 3 years ago

I'm a bit lost, I don't quite understand which tool you used that creates the Tags element. Is that nhentai?

Then you mention mobi, but komga doesn't handle mobi, so not sure to understand.

schemen commented 3 years ago

Correct,It tags stuff automatically but I suppose it is not an officially supported tag.

Mobi is another pipeline altogether - sorry for the confusion.

gotson commented 3 years ago

OK but I'm still confused about your pipeline. I an you clarify un more details the various steps and explain at which moment the Tags are added?

schemen commented 3 years ago

The tags are loaded and set by nhentai which outputs chapters in a .cbz format together with the ComicInfo.xml. This is all that is relevant to this issue I suppose - the other stuff was my own confusion and a different pipeline :)

gotson commented 3 years ago

Thanks for clarifying. I don't have any plan to add support for unofficial elements in the comicinfo.xml format for the moment, I'll keep this open for the sake of reference.

MKH-42 commented 3 years ago

Hey,

to have the Element also imported in Komga would be fantastic :-)

rosystain commented 3 years ago

Hello, I am seeking a way to import Tags and ISBN into Komga. It’s would be fantastic if they can be imported from ComicInfo.xml.

I understand that Tags and ISBN are unofficial elements in ComicRack format. But the day they become official items will never come because ComicRack has been dead for years. Besides, ComicRack doesn’t have a good user-experience and lacks macOS support. So I wrote some simple scripts to generate ComicInfo.xml like comictagger does. People like me will never care about ComicRack. The only reason for us to make cbz with ComicInfo.xml is that Komga supports it.

If every folk comes in and asks to add support for an element that doesn't exist, it will soon be chaos.

I agree with this. But it has nothing to do with any folk. Adding support for elements which have related fields in Komga ( like Tags, ISBN, Webtoon, etc. ) will make ComicInfo to be more powerful . And the new ComicInfo.xml will still have a nice compatibility with ComicRack since unrecognized elements would be ignored. ( Although compatibility doesn’t make any sense )

GlassedSilver commented 3 years ago

The issue with ComicRack is that whilst the project is dead its groundwork for metadata sidecar files has been the basis for many kinds of programs that read from and write to a file that's called the same, but reasonably extended what is typically stored in these files.

I would understand not supporting the tags entity if tags was a different kind of data for the various programs out there that write to ComicInfo.xml so if there was no way to know what data to expect from it. However, nothing could be further from the truth with tags. Not really any other way to store tags in ComicInfo if I'm not mistaken.

Same with ISBN. Especially so with ISBN. It's not like the key is called "Product Number" and it could be an ISBN, UPC or EAN. It doesn't get any more specific and would fill a field that's supported within Komga's own metadata set. I don't see this being the gateway to chaos at all when the original ComicInfo.xml specs are so lacking and have been freely adapted for very good reasons for a long time.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

shrublet commented 2 years ago

Hoping this can still be taken under consideration. I'd rather not have to manually set tags for every entry if the capability to read them from local metadata is a possibility.

AyoKeito commented 2 years ago

I'd love to see this functionality added because it seems that there's no way to load tags into komga using sidecar files (i can't see Tags in any section of "Import metadata"). I have a big collection that i'd like to tag, so i wanted to make a tool that will download tags into files and put them into corresponding cbz's, but it seems that i'm out of luck since this tag importing functionality simply isn't there. I'd consider tagging everything manually if komga would write ComicInfo.xml or any other sidecar files (just in case i'll have to change my tools in the future) but i'm not going to bother filling the database that i can't really use outside of one specific software.

If you don't want to add anything into ComicRack, you could probably add the ability to treat any of existing fields as a place for tags? Notes will probably do... Another, probably easier solution, is to merge tags and genres, making them the same thing. It could probably break functionality for some, but i guess it can also be added as a toggle. This way people who need to import tags could write them as genres into the ComicInfo.xml.

Thanks!

GlassedSilver commented 2 years ago

Genres and tags are way too different.

Just read <tags> and call it a day. No reason to fear that anything other than a tag will be in a <tags>.

I would understand waiting with implementing this is discussion was needed for this, but all that happens is people sharing their frustration and no real reason to hold this back other than that it's not an official CR standard, which isn't really a valid reason since all that ComicInfo is in today's practise is a container file for all sorts of software writing to that kind of file. There is no standard that forms beyond the commonly found practicized ways to use this file format and that is established enough with little variance.

Not sure what the hold up is, but maybe I'm not getting something. Maybe there is a competing format by now that I don't know of that I could alternatively use.

ghost commented 2 years ago

With the rest API i had basically no trouble writing a script to read comic info and submit the extra fields

github-actions[bot] commented 2 years ago

:tada: This issue has been resolved in version 0.145.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: