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.

When Ubooquity scans the shared folders, it removes all files that don't exist anymore. If your network drive is offline, Ubooquity sees them as deleted and removes them.

So technically not a bug. ;)

But I get why this is annoying and other users already complained about it on this forum.

So I already have a task in my todo list to prevent Ubooquity form removing files from the database when the shared folder itself (not subfolder) is missing.

In the meantime, you could disable autoscan and perform scans manually when you are sure your network drive is available.

I got your file and I have the same problem, so I'll be able to investigate this week-end.

Technically your Java version is one year old, but this is completely unrelated to this problem. There is no reason (at least for Ubooquity) to upgrade your Windows JVM.