Your comments

Once a file has been scanned, it is not scanned again unless it has been modified or renammed. So the extra step of guessing the correct file type is done only once by incorrect file.
However, it happens once for each page when reading a comics using the online reader, so it's better to have correctly named files from the beginning (although the guessing step is very very fast).

I will not add a renaming feature to Ubooquity as it would go agains one of its core principles: "do not modify the files of the user", ever. But I have found a small tool that does just that: correcting the extension of CBR/CBZ files (it has a few other useful maintenance related features and is really simple, so it's worth a look).

The tool is ZenCBR.
Regarding performances, the current version has a bug heavily impacting reading performances when a scan is in progress. Perhaps that's why you experienced a problem.

I'll look closer at the code in charge of resizing the pages. You use Ubooquity 1.5.0, right ?

Regarding the button placement issue, I can't test it myself as the default Android browser does not exist anymore on devices running on recent Android versions (the official browser is now Chrome).
It could probably be fixed by generating better HTML/CSS than what I currently do, but if it only affects the default Android browser, I'd rather focus on other features.
A missing index has been added in Ubooquity 1.5.0.
So if you are running with this version, you already have the index.
By the way if you are adventurous and like SQL, exploring the database only requires the H2 jar and some tutorial reading.

I'll try to generate a big library (20k books is quite a collection) and do some tests on my Raspberry Pi (which should be less powerful than your NAS), but it will take time.
In fact the comic reader already reduces the image (and a little bit too aggressivly at the moment, due to a bug). The reading device sends the size of the screen and the server resizes the image before sending it over the network. The bug I was talking about limits the width of the page to 1200 pixels, but it will be fixed in 1.6.0.

As for the preloading, it is already done as well (only one page), although it is not working for all devices (for instance it doesn't work on iPad).

So the features are there but they need refining/fixing.
Next version will also contain a simplified screen for advanced preferences (simpler mostly for me) that will allow me to expose settings that I wouldn't have not exposed before for fear of overcomplexifying the interface.
On what kind of hardware (and OS) are you running Ubooquity ?
Hi, it's a different bug.
It's already fixed but not released yet. It will be part of the version 1.6.0.

Weird thing though: I had the bug with Firefox as well.
You solved your problem faster than I was able to answer. :)
The solution is indeed to go into the directory you want to use before calling the "java" command.

If you really want to be ablre to specify your "working directory" (although I can"t think of a scenario where you could not simply go into the directory to launch Ubooquity), you can do it by explicitely setting the Java "user.dir" property:

java -Duser.dir="/my/directory" - jar /path/to/the/jar/file/Ubooquity.jar

But I don't really recommend that solution as it could have unintended side effects (I don't know any but it's safer to just use your method).

I'm glad it's working now. Don't hesitate to let me know if you have other questions.