Has CBL tagging ever been considered for Ubooquity ?

Yes, when I added metadata support I considered the three schemes supported by ComicTagger.

I don't remember all the factors of my choice (it was in 2014), but from what I can remember:

• ComicRack: de facto standard, as it is the most supported format. Implemented.
• Comet: used by one application only. Not implemented.
• CBI: not supported by a lot of applications at the time (still not many today), and I did not like the use of the zip comment, which was harder to extract/use/understand (not only from a code perspective but for end-users) than a simple embedded file. Not implemented.
  
  And since you mention the CBZ/CBR argument being moot (CBR are a useless heresy when it comes to storing comics), I might add that compression in the CBZ file is pointless (JPG files are already compressed inside anyway), so a good CBZ file should not use it. And in that case (zip file used as a container, without compression), replacing a file inside the CBZ is very fast (although not as fast a changing the comment, granted). But that's just for the sake of argument. I agree with your performance point.

So I have no plan to add support for it as today, mostly because it is not used much at all. (and because I already have a huuuuge feature backlog and not enough sleep).

I agree, the documentation could use some improvement.

But I really lack time to do it properly.

I made the documentation open source hoping for some contributions, but without much success so far...

I removed this information from the UI of V2 because:

• the displayed remote IP is trivial to get anyway (open a browser while at home, type "what is my ip" in Google and pick any result)

• the displayed local IP was confusing for people having several network interfaces, as Ubooquity was picking the first one it found, leading some people to believe that it was listening to this one only (by default Ubooquity binds itself to all locally available network interfaces).
  So in that case you need to find the local IP address of your server either by looking at the admin page of your network equipment if you have one (routeur, provider box...), or by using the command line on the server (ipconfig on Windows, ifconfig on Linux, for instance...)

I know, I know...

But I don't even manage to answer all the questions on this forum (much to my shame), so settings auto-migration is waaaaay down on my "should-do" list. ;p

(By the way, I did update the documentation upon V2 release, so...)

Ubooquity offers a way to interface with other applications using its OPDS feed.

But it requires specific development in the external application.

As far as I know, the only applications that have done the development are:

Challenger Comics Viewer (Android)

Chunky Viewer (iOS)

ComicViewer for Ubooquity (Android)

The provided execution directory does not exist or is not writable

just means that: the directory you are running Ubooquity from (the one you are in when you launch the command, since you didn't specify a explicit working directyory) seems to lack writing permissions for the user you are launching it with..

There is this.

Also, from what I read, ComicRack does not automatically write the metadata into your files (even for CBZ), there is some manual action involved (I'm not using it myself, so I can't be more accurate).

If tags are not displayed for some CBZ files (and if there is actually a ComicInfo.xml file inside the CBZ), send it to me, I'll take a look to understand what's wrong.

That's weird...

Just a long shot: is the clock of your Raspberry at the right time ?

The files on the shared drive are the Ubooquity binaries or your books/comics ?

I looked into this a few years ago (you're not the first to ask about this) and rejected the idea for the following reason:

• It would require waaaay too much time to implement

Also:

• ComicVine is good for US comics but is not usable for european/japanese comics. To do something "universal" I would have had to find and integrate other databases -> even more work and complexity
• Storing metadata inside files (be it a picture, a book, a comic...) is a better practice than storing them in an external database: metadata have a 1:1 relationship with the file they describe, also if you want to stop using Ubooquity and use another software, the database becomes useless to you.
• Given how little I have to work on Ubboquity, I prefer to focus on a "single" feature, which is content access (meaning giving you a way to browse and read your books). Content edition (like getting and inserting metadata) is a whole other family of features that would entail quite a few problems.
  For instance, Ubooquity never modifies user documents. So I don't need to worry about corrupting or erasing your books by mistake. The day I allow Ubooquity to modify this files, I'll have to be a lot more careful.

So, sorry, it won't happen.