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.

Since I didn't manage to reproduce the problem, I won't be able to investigate further without more information.

Until Apple provides a simple way to launch pages in full screen (and stay fullscreen when you navigate), I won't be able to do anything.

The OPDS feed is served page by page, each page containing a few items (in your case, 20).

So the solution offered by Seth will probably work, but will serve huge OPDS pages (not really a problem though).

The real cause is probably the pagination managament done by Challenger Viewer. You should try contacting its author.

• complete rewrite of the web administration interface (and removal of the desktop UI): maintaining two interfaces was taking too much time
• server side bookmarks to allow device switching in the middle of a book
• OPDS feed improvement
• other small improvements and hopefully better performances