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

Yes, very likely a network issue.

This error is caused by a network issue (the "peer" being the external browser sending requests to Ubooquity).

It happens when the connection is lost during a transfer or when the browser cancels it.

Since this is network related, it should affect both books and comics. I don't know why they behave differently.

It's perhaps due to the fact that book chapters are much smaller files that comic pages.

Do you have the same problem when downloading the full book/comic instead of reading it online ?

If you do, this is really a network issue.

Ubooquity does not have any external dependency to external libraries, it's full Java.

If you are running it on Linux, does your user have writing permission on this "/config" folder ?

Not fixed yet.

The fix will be announced in the release notes when it's done.