[Bug] Possible regression with opening CBZ files

[kkwpsi]

What Went Wrong?

Hello 👋
I was using Booklore 1.17.0. In early January 2026, I scanned my comic book library. The comic book (cbz file) I'm referring to was also scanned, its cover was added, and I was able to read it. Today I updated Booklore to version 1.18.5, and this particular comic book was no longer readable. Booklore reports that it can't open the zip archive.
The command "podman exec -it booklore unzip -l /books/start/'title.cbz'" correctly displays the archive contents. 7z app confirms that it is a zip archive.

Container logs include:

2026-02-02T23:34:37.245+01:00 ERROR 6 --- [booklore-api] [io-8080-exec-34] c.a.b.service.reader.CbxReaderService : Failed to read archive for book 5773

java.io.IOException: Unable to read ZIP archive with any supported encoding

I restarted the container several times. I also replaced the cbz file, i.e., repacked it, and, incidentally, zipped the files so that there are no folders in the archive. The archive contains 182 JPG files. No changes.

cbx-reader works. Other comics, including CBZ, open correctly. However, I can't test all of them.

How Can We Reproduce This?

Try to open a comic to read, but instead of comic book pages, an error appears.

What Should Have Happened?

The comic book page should appear.

Screenshots or Error Messages (Optional)

Any Ideas on How to Fix This? (Optional)

I can only assume that something has changed at the Java level (CbxReaderService?), which is why the application cannot open the cbz archive.

Your Setup

• Debian 13.3
• Booklore 1.18.5 (ghcr.io/booklore-app/booklore:v1.18.5),
• Podman compose
• local storage
• on desktop: Firefox 147.0.1

Before Submitting

• I've searched existing issues and confirmed this bug hasn't been reported yet

[kkwpsi]

The bug still persists in version 2.0.0-2.0.5. I haven't noticed any changes in Booklore's behavior, logs, or the unzip output run inside the application container.

[RikH90]

I'm also getting this bug with certain .cbz files. Definitely not all of them though.

Log doesn't offer much info, but included anyway:

2026/03/01 14:12:43 | stdout | at org.booklore.controller.CbxReaderController.listPages(CbxReaderController.java:28) ~[!/:0.0.1-SNAPSHOT] -- | -- | -- 2026/03/01 14:12:43 | stdout | at org.booklore.service.reader.CbxReaderService.getAvailablePages(CbxReaderService.java:84) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | at org.booklore.service.reader.CbxReaderService.getImageEntriesFromArchiveCached(CbxReaderService.java:179) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | at org.booklore.service.reader.CbxReaderService.getCachedMetadata(CbxReaderService.java:172) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | at org.booklore.service.reader.CbxReaderService.scanArchiveMetadata(CbxReaderService.java:201) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | at org.booklore.service.reader.CbxReaderService.scanZipMetadata(CbxReaderService.java:260) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | java.io.IOException: Unable to read ZIP archive with any supported encoding 2026/03/01 14:12:43 | stdout |   2026/03/01 14:12:43 | stdout | 2026-03-01T14:12:43.424+01:00 ERROR 1 --- [booklore-api] [t-handler-11460] o.b.service.reader.CbxReaderService      : Failed to read archive for book 16324  

[kkwpsi]

Could someone reopen this issue?

[SuperEllipsis]

Could either of you open one of the CBX files that are unreadable with a zip progream, and check if any of the image page numbers are very long. Because this may potentially be due to an update in Release v1.18.4, which adds a way to naturally sort images when reading a zipfile.

Since this sorting is done with Integer compares, it can throw an number exception on page numbers larger than an Integer size. I has an image titled: "05521195721111311921_copyright.jpg", which when it tried to sort, triggered the exception. A manual fix, before any code changes, could be to split the long page number "055211_9572111_1311921_copyright.jpg", which fixed my case

[RikH90]

In my case, there was no sign of long filenames, the ones in the screenshot are indicative of all the others, all of them are the same format.

I did see that when looking at properties, it says RAR, not ZIP, although it's a .cbz file, not sure if that's relevant.

