Yes, the feature is still planned and near the top of my backlog.

Version 1.10 was an emergency fix done because recent version of Java broke the rendering of PDF files. So it delayed all the other features I had planned.

I won't give an estimate, because Ubooquity development is affected by a lot of external factor that I cannot foresee, but the work is still in progress.

I looked at the logs you sent me by private message and the ones you posted here, but I still don't know what the problem is. :(

For the "Locked by another process" issue: is the Ubooquity java process still running when you try to restart it ?

As for the network issue, I have no idea.

I am in the process of replacing the current internal server of Ubooquity with another one, perhaps it'll help. But it's a long shot.

I understand that this is a tiresome process, but I have no plans to integrate the Comicrack database with Ubooquity, sorry.

You can read a detailed explanation in this thread.

Also, this is another example of why CBR should disappear in favor of CBZ.

I was asking because the error message you posted is not related to the network at all.

Database may be already in use: "Locked by another process"

means that the database file Ubooquity relies on is already in use by another process (basically you launched Ubooquity twice).

But I fail to see a link between this error and the network issue you are describing.

This is the only error/warning you have in the logs ?

Great ! :)

Check this thread first.

If the ComicInfo.xml fil is not in the comic archive, there is nothing Ubooquity can do about it anyway.

My guess is the problem lies on ComicRack side.

You mean you are running Ubooquity on one device while having its working directory (its database, log files etc) on a network drive on another device ?

2 things you could try:

• Increase the quantity of memory allocated to Ubooquity (like described in the FAQ)
• check in your logs if the problem always happens for the same file: it might be caused by a specific PDF containing very big images for instance

Since the mobi format is a closed one, without public specifications to work on, Ubooquity lists all images in the mobi file and tries to guess which one is the cover, based on dimensions and ratio.

This is far from perfect of course.

If you can send me one or two mobi files having this problem, I'll take a look at them and see if I can improve the guessing algorithm.

My address: tom at vaemendis dot net