Some CBZs result in "page not found"

Darren 6 years ago updated by Ben Erickson 4 years ago 12

My comic collection is comprised entirely of CBZs. A small percentage of these CBZs aren't viewable in the web viewer, but are downloadable and readable in any number of comic reader apps. I've unzipped these problem CBZs looking for superfluous files, but they appear identical to my good  CBZs containing only jpegs. Is there a jpeg format that disrupts the web view?

Under review

Not that I know of.

If you can upload one of your faulty cbz files somewhere, I'll take a look.


Your CBZ contains a "__MACOSX" folder, filled with "jpg" files which are not really JPG files.

To create the cover, Ubooquity looks for the first image file in the archive. In your case, the first image is not readable and Ubooquity fails to create the cover.

The online reader fails for the same reason.

The fix is simple: just remove the "__MACOSX" folder from the CBZ (it has no use anyway).

Thank you. These must be hidden by Mac OS since they're not visible to me. Considering all CBRs I download are converted to CBZ using the Mac's built-in zip compression, I'm assuming these are in the majority of my CBZs.

So this is going to turn out to be a laborious process. 

FYI for Mac users who have created their own CBZs with the built-in Mac compression service: you'll have to use Terminal to delete the "__MACOSX" file from your existing CBZs. The "_MACOSX" folder is deleted when the zip file is unzipped on a Mac. It's recreated when the file is re-zipped using the built-in Mac compression. 

Part of the "I don't care about the outside world" way of doing things of Apple. :/

You're not the only one annoyed by this: https://stackoverflow.com/questions/10924236/mac-zip-compress-without-macosx-folder

I had to fix so many already, which I downloaded as-is... :-(

Yeah, that's the thread I ended up in after you let me know the issue is with the _MACOSX folder. I replicated the Automator Service in that thread. At least now I can right click on the problem CBZs to easily remove the _MACSOX folder. My next task will be rejiggering my CBR to CBZ automation to use a third party app (or a terminal command) to zip and create the CBZs. Thanks again for pointing me in the right direction. 

Sorry to intrude, I have the same problem with some cbz, but I do not own a mac and the files are created along hundred of others (that are correctly displayed) by the same program. 

I don't know if I'm missing something but I do not see any _MACOSX hidden folder nor the images appear to be corrupted in any way. Only the first page is displayed in Ubooquity. It happened only 2-3 times, by the way.

An example: https://ufile.io/hjnvl


I downloaded your example and was able to reproduce the problem.

It seems to be a color space issue in the PNG files of your comic (the first page is a JPEG that does not have any issue) that happen when I try to create the JPEG file that is sent to your browser.

I tried a few things to fix the issue, without success, unfortunately.

I'm out of ideas, so I'll have to leave it at that. Sorry.


It is still quite rare (at least for me), so it's just a minor hindrance. I use a software to download the files from some sites, but since this bug usually happens more often for certain series (uploaded by the same person/group) and the software should not be doing any form of editing or conversion I suppose that the issue is probably within the original source file as created by the original uploader, so nothing more to do. 

Thank you anyway for taking the time to check! :)

I'm not sure if this fixes Mario's issue, but Ubooquity doesn't seem to like gray+alpha PNG files.  For instance, if you `file` the PNG file in Linux and see this:


[abc@xyz ~]$ file tmp/089-044.png
tmp/089-044.png: PNG image data, 920 x 1300, 8-bit gray+alpha, non-interlaced


The page won't display in Ubooquity.  The quick workaround is to open the file in MSPaint and then save it which removes all the alpha transparency and grayscale attributes:


[abc@xyz ~]$ file tmp/089-044.png
tmp/089-044.png: PNG image data, 920 x 1300, 8-bit/color RGBA, non-interlaced


EDIT: I'm not sure if that's a bug, or intended behavior.