Ubooquity displays the title from the "ComicInfo.xml" metadata file found in your comic book archive.

If it doesn't find this metadata file, it just uses the filename.

Series name and number are not used (yet) to generate the name of the comic, so my guess is that comics displayed correctly don't contain metadata at all.

I have plans to allow more customization of the displayed name, but they have not reached the top of the todo list yet.

Well, it'll be fixed in the next version of Ubooquity anyway !

(I'm stuck with iOS 9, and I must not be alone)

Any specific issue with the procedure I described ?

Hi,

Comics and books module are separate mostly due to historical reasons (books were added later).

Ideally there would be no difference between the two.

Adding a third module (or merging the two into a single one) would however require a lot of work.

Given the veeeery long list of feature already on my todo list, this is not likely to happen soon, sorry.

If this is done in a future version of Ubooquity, I guess you'll have a single list of shared folders and perhaps a configurable content tag (comic, book, magazine...) for each folder, or perhaps based on file types, I don't know yet...

True, and part of the work is already done as the embedded Epub reader is already getting the resources contained in the Epub directly from the server.

(although this wouldn't solve the pagination problem)

Yes.

If you are already using a custom theme, open the comics.css file and find the block: .numberblock

Replace it with this:

.numberblock{
display:none;
}

If you are not using a custom theme, just create one (it will be a copy of the default theme) and edit it as described above.

Update, i had a look at a couple of other scripts and the $MEM_OPTS was placed just after java and before the -jar...if that makes sense, so all sorted

That's because the memory option is intended for the Java Virtual Machine, not the Ubooquity program itself (which is running inside the JVM).

Thanks for the precise characterization of the problem, it helps a lot to know exactly where to look.

I'll do my best to fix this in the next release.

Guess I'll have to investigate on Linux though, can't reproduce the problem on Windows...

Deleted comics are file that don't exist anymore on the filesystem anyway.

And displaying more info would require a database request for each file, but I guess at scan time this is not very important.

I'll put it in the backlog.