Your comments
It would require to have two titles: one for display, one for sorting (like the way it's done in Calibre). In my opinion it is not worth the added complexity.
Yes, you can connect to the database using external tools like Squirrel SQL.
But the simplest way is to use the web client provided by the H2 database itself.
Extract the H2 jar from the Ubooquity.jar file (using any archive management tool, the jar is just a renamed zip file).
Now double clic on it, it should launch the H2 server (a yellow icon in your system tray) and a client in your browser.
You need to provide a JDBC URL pointing to the database file.
For instance if your database file is called "ubooquity-4.h2.db" and is located in
C:\Users\Tom\Ubqt
the URL should be
jdbc:h2:C:\\Users\\Tom\\Ubqt\\ubooquity-4
(note the double backslashes and the absence of ".h2.db" extension)
Keep the default username and password (sa and empty) and connect.
I'm back.
The online comics reader of Ubooquity does not render PDF pages. It merely extract the first image found in the current page and displays it.
By the way the extraction is done using PdfBox. Jpedal is only used to render covers (and pages of PDF shared as ebooks). That's because although JPedal is quite good at rendering PDF, the free version limits image resolution to a point that it can't be used to render comics pages.
The PDF you have a problem with stores its images upside down and contains roation instructions in its layour information (that's weird, I don't understand why it's done that way). In a regular PDF reader, the image is displayed correctly since the rendering pass rotates it. When the image is displayed "as is", it stays upside down.
I plan to replace JPedal with the PDF.js reader, but only for ebooks, not comics. So when it's done, you'll be able to read your upside-down comics, but only by sharing them as books.
Not ideal, I know. :(
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.
Could you provide a PDF file I could download somewhere to reproduce the problem on my side and investigate it ?
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.
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)
Customer support service by UserEcho
This error (Database may be already in use: "Locked by another process")
means that the database file is still seen as locked by Ubooquity. This
lock mechanism prevents concurrent modification of this file.
So either you had another instance of Ubooquity still running, or the
locking mechanism used by the H2 database library (it creates a
temporary file named "ubooquity-4.lock.db" to check if the database is
in use or not) has been tricked one way or another.
In any case this is nothing serious. Just check that Ubooquity is
stopped before starting it again and everything should be fine.