I don't remember it, but I guess I said no at the time ? :)

Empty folders are completely ignored starting with version 2.0.0.

The trick is that they are removed at the end of the scanning process. So, new empty directories will be shown until the scan is finished.
If you still see them afterwards, let me know and I'll investigate.

In the next vedrsion (2.0.3), you'll be able to click on the Ubooquity logo on the admin page to go to your library.

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).