Yes, scanning the command prompt to trigger a scan would be easier. Not very convenient, but why not.

I'll add it to the backlog.

No it won't work: Ubooquity is a Java SE application, not an Android one.

Thanks. :)

you're welcome. :)

Well, I don't know much about Python myself. :)

I plan to use Java Mission Control.

But don't bother yet. Once I have done my tests, I'll come back to this thread with what I found (or didn't find). Then I might be able to tell you what I am looking for (or I'll have found and fixed bugs).

I think you should start by trying to run Ubooquity manually and see how it goes.

Just put the jar file in a dedicated (writable) directory and run:

java -jar Ubooquity.jar -headless

Once you have it running and you have successfully accessed a few shared files, then you can try setup something more permanent.

Interesting.
I guess you are using the GUI (not the web admin page).
So the web server part would be broken whereas the rest of the application is still running...
I'll double check that all critical threads are covered by the exception catching mechanism. But it will be a few weeks/months before I do it, I want to finish and release the online epub reader first.

As for the memory management mechanism, the JVM memory management is consistent, it's just a matter of default strategy. Java's default strategy is to free memory only when you come close to the allowed limit (this is not entirely true for all GC strategies, but still...). This makes sense as freeing memory more frequently would consume resources (and induce latency or add micro freezes) without providing much benefit (as long as you consider memory as a non critical resource).

In any case, a small application like Ubooquity should not require any specific memory configuration, nor should it require more than a few hundred megabytes of memory. I have to investigate and create some test case with massive numbers of files.