Import metadata from ComicInfo.xml

[gotson]

ComicInfo.xml from ComicRack is widely used. Importing data from the file contained in the archive would be nice.

Depends on #48

[beville]

Would love to see this support.

Don't know if you've seen it, but ComicTagger might be a handy tool for you to use (https://github.com/comictagger/comictagger).

[gotson]

Would love to see this support.

Don't know if you've seen it, but ComicTagger might be a handy tool for you to use (https://github.com/comictagger/comictagger).

I have no interest in third party tools, I want everything to be implemented in pure Java, so the code is portable.

[beville]

I was pointing it out for possible use as a reference and testing tool. I use it (and in fact created it) for tagging files. CT can write ComicInfo.xml for metadata tags, and I think it would be great if your server supported them as well, particularly for organizing files. ComicInfo.xml is as close to a de facto standard for CBZ metadata as we are likely to get for a while.

[gotson]

Thanks for pointing it out. At the moment I have no plan to support writing of ComicInfo. It may be an accepted format, but it's a very bad one, and with ComicRack vanished, it's only going to be worse with people potentially adding to it on the own without centralized consensus.

[beville]

Sorry that I was unclear. I wasn't suggesting that you should add support for writing ComicInfo, as I don't think that would be the appropriate for a media server, but was just voicing my own happiness for the possibility of Komga reading existing files that contain ComicInfo, and hopefully using that info for organization. :-)

[gotson]

Sorry that I was unclear. I wasn't suggesting that you should add support for writing ComicInfo, as I don't think that would be the appropriate for a media server, but was just voicing my own happiness for the possibility of Komga reading existing files that contain ComicInfo, and hopefully using that info for organization. :-)

That's totally planned, i'm currently adding manual metadata editing, so that will bring the database fields, API methods to retrieve in the UI, and UI integration with edition.

Once that's done i'll work on reading ComicInfo.xml, which shouldn't be too complex to add.

[GlassedSilver]

Could I just add that writing to SOME kind of format that isn't a centralized database specific to the application has this massive benefit of the meta data being easily transferable?

I mean, we're right now LITERALLY talking about how handy it is to be able to feed Komga all this work we've put into organizing our manga and comics in other programs that we're departing from, e.g. ComicRack.

Unless there's major assurance Komga is going to be around "forever" as in actively supported, not the least by readers you want to connect to, there should be some concern about future-proofing the work we transfer into and directly manually put into Komga ourselves.

Just because Komga is open-source, which is obviously a) amazing and b) a SUBSTANTIAL differentiating factor from ComicRack (beyond the other aspects), doesn't mean history cannot repeat itself and at least with ComicInfo you're looking at a format that has community support. No need to add to it in terms of relying on it for this application's inner workings, but being able to export gathered meta data into a ComicInfo isn't something we should discard too easily methinks.

There's probably other things one can consider as well, maybe this is the time for a new and better format - I'd be happy to hear what you'd improve on and if you wish I'd love to provide personal input as well. Just saying that a database is the best option to index, make searchable, organize metadata etc, but beyond those aspects there's reasons why one would likely still enjoy having a way to export all that data either partially or all in one go for whatever reason.

Probably some readers would need a ComicInfo as well still. (or other formats if the reader isn't comic-specialized)

Sorry for the rambling, I also don't wanna sound like I know better, it just dawned on me that we're right now enjoying that one perk of ComicInfo and at the same time forgetting a little bit to not make ourselves too dependent on what is arguably niche software. But maybe gotson has something on their mind and simply not mentioned yet? Sorry if I sound probing, I'm just rather curious if this is something that is being thought about. CR practically dying and in a very slow and discomforting way has left some battle scars... :/

[gotson]

Your concerns are legitimate. Here are a few points that come to my mind:

1. ComicInfo has the problem of being only related to a comic, meaning you can't use it (or it could be difficult) to modelize other data, for example about a series.

2. Komga has a RESTful API, which will serve all the information needed. Anyone can use it to implement any tool that does pretty much anything. Metadata will not be locked in the database and innerworkings of the software, it will be available for everyone to use as they see fit. You want to built a small tool that introspect your libraries and write back the ComicInfo to the files ? Easy, you can even use the programming language of your choice!

3. I don't know exactly how people use ComicInfo (I personally don't), but most likely the information came from somewhere in the first place, like ComicVine. Of course some people tweaked the information to their liking, but that might be a small slice of the population. The source information will be available at some point in Komga too, through metadata providers, and then it will be easy to retrieve it, without the need for ComicInfo.

Not saying i'm not gonna develop something to write to ComicInfo, but that's clearly not a priority right now. You are more than welcome to open a different issue if you want to track it.

[GlassedSilver]

I'll get to point 3 later on, but fair enough on points 1 and 2, that's good to hear especially with your very last paragraph.

As for 3 I'm thinking of the predicament of trusting third parties too much... Meta data sources might always be available, but they might as well not be easily scrapable forever. And again: manual overrides are a thing. This is especially true if you collect niche items like doujinshi, which are fan-made mangas for existing series or originals. There's sources for information, but due to the nature of these works some authors prefer not to be listed on what is basically the only portal worth its salt (doujinshi.org, NSFW warning, very mixed content). Basically doujinshi artists are tolerated by the rights holders of existing series as long as they kinda fly under the radar and don't make too much money.

It's all a bit complex, just saying that there's always reasons for data being easily transferable. Meta data included. What I can scrape today might not be what I can scrape on a database rebuild in another or even the same software tomorrow.

Thank you for not outright discarding the concept and keeping the issue in mind, it's greatly appreciated and I cannot wait to see Komga prosper. CR left a humongous gap.

[gotson]

Released in https://github.com/gotson/komga/releases/tag/v0.25.0

[lukemin]

Komaga is really amazing app.
I downloaded my comics by Hitomi-Downloader. Would you like to add the function to collect metadata from the info.txt generated by Hitomi-Downloader?

The language of info.txt is as the same as the setting in General Preferences. So for one comic, There may have several different info.txt.
Take Chinese and English as example:
Chinese :
info.txt
图库 id: 1172760

标题: 【中國語】NanoCore「納米核心」2018.1月Ｒ１８の絵のコレクション②

艺术家: N/A

分组: N/A

类型: imageset

系列: nano core

人物: N/A

标签: female:anal, female:mother, female:stockings, female:x-ray, incest

语言: Chinese

English:
info.txt

Gallery ID: 1172760

Title: 【中國語】NanoCore「納米核心」2018.1月Ｒ１８の絵のコレクション②

Artists: N/A

Groups: N/A

Types: imageset

Series: nano core

Characters: N/A

Tags: female:anal, female:mother, female:stockings, female:x-ray, incest

Language: Chinese

[gotson]

Please do not comment on closed issues.