I second the request; It happens now and then that one page in the middle of the book is in the wrong orientation: such a feature would help

It takes a fairly long time for the page to display when I order it by time , and then again to order back to alphabetic. I'm assuming it's the time to process on my small configuration. I'm assuming that on opposite, the page "latest comics" is precomputed at scanning time so it doesn't take any computing time to display, just the standard time for displaying a page

I second the request; maybe instead of limiting to a pre-defined number of comics, you could present the comics that have been added to the collection the last 1 ou 2 weeks? The reason is sometime I add only a coule of comic that I found, sometime I add a whole serie that contains 40 comics or more; making it difficult to know in advance what is the proper number of comics that should be displayed

To improve the feature even more, the best solution would be to be able to define that setting (number of days to display) in the admin page.

Here is an other point that would benefit from optimization, it would be a big benefit for users like me that use a small hardware to run ubooquity and like reading on-line.

when using the web interface to read comics, it take a looong time to load the first 2 or 3 pages; I can understand why loading the first page is slow (ubooquity has to load the reader, unpack the comic, load the image renderer, etc...) but I don't understand why loading pages 2 and 3 is significantly slower that loading the pages that follow. After the first pages, there are some slowness every now and then, which I can understand (I'm guessing some background process is interfering with the reader), but it's not systematic and it's not as slow either (or maybe it is related after all because it's about updating the cache?). But the first pages are really very slow to load

I'm guessing this is because of memory limitations on my system (I allow only 128Mo for ubooquity to run on my NAS) because the problem is a lot worse on large files than on small files. On very large comics (comics whose size exceed 80Mo) loading the first pages is so slow that I've given up reading them online entirely.

I'm not sure what is causing the problem exactly: loading a few images in memory for caching should not take more than 10Mo of memory; Even on the best scans, comic page rarely exceed 2Mo. This is something my system should allow: ubooquity uses about 30Mo of memory when browsing the database, and it goes up to 70Mo after I've opened a comic, this should leave 30Mo of memory for caching images, meaning more than 10 pages even for the largest files...

My feeling is that memory management could be improved:

- unpacking the comics uses memory and that memory is not freed at the end of the unpacking: memory usage goes up when opening the comic and doesn't go down after that...

- reading comics loads new images into the cache but old images are not unloaded from memory (when I track memory usage, I only see memory usage growing: it should fluctuate around an average value shouldn't it?)

- when closing a book, the memory is not cleared. Opening a second book right after closing the first one is just not working: I have to wait a long time for memory to go down to the initial 30Mo (I'm guessing it's how long garbage collector does its job)

pdf creates problem: I've converted all my comics to cbz to avoid this problem

Hi,

I've tried it: I've downloaded the H2 software, connected to the database using command like

jdbc:h2:C:\\Users\\Tom\\Ubqt\\ubooquity-4

it all looks ok but then I just don't see any table, any records that I can exploit: were is all the data stored ?

Hi,

I'm trying to setup web proxy on my synology to accelarate browsing, but I don't understand how I can configure that in conjunction with ubooquity: how did you configure nginx?

Going back to the subject: As mentionned above, I scrap metada from Bedetheque, and most "Hors Serie" show as "alternate number" which is reflected in comick rack with the <AlternateNumber> tag

for example:

http://www.bedetheque.com/BD-Cites-obscures-H07-Mary-la-penchee-40559.html

the number appears in comcik rack comicinfo.xml as

<AlternateNumber>H07</AlternateNumber>

I don't know if you intend to do something about it, but it wold be a good idea to read the "alternate number" tag when you do a scan; combined with a (normal string) sorting on the field, you might have a solution for sorting a collection

Hi,

you should probably tray anyway: personally, I've found it easy to install "manually" ubooquity on Synology. The main difficult task is to adapt the startup script but even that may even be simplified since DSM6.0 because we can create scripts directly from within the web admin interface.

But if you are completely new to Linux, it may look scary.You may look there; at the begining, when looking to install ubooquity on my NAS I found this: [Test packages available] Ubooquity: comic book server

I haven't tested it since it doesn't seem to support my brand of Syno, but you can give it a try (and tell us how that works)

Going back to this "Java heap space" error.

The same situation happens sometime when reading a comic using the web reader. It's generally because some scan are insane large (more than 1Mo for an image... I should probably reproces them, but htat's too much work)

When encountering java heap space error, Ubooquity hangs... but it's not 100% dead: for example, I can still refresh the log pages (even though the reader is stuck because of this error).

So I belive you should definitely catch that error in the two situations:

• during a scan
• when reading a book

In case of that error, throw a message for the user, and either kill ubooquity entirely, or try to recover (although I don't know how you can force java to release all memory)