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

I've encountered similar issues several times.

I can see similar logs in ubooquity:

20160929 08:43:52 [pool-1-thread-20]  WARN com.ubooquity.e.e - Interrupted while sending response (perhaps the 
client stopped the download) - java.net.SocketException - Broken pipe

When the crash happens, the ubooquity process itself looks OK from command line: it's still running (on my synology NAS), java is still OK, it's only the web interface that becomes unresponsive: I get "timed out" error pages when this happens

I suspect there is something wrong within the embedded web server that ubooquity uses: it doesn't handle well parallel requests. For example, when I load a new page [I've set my pages to display 24 items] it loads the first 20 items extremely fast, but for some reason, the last 4 items take forever to load. This is systematic: the first 20 are fast, the remaining 4 are extremely slow.

I suspect the embedded-web server doesn't handle web parallel request, or has limited capacity... but when I reload new pages too fast either to refresh those last 4 item, or to go the next page, the number of items that the server doesn't send accumulates, and after a while, this crashes the web server. This would explain why ubooquity still operates, but we don't see pages anymore: the web server (and only it) has crashed.

It would be nice if ubooquity could detect when the web server crash so it can relaunch it; at least ubooquity could dump a file that our operating system could detect and use to trigger a restart of ubooquity

I just can't figure out why 20 is OK and 24 is bad. Anyway: for now, I changed my settings to 20 items per page, and hopefully, I won't be getting those errors

I'd like to have named groups better than reorganising my folder structure: named group are more flexible, for example I don't know how many groups I may require: it's easier to create a new group than to reorganise the folder structure and rescan the whole library

just login as admin and after use "sudo" before any command that you want to run as root

I got a lot of such errors with pdf files. I've found that when converting them to cbz or cbr those memory leaks have disappeared completely... so I basically converted my entire collection to cbz and I've never had those problem since

Of course, it would be nice to inverstigate on why the pdf format is causing such rpoblems

that's a good idea actually: no need to create profiles, just need to modify the existing user creation module; The solution you propose doesn't fit what I want because my collection lays in a shared folder on my NAS. This means that the user folder is //SHAREDVOLUME/ and that's all. What I could do easily, is create a subfolder that contains the comics I don't want kids to see://SHAREDVOLUME/NOTFORKIDS/, but then I'd need the possiblity to exclude a folder from a kid account.

Other solution is to reorganise the entire collection so that I have two folders ://SHAREDVOLUME/OKFORKIDS/ //SHAREDVOLUME/NOTFORKIDS/

but this worries me: if I want to exclude for little kids (only tintin and blueberry) and teenagers (allowing other stuff) and adult... I would need three folders....

The best would be to be able to create list of folders and assign them to a user account... but that's like profiles again

Hi,

look at the script I've posted soem time ago: I added exporting lang before the main command. This works fine on my DS212

script # System variables.
 JAVA_DIR= XXX
 WORK_DIR= XXX
 PKG_DIR=    XXX
 PORT= 2202
 MEM= Xmx128m
  # prepare environment
  LANG=fr_FR.UTF-8
  export LANG
  exec $JAVA_DIR/java -Dfile.encoding=UTF-8 -$MEM -jar $PKG_DIR/Ubooquity.jar --port $PORT --webadmin --headless --workdir $WORK_DIR
end script

Hi, I'm just inquiring about that feature: 1.10 got out but I didn't seen any improvment on how comics are sorted

just a thought: does the problem occur during the scanning process? looking at some of your logs, it seems you're running out of heap space during scanning. This would be the root problem forcing you to restart Ubooquity: some books in your library are causing problem