Your call.

I don't mind letting it live if you want.

Let me know.

The "bypass single root folder" feature works by sending a HTTP 302 (temporary redirection) that sends your browser directly to your single folder.

Hence the translation from /comics/ to /comics/1/.

I don't understand why the protocol changes due to this redirection (when tested on my side, I kept the HTTPS).

For now, I think the problem is linked to your proxy settings somehow. But let me know if you have any additional info/ideas, we'll keep digging.

(NB: naming your root folder "comics" is not a problem, Ubooquity uses ids for folder (in your case: "1")).

File size will be displayed in version 2.0.3.

I have managed to reproduce the problem.

To work around it, make sure you don't have a slash at the end of your admin page URL.

(and let me know if this worked or not)

Bad:

localhost:2203/admin/

Good:

localhost:2203/admin

I'll try to find a way to prevent that.

Slashes management in HTML/JS code has been a problem for me for a long time. :/

The API is behind the same authentication layer as all the other pages served by Ubooquity, which is not basic auth. Hence the issue.

I added basic auth support when I implemented the OPDS feed, because the OPDS specification requires it. But for everything else, authentication is done the following way:

1. Ubooquity serves a login pages, wich contains a server "salt" and the server current time
2. The user enters his crendentials
3. The browser sends the login and the hashed password (generated with the user's password, the server salt and the server time) to the server
4. The server returns the home page, with a cookie containg a user token
5. The token is included by the browser with each subsequent request

This way, the password is never sent in plain text over the network. (the token can still be intercepted and access gained, but it's still better than exposing the paswword)

I prefer to restric basic auth to the OPDS feed, because it's really unsafe when you don't use HTTPS.

So I'll try to quickly add an authentication API that can be used by external clients.

It will require some hashing work on client side to protect the password the way I described earlier, but I can provide code samples for that.

Thanks for the info !

Very nice indeed !

I have updated the theme list on Ubooquity website to include it.

Appart from any potential memory leak in Ubooquity (there still might be some), Java will generally use as much memory as you give it when working on memory intensive operations (image handling in Ubooquity for instance).

To restrict the max amount of memory Ubooquity can use, your have to launch it using the command line and the "Xmx" flag.

For instance the line

java -Xmx512m -jar Ubooquity.jar

will launch Ubooquity and give it a maximum of 512 MB to work with.

I still have no lead to follow to try to understand this.

The only advice I can give is to check that there is no permission issues, as other users in this thread seem to have solved the problem this way.

According to your logs, all your Epub files seem to be unzipped (you have folders named "something.epub").

Ubooquity needs actual Epub files, not folders containing the inner parts of an Epub file.