Sorry, my explanation was misleading: I didn't think of cookie authentification and just assumed the worst...

It makes sense to allow for multiple network connections using the same cookie

But maybe we could reduce the time-out ? to something like 15min or 30min. This is normally plenty enough to do whatever you need to do. Or let an admin set this value in the admin page?

mmm, I don't use Chrome but you might have a point: I've just tested connection to the admin with 2 different browsers on the same PC and I got the password prompt. So you got that right

But I still feel the admin should be more secured: when wrote this report, I used the same laptop when I left home and when I get to the office. This cookie thing would explain why I didn't have any prompting. But I still feel it's not good enough

• I changed IP address between home and office => this should prompt for a new password
• There was at least 1 hour between the time I left home and the time I get to the office during which I'm sure my laptop was disconnected => this should prompt for a new password

I have a similar problem: my collection contains many "Hors serie" comics displaying HS in the number field (I scrap metadata from bedetheque). And I get a similar warning in the logs during scanning

If you plan to change the type of this field, in a future release be very careful of the ordering method you will use in that field: 95% of comics have a proper number in that field, and you will want to have 1 ordered before 2 and 2 before 10... if you make a string of this field and use normal ordering then 10 will be after 1 but before 2.... which would be very bad

Alternatively, you could add a new field "Alternate numbering" make it a string and populate it during a scan whenever the current number field is invalid; The current number field is the order in which the item is to be seen: when you have a mix of both in a collection, put the "alternate number" at the end of the number field for example

I don't think you need a full rescan to fix this. You can rescan only books that have an empty number field. You could also add a button when opening the book for a rescan of an individual book. This way the user may go and choose to rescan the book when he made a modification

Since ubooquity is designed to be multi-user, it would be nice to be able to create "shared reading list" allowing other users to see/modify a reading list, and "private reading list" that can only be seen/modified by the user

:-( too bad, for once that I was wiling to participate in the development of a project and had some knowledge of the langage

Good news!

Here is the benefit I see in the "average" feature: I've opened my server to several friends, and being able to rate and see the average would allow each other to get information of what comics are worth reading when we are wrowsing through the collection without knowing what to read first

Yes, this would be a nice feature: we could add comics or series to a "reading list" similar to a music playlist; this would allow to remember the advices given by friends

Thanks a lot for looking at this problem. I'm pretty sure you're not closing the files when we navigate from page to page.

I've found an other way (in linux) to investigate exactly the problem:

• find pid of ubboquity
• look in the folder /proc/PID/fd

this folder contains all the file descriptors used by the pid; it's the best way to investigate the problem

I've just encountered the bug again, so I counted the files in that folder, (command line = ls -l fd | wc -l) , it tells me 1023 ! remenber: I'm only allowed 1024 in linux; so I'm pretty sure that's what causing the bug

• After restart : ls -l fd | wc -l) = 48
• After login : ls -l fd | wc -l) = 75
• Now when I load new pages, here what I get

admin@DiskStation:/proc/9202$ sudo ls -l fd | wc -l
99
admin@DiskStation:/proc/9202$ sudo ls -l fd | wc -l
119
admin@DiskStation:/proc/9202$ sudo ls -l fd | wc -l
139
admin@DiskStation:/proc/9202$ sudo ls -l fd | wc -l
159

So, It's pretty clear that I load 20 new fd for each page (corresponding to the 20 icons that I've defined in the admin settings)... until I bump into the 1024 limit

I've reported a bug lately (Too many open files creates a crash) where I explain my suspicions about a very similar problem; in short, I think there is a file-descriptor leak: ubooquity doesn't seem to close the files properly after reading them (mainly, the thumbnails), so after a long period of usage, ubooquity exeed its OS-defined allocation, and this causes the web-server to crash...

it's very possible those two bugs are the same.

I'll if I can force a scheduled restart on my system (it's a synology NAS, I'm not quite sure how I can do that at the moment)

Did you have anychance with the database? I can't quite figure out how it's working