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

All the problems you describe should of course not happen.

The next version of Ubooquity will replace the old internal server (NanoHTTPD) with something more robust: Jetty.

I hope the problem where Ubooquity is still running but fails to answer requests will be solved by this change.

I hope to release it before the end of 2016 (Jetty is already integrated by there are other feature I want to include).

Good news!

And for those (like me) stuck with earlier versions of iOS, the next version of Ubooquity should fix the problem as well.

Well, pages don't really exist in epub files (since an epub is only a collection of zipped html files with some metadata).

If you look at the cookies Ubooquity creates to keep track of your progress when you read a book, you'll find two numbers:

- an index identifying the html file in the epub spine

- a progression percentage for this html file

Having page numbers would require Ubooquity to scan the entire epub and guess page numbers using character numbers (ebooks readers like the Kindle or Kobo ones do that).

Too complex for a too little benefit.

But like I said, you can already get a specific html file (usually a chapter) by index, and keep track of the scrollbar on client side.

Problem found (some missing dependency).

It will be fixed in the next version of Ubooquity.