An interesting reading.
I understand why file modification is a problem when identifying them with a hash (usually when using file sharing systems), but I disagree with the conclusion.
I see the "comicinfo.xml" file a metadata the same way you have metadata in EPUB files, or in JPEG, MP3, etc.
Nobody's trying to store image, ebook or music metadata outside of the data file. Why do it for comics ?

You only modify metadata to fix them, meaning that, ideally, they should be good from the start. They are not (or should not be) used for user-specific data like the last read page. So it's definitely a bad idea to store them only in an external database as they are part of the work contained in the file.

NB: For me, metadata do NOT include user rating and read/unread status. They are different information, from a different source and a different life cycle. I know Ubooquity supports Calibre user ratings in EPUB files, but if I had to do it again today, I probably wouldn't.

Anyway, I plan to add read/unread status for comics and ebooks in one of the next releases, but without CR integration. It would require too much work for a feature I consider is not part of the "core" functionalities I want to include in Ubooquity.

Now if there was some kind of ComicRAck API easily usable from Java, that's something I might consider in the (distant) future.

Well that's an interesting problem you have there. :)
Could you provide a PDF file I could download somewhere to reproduce the problem on my side and investigate it ?

If everything works fine on your local network but is slow when accessed from the outside, I'd be tempted to say your connection (either your fiber or your mobile connection) is the problem.

Although with a 50MB/50MB line there should really be no speed problem.

From the point of view of Ubooquity, there is not difference between a page loaded from a local or a distant connection.

I'll let other users share their experience, perhaps they'll have more ideas.

Just to be sure to understand: the "UTF-8" parameter worked when you launched Ubooquity manually but not anymore when used in the ".conf" script ?

If so, I'll try it again on my side.
(I will be probably unable to use a computer for a week or two, so please be patient, but don't hesitate to ping me at the end of the month if you don"t get feedback)

Ubooquity already supports ComicRack XML metadata files (since 1.7.0).

What features would get from a direct database integration ?

Given the insane pixel density we have today on monitors, I get how this would be nice.

It will require a heavy modification of the reader script though. I'll put it in my todo list (I think it's a good idea), but don"t expect it anytime soon.

I'll focus on the read/unread flag for now. ;)

Sorry, I'm quite late. Here is the line modified with the encoding option (and the new "workdir" parameter):

exec /var/packages/JavaManager/target/Java/bin/java -Dfile.encoding=UTF-8 -jar -Xmx1024m /var/packages/Ubooquity/Ubooquity.jar -port 2202 -webadmin -workdir "/volume1/prive/Ubooquity"

Thanks for the feedback and help !

As for the "user.dir" replacement by the "workdir" option, it's on me.
I told Matthew I would change it. It'll be done soon.