Thanks ! :)

So, this one was tricky.

Turns out Safari doesn't like images with a application/pdf MIME type.

That's understandable.

Fixed, will be part of next release (2.0.3).

Thanks for the investigation !

I'll take a look asap (got a baby last week, so I don't have much time for anything else these days :) ).

I still can't reproduce the problem on Windows (working with Ubooquity 2.0.2), so I tried on my Raspbery Pi (on Raspbian).

I followed your protocol, and the number of opened file descriptor stays quite stable, around 70, even when browsing a lot of pages with hundreds of covers.

So I don't understand why you still have the problem unfortunately.

Unfortunately I still have no idea of what could cause this.

I'm not the one who wrote the Synology instruction (I don't own a NAS), so you'll have to wait for a Synology user to update them.

I recently transfered the documentation to Github to give people an easier way to contribute.

This one's really a mystery to me.

So yes, having acces to the admin panel of a Ubooquity instance that has the problem could help.

You can contact me directly by email (and in french ;)) at the usual adress: tom at vaemendis dot net.

Keep in mind that providing admin access potentially exposes the whole file system to me.

I won't abuse that of course, but you have only my word, no technical protection.

Ubooquity supports only ComicInfo.xml as metadata storage because this is the de facto standard.
Other metadata storage methods exist, but they are either impractical or supported by a very small number of applications.

Did you try ComicTagger (it is supposed to support Cbr writing provided you have the right external tools) ?

As for the Rar format itself, it may be superior to the Zip format (which is quite old and far from perfect), but for the sole purpose of storing images, I don't get why it has ever been used:

• Rar format being proprietary, most software just can't modify Rar files (which involves recompressing them).
• Even Rar uncompressing is not necessarily easy depending on the programming platform you are using: for instance, Ubooquity is using an unmaintained library (last update is 5 years old) because that's the only one available for Java.
• Zip, on the other hand, is easily the most widely supported compression format, with many libraries to choose from in all programming languages
• Rar superior features are irrelevant in the context of comics:
  • Compression efficiency doesn't matter: your archive contains already compressed files, the "compressed" file is only acting as a container, not as a way to reduce the overall file size.
  • Stronger encryption: no point in encrypting images inside a cbz/cbr file anyway.
  • Error recovery: it might have been useful in the early days of the Internet (I know, I was there), but it's useless nowadays.
• Sometimes, when done by careless people, cbr files are compressed as solid archive, which are a performance nightmare when you have to extract a specific image from inside the archive.

For all these reasons, I don't understand why the cbr format is still used today (my guess is: pure inertia and habit).

The database of Ubooquity is not encrypted.

See this thread for an explanation about accessing its content.

(Ubooquity has to be stopped, though)

As for the bookmarks, they are stored server side through a very simple REST API.

Just take a look at the Javascript used by the online reader to get the URLs (F12 in most browsers).

(Ubooquity.jar is just a zip file by the way, you can open it with any compression tool)

Thanks, I broke them when I refreshed the design of the website.

It's fixed now.

2.0.2 is out, with an option to display the title instead of the filename.

Let me know if this fills your needs.