It's inside a folder in the .cbz

Filenames structure

Properties

Some other things to consider, all of the .cbz files I get this issue with have [ ] in the name.
The .cbz also has some dashes, underscores and spaces

[balazs-szucs]

It's a RAR named CBZ... I'm assuming the most likely cause is that the reader does not use ArchiveUtils to correctly identify the archive type, and it is essentially trying to open a RAR by invoking methods meant for ZIPs. Either way, this has zero relation to my PR that closed this issue. Open a new issue.

Or, since it is a relatively trivial issue, it would take maybe a few minutes to fix the code or your library. E.g., fix the code to identify archives via their magic numbers, or just rename your files to match the archive type that they actually are. E.g., RARs should be named .cbr, ZIPs should be named .cbz, etc

[balazs-szucs]

The logs you posted are rather clear:

at org.booklore.service.reader.CbxReaderService.scanZipMetadata(CbxReaderService.java:260) ~[!/:0.0.1-SNAPSHOT] 2026/03/01 14:12:43 | stdout | java.io.IOException: Unable to read ZIP archive with any supported encoding

Notice how the method that errored called: scanZipMetadata

then on your picture, for the type it says: Rar

[RikH90]

Yeah, it's only with looking at the properties now that I see it was named faulty. Very annoying, since I didn't name it myself, so I didn't know that it was a RAR in stead of a ZIP. I tested renaming it and that seems to do the trick.

Not sure if there's any way to check that without opening the file in 7zip and looking at properties.
Unless @kkwpsi has any other input, that's it for me on this issue.

[balazs-szucs]

Not sure if there's any way to check that without opening the file in 7zip and looking at properties.

While Linux has the file utility, file type validation should generally be handled by the backend's logic. A fundamental rule of development is to never trust user-provided data. The reader service should use ArchiveUtils to determine the actual file type and process it accordingly, rather than relying on simple filenames... Just my 2 cents here.

Hence why you should make a ticket for this, because no-one actually looking at this ticket because it has been closed for month, if you make a new ticket somebody who willing to implement this may see it.

[kkwpsi]

I considered reporting Booklore's inability to read a file whose extension doesn't match the content (e.g., *.cbz is a rar archive) as a bug, but I wrote a script that matched the file extensions in my library to the content. However, I believe Booklore shouldn't generate an error here. After all, a typical archiver opens the archive, even though the file extension can be misleading.

Getting back to the problem: in my case, the files in the archive contain a long, fixed numeric value, but this numeric value doesn't store page numbers. A short excerpt:

Henn_9781607746362_epub3_107_r1.jpg
Henn_9781607746362_epub3_108_r1.jpg
Henn_9781607746362_epub3_109_r1.jpg

Since this numeric value is not a page number, but rather a string, the error is on Booklore's side.

[balazs-szucs]

I considered reporting Booklore's inability to read a file whose extension doesn't match the content (e.g., *.cbz is a rar archive) as a bug, but I wrote a script that matched the file extensions in my library to the content. However, I believe Booklore shouldn't generate an error here. After all, a typical archiver opens the archive, even though the file extension can be misleading.

Getting back to the problem: in my case, the files in the archive contain a long, fixed numeric value, but this numeric value doesn't store page numbers. A short excerpt:

Henn_9781607746362_epub3_107_r1.jpg
Henn_9781607746362_epub3_108_r1.jpg
Henn_9781607746362_epub3_109_r1.jpg

Since this numeric value is not a page number, but rather a string, the error is on Booklore's side.

"I want Booklore to fix X bug, but I refuse to let the people who can actually fix it know there's a problem. Anyway, here's another bug that the developers will just have to figure out telepathically and fix, because I only write about it in a dead-issue"

🤦‍♂️

Anyways, gonna subscribe down from this thread. No need for me to get notification about this...

[kkwpsi]

balazs-szucs , I don't understand. I don't know why this thread was closed prematurely, because the issue I initially reported hasn't been resolved. I also posted in this thread asking for the ticket to be reopened. Should I report the same issue twice? 🤷‍♂️
@RikH90 's case is another story.