Given the size of the collection of some Ubooquity users, I'm not sure getting all the items at once is a good idea... ;)

I get that the page size defined for web pages is not ideal for OPDS pagination, but for now they are linked.

Couldn't you iterate over OPDS pages one after another to get the full list when it exceeds the page size ?

The proper way to do it would be to write a real and clean REST API, but my backlog is still growing faster than I can catch up... :(

Both CBR and PDF covers are currently extracted using internal Java libraries (JUnrar and PdfBox).

Only the first page (or file in the case of a CBR) of each comic book is rendered/extracted.

Older versions of Ubooquity (I don't remember which ones exactly) used to put "null" in the description when no metadata was found. This bug has been fixed some versions ago, but it doesn't fix book entries created with the buggy version.

So if you scanned your files with an old version, you'll have to clear your database (the "Clear comics database" button) and scan your comics again.

If your comics were scanned and added with the latest version, then it's a new problem and I'll need you to send me an example of PDF file that does not work (a single page PDF is enough, since you can generate them).

My address: tom 'at' vaemendis 'dot' net

If Ubooquity fails to extract the covers of your book, there is probably some errors in the logs.

Could you take a look and post them here ? They'll give me more info about what could have gone wrong.

Added to backlog as well, but this is not a bug: OPDS search is supposed to return only entries, not categories (in Ubooquity's case, folders are just some specific OPDS categories)

Added to the backlog.

No, that's a bug.

Thanks for reporting it.

Any SSL/HTTPS related error in the logs ?

It can work (other users are successfully using Apache reverse proxy with Ubooquity), but I never did it myself.