Support Page "Type=" attributes from ComicRack in ComicInfo.xml

[briandking]

Steps to reproduce

When importing books from a comicrack library, pages can be tagged with types like:

• Deleted ; or
• FrontCover ; or
• Advertisement

Komga doesn't use the Deleted or the FrontCover tags when choosing the front cover image for a book. In my library there are books imported from old purchased CDs and many of the scans include blank first pages. Rather than remove the pages from the zip, in ComicRack I merely tagged the pages as deleted. I did the same with other trailing pages or the occasional page that was scanned twice.

Expected behavior

With a book like this:

<Page Image="0" ImageSize="30113" ImageWidth="995" ImageHeight="1533" Type="Deleted" />
<Page Image="1" ImageSize="471719" ImageWidth="995" ImageHeight="1533" Type="FrontCover" />

The 1st page shouldn't be used as a cover because it's in a "Deleted" state. The 2nd page should be the Cover because: a) it's the first page after all deleted and Advertisement pages ; and b) it's explicitly tagged as the FrontCover

In addition, when reading, any "deleted" pages should be skipped.

Optional feature: ComicRack would allow the option of skipping Ads when reading as well. This is a nice to have but not as important as choosing the correct cover.

Actual behavior

Komga chooses the 1st page as the cover.

Logs

No response

Komga version

0.148.2 (docker)

Operating system

Linux raspberrypi4 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux

Other details

Komga is running in docker (gotson/komga:latest)

Samples of each type value mentioned above, plus Editorial (which I don't expect to change the viewer behaviour, it's just for reference)

<Page Image="33" ImageSize="314951" ImageWidth="990" ImageHeight="1532" Type="Advertisement" />
<Page Image="34" ImageSize="338985" ImageWidth="990" ImageHeight="1532" Type="Editorial" />
<Page Image="0" ImageSize="33678" ImageWidth="1000" ImageHeight="1533" Type="Deleted" />
<Page Image="1" ImageSize="447755" ImageWidth="1000" ImageHeight="1533" Type="FrontCover" />

Acknowledgements

• [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I have checked the FAQ.
• [X] I have updated the app to the latest version.
• [X] I will fill out all of the requested information in this form.

[gotson]

You misunderstood issue report and feature request.

[briandking]

Thanks, I wasn't sure since it is supposed to display "covers", but displays blank pages for a large portion of my collection. Displaying the first page rather than the actual cover could be considered a bug.

[gotson]

Displaying the first page rather than the actual cover could be considered a bug.

Komga doesn't only handle comics from ComicRack.

Quite curious why you wouldn't fix the files by removing those pages. I would say ComicRack should be able to do so easily if you have them tagged already, no?

If I could generate a cover file with the same name as the book, you could also use that with custom covers.

[gotson]

@briandking would you be able to share some of those books with metadata with me ? I thought about it, and doing the custom cover shouldn't be too complex.

You can DM me on Discord to send me some links to the files maybe.

[briandking]

Understood (not only supporting ComicRack).

Regarding not removing the pages. I just haven't done it because I haven't needed to. I'm just starting to switch from ComicRack to Komga. I've been using the ComicRack android App and while reading it allows me to tag a page as a type (FrontCover, deleted, advertisement, BackCover, ...), and those tags change the display behaviour, so I haven't had to modify the comics manually. If I do have to in the future, I'm open to it.

I'll find a place to drop a few samples and DM you. Thanks for taking a look!

[gotson]

The ComicInfo.xml schema doesn't prevent multiple pages to be tagged as FrontCover. Does ComicRack itself prevents this, by only letting you chose one?

[briandking]

I just tested it, and CR will allow setting multiple pages as the cover page. It uses the first one it finds as the actual cover.

[gotson]

I started thinking of this, and how it could fit in Komga.

For deleted pages, if Komga could actually delete the pages from the archive directly, enabled via a library option (similar to "convert all cbr to cbz" for example), what would you think of it ?

[briandking]

It sounds ok to me, and actually would help save some disk space (and time cleaning up myself).

Some counter arguments to consider for other users:

• If it happens automatically, some users might not be expecting it and might have reasons for not wanting the pages modified. Making it optional would probably be ok.
• Do you support read-only mounts for the comics? How would it behave in that case? Try to convert and fail in some manner? Skip displaying the deleted pages anyway?
• Even if it's optional, what if a user enables the feature but doesn't realize some pages are miss-tagged in their library and it removes an art page? You might want a safety mechanism before deleting anything? For example a web page to review all comic pages about to be deleted; or an attempt to automatically verify that the deleted page is "mostly blank" (for example greater than some percentage of a single color).

[gotson]

• Making it optional would probably be ok

Nothing is automatic by default, it would be a library option to toggle on.

• Do you support read-only mounts for the comics? How would it behave in that case? Try to convert and fail in some manner? Skip displaying the deleted pages anyway?

There is no explicit support, meaning Komga will not attempt to detect whether a whole library is read only. That wouldn't make sense anyway, because you could have write access to some files but not others.

It would work in the same way as other features that do modify files (repair extensions, cbr to cbz conversion, duplicate page deletion, book/series deletion) where an exception would be thrown because of insufficient rights.

• Even if it's optional, what if a user enables the feature but doesn't realize some pages are miss-tagged in their library and it removes an art page?

In 2.5 years of Komga, you're the first one to ever talk about this feature of ComicRack. I would expect that people know what they did when they used the feature. As usual with features that can modify files, it is advised to backup files first, and test, before using it massively.

• You might want a safety mechanism before deleting anything?

No. Warnings should be enough.

• For example a web page to review all comic pages about to be deleted

That could be a feature, like we have for duplicate pages, so people can have a look at the pages and perform manual deletion.

• an attempt to automatically verify that the deleted page is "mostly blank" (for example greater than some percentage of a single color).

This would probably not work as anyone expects, I won't be doing anything like that.

[gotson]

I thought of something recently. In order to trust the information in the comicinfo.xml, it needs to match the pages found in the book. For instance if you had information on 5 pages in the comicinfo.xml, but had 10 pages in the book, then the information is clearly unusable.

If we are to delete the actual pages for the ones marked as deleted, or via other means like the duplicate page removal feature that already exists, then the information in comicinfo.xml about the pages becomes unreliable, as the page count won't match.

We could have 2 different way of handling it :

• ignore unreliable information, simple.
• modify the information in the comicinfo.xml file

I am not necessarily in favor of the second option, but do note it's quite similar to #82

[briandking]

Good catch!

I would say we would definitely have to ignore the XML info if we know for certain it doesn't match (e.g. the wrong page count).

As for modifying the comicinfo.xml, if we decide to remove pages flagged as deleted, we would have to modify the comicinfo.xml or we would be creating a situation where we could no longer trust the xml by making the page counts no longer match.

So either:

• delete the pages flagged as deleted, AND update the comicinfo.xml ; or
• don't delete pages and just skip them when displaying and when calculating cover thumbnails

[realFPS]

I also have more than 9k series with front cover information embedded in the xml. Its only the front cover info thoug, nothing is mentioned about other pages.