I guess you should try to ask your question on a QNAP forum, you're more likely to find QNAP "experts" there.

Sorry.

Hello,

the restriction to CBZ and CBR files is by design: the extension of the file carries a meaning which tells what kind of data we can expect to find inside. CBZ/CBR files are supposed to contain images and sometimes metadata files, so Ubooquity knows what to do with them. Zip and rar files can contain anything, so it's better for Ubooquity to ignore them as more often than not they will not be comics.

This problem I have sometimes too. It happens on my iPad 3.

But I think it's different from the "pure" slowness problem Eric and Mike have.

Usually I reload the page and it works.

I have never been able to understand it, especially the part where thumbnails get mixed up, but I'm almost sure this is an iOS only problem (thanks Apple, again):

http://www.steckinsights.com/images-randomly-swapping-iphones-mobile-safari-ios/

https://openradar.appspot.com/19027882

No problem. I was indeed already using Safari.

If there is a solution simple enough to implement fullscreen on iOS I'll do it, but it seems unlikely so far.

iOS users can still use alternative browsers with a fullscreen mode provided by the browser itself. iCab Mobile offers this functionality, for example.

Here is how it works.

The first time you go on the admin page, Ubooquity asks you to create a password.

The password is hashed and stored in a file ("webadmin.cred", in Ubooquity's working directory).

You are then redirected to the admin page and a cookie is created.

The next time you go on the admin page, if the cookie still exists has not expired (it lasts 30 days), you'll not be asked for your password.

If the cookie has been deleted or has expired, you'll be asked to provide your password again, which will be compared to the content of the "webadmin.cred" file.

By the way, did you look for errors in your log file ?

So, I tried implementing this. Not as easy as it sounds.

Well, for Android it was, the following line did the trick:

<meta name="mobile-web-app-capable" content="yes">

But for iOS, it's not that simple (as usual). Although there is a configuration that do launch the web browser in fullscreen mode:

<meta name="apple-mobile-web-app-capable" content="yes">

as soon as you click a link you are redirected to Safari.

I tried to change programmatically the location of the page each time a link is clicked (to stay in fullscreen mode), but it broke some parts of Ubooquity.

Bottom line: you'll have fullscreen on Android in the next release but not on iOS.

I quickly tested your server from my PC and my phone.

The PC is accessing the net through a 1Mbps ADSL connection. Page loading was quite fast (both thumbnails and comic pages), never more than a few seconds.

Then I tried on my phone (LG Nexus 4) using 3G. Pages were loaded even faster (which is logical, the 3G I get is usually faster than my land line).

That means I still don't have any idea why you have this slowness problem, unfortunately. :(

If I improve and extend customization possibilities someday (not at the top of the list yet), I'll probably use HTML templating for all pages (using something like mustache).

This would allow total control over all pages type.

Well for starter, except in a few unfortunate cases (when PDF comics are not simple images), the current way of reading PDF comics is working quite well. Given the little time I have to work on Ubooquity, I have to choose between having one feature working for 100% of cases, or two features working for 90% of the cases.

It's common in software development to choose the second option, as you can easily spend insane amount of time trying to make your software work in every situation.

The second, and perhaps more valid reason, is that I'm not sure that PDF.js will allow me to control content streaming page by page, meaning the full document would be downloaded in the end (provided you don't stop reading) whereas the current reader only downloads what's needed when you display a page.

I have yet to start working with PDF.js and understand how streaming would work exactly. So this is not a definitive no, but for now I plan to stay with the current comic reader.