Your comments
Perhaps a side effect of my attempt to manage symbolic links.
Since there is an easy workaround, perhaps I should remove the "feature" altogether.
You can use the "Scan exclusion pattern" option (in the "Advanced" section).
The following pattern will exclude PDF files:
.*.pdf$
But it will do so for all folders, comics and ebooks alike.
I think I might have found this issue. The comics sharing module is is disabled. The Bookreader is using JS and CSS files from the comicreader path, which are not accessible and returning server status 500. See screenshots.
Ouch, good catch !
I'll fix that in the next version.
Usually, I do a "pgrep -lf java" to list all running java processes, then I identify the one running Ubooquity by its command line argument.
I take its PID then kill it with "kill <PID>".
Nothing special here, pure Linux commands. Once you get the PID of a process, there is nothing preventing you from killing it (except if it has been started by another user).
Last thing to check: in earlier versions of Ubooquity, a "<database_name>.lock.db" file was created in the working directory to ensure the database was not accessed by two instances of Ubooquity at the same time.
Details here: http://www.h2database.com/html/advanced.html#file_locking_protocols
But this is done that way anymore, so I don't think you have this issue.
You're welcome. :)
Well that's disappointing. I'll do some test again on my side, but not in a near future as there is workaround.
Just to be sure: did you test by re-entering the symlink in the configuration screen ? They are converted when you save them, so just replacing the Ubooquity jar with the new version won't work, you have to reconfigure the paths.
Customer support service by UserEcho
I'm afraid the hardware inside routers (especially the RAM) won't be good enough to run Java applications.
The way to avoid having a computer running 24/7 is usually to run Ubooquity on a NAS or a Raspberry Pi (probably the cheapest solution).