The file type overlay (in addition to the type already displayed in the "details" dialog) has already been requested, quite a long time ago. I agree it would be useful and I still plan to implement it someday.

The two other features would be quite rarely used, in my opinion. So I will probably never implement them given the huge backlog of features I am already late for. :)

(also, mobi and azw are closed formats that I don't want to "invest" on)

Did you clear your browser cache ?

I can't think of better ideas than what you proposed, unfortunately.

I tried copying the name and password hash from the .xml file over to the .json file in the new format

That's the right thing to do.
But you have to be sure to stop Ubooquity before replacing the json file (Ubooquity overwrites it upon exit).

@TierparkToni: settings are stored in a separate preferences file, not in the database. So it is editable by hand.

Thanks.

I have downloaded them and had begun to take a look, but I've been taken away by non-Ubboquity issues for a while.

I still plan to give it shot. :)

Did you try it on a double-page ?

If so, in which browser ?

No problem. :)

Yes, v1 themes are still compatible with v2 (at least in 99% of the cases).

If you send me a (small please) comic sample with CBI metadata, I might take a very quick look, just in case... (no promises though)

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