Your comments

The default theme files are embedded in the Ubooquity jar file.

When you create a new them in the administration screen, a copy of the default theme is made in the "theme" folder (with the name you chose), so that you can modify it as you see fit.

See "Create a new theme" on this page:

http://vaemendis.net/ubooquity/static10/themes

This is me forgetting to clean up the Ubooquity statistics database and being on holidays far from my computer when it becomes full.

In detail, Ubooquity regularly checks if a new version is available by calling my server. I count these calls and store the result in a database, so that I can have an approximate count of how many people use Ubooquity.

What you see is the server telling Ubooquity that it failed to use the database.

I made room in the table, you shouldn't see this error anymore.

My aplogies for the issue.

The information you want is not available through an API.

But it is written to the logs each time a scan is done.


So if you can ssh into the server, you should be able to get the number and dates with a bit of bash.

When Ubooquity fails to open an archive (e.g. zip or rar), it checks its type using its file signature (also called "magic bytes") instead of its file extension.

Hence the lines you fins in your logs:

20200529 16:32:28 [Scanner thread] WARN com.ubooquity.f.a - Failed to
read file, checking potential extension mistake (cbz/cbr) for:
/comics/Lucky Luke/Zack Album - Lucky Luke 01-14/Zack Album 03 - Lucky
Luke - und der Großfürst.cbr
20200529 16:32:28 [Scanner thread] INFO com.ubooquity.f.a - File type is ZIP (cbz)

When a file has the wrong extension (in this case, cbr instead of cbz), Ubooquity will retry reading it using its real type.

A cbz file will always be correctly read, whatever its extension may be.

Rar files reading is less reliable: Ubooquity relies on a libreary (Junrar) that sometimes has issues with some rar files (and can't read RAR 5 files in any case). If the library fails to read a rar file there is nothing more I can do.

My advice if you are able and willing to recompress your files: drop the RAR format completely, it has almost no advantage over ZIP and a lot more issues due to its proprietary nature.

You can limit the quantity of memory Ubooquity is allowed to use by using the "Xmx" parameter in the command line.

For instance the following command will launch Ubooquity with a hard limit of 512 MB of RAM:


java -Xmx512m -jar Ubooquity.jar


Now if this quantity is too small, you might sometime saturate it with when performing memory intensive operations.
That’s when you get java.lang.OutOfMemoryError: Java heap space errors.


It's up to you to choose the best compromise for the hardware you use and the operations you perform with Ubooquity (PDF processing can be memory intensive with the current version).

Hi Henry, no problem, Covid-19 is impacting everybody.


When implementing the hash mechanism, I used these guidelines:

http://pajhome.org.uk/crypt/md5/auth.html

(more specifically the "Adding MD5 to an Authentication System" part, with sha256 instead of md5).


While looking for a solution to your issue, I noticed that in these guidelines, the user password is considered as the key and the salt is considered as being data when calling the hex_hmac_sha256 method.


So if you swap the password and the salt when using any of the services you mention, you will get the same hash as the one generated by Ubooquity.

Did you specifically authorize your user for each folder you shared ?

Did you stop Ubooquity before updating the json file ? Otherwise it might have been overwritten when Ubooquity stops.

Hello Henry,

You should find the info you need in this post:

https://ubooquity.userecho.com/communities/1/topics/280-script-to-change-the-admin-password

It's about the admin password, but the user password hashes are generated the same way.

Let me know if something's unclear.

The next version of Ubooquity will support more recent versions of Java (11+).