Cover art not populating or incorrect

I'll need a bit more information to guess what's happening.
By "incorrect", you mean the cover of another book/comic ? Or a page of the right book but not the cover ? Or something else ?
Also, on what are you running Ubooquity ? A desktop (Windows, Linux, Mac OS ?), a NAS ? Are your file located on the same device or do you access them from a network drive ?

If you can, copy and paste here the your system infos (there is a link at the top of your admin page (if you use the web admin), and a button on the first screen of the GUI ("General"->"System info")).

Sometimes they will have covers of other books and a simple refresh solves that issue. However, not all the covers populate, some are a white and grey book even though the cover is in the metadata, and some others are random covers (possibly a page in the book). I have firebug lite installed and when I right click on one image in the web interface and hit "inspect with firebug", I am shown the following:

<img src="/books/185/CompTIA%20Linux_%20Study%20Guide%20-%20Roderick%20W.%20Smith.mobi?cover=true"/>

While I am not great with all of this I noticed the path is /books/185/... My directory the server is looking on does not have /185/ as a folder or anything. So I am not sure what that is.


Here is my system info:

Ubooquity version:	1.8.2 built on 2015-08-23 at 16:10
Java version:	1.8.0_60
Java vendor:	Oracle Corporation
Java VM name:	Java HotSpot(TM) 64-Bit Server VM
OS name:	Mac OS X
OS version:	10.10.5
OS architecture:	x86_64
Number of processors:	4
Max memory:	1820 MB
Free memory:	158 MB
Total memory:	185 MB

isUserManagementEnabled:	true
comicWidth:	160
comicHeight:	230
comicsPaginationNumber:	30
bookWidth:	160
bookHeight:	230
booksPaginationNumber:	30
autoscanPeriod:	1440
isWebAdminEnabled:	true
theme:	modern
reverseProxyPrefix:	false
keystorePath:	false
keystorePassword:	false
isOpdsProviderEnabled:	false
hideEmptyFolder:	false
scanExclusionPattern:	true
bypassSingleRootFolder:	false

window.innerWidth:	1147
window.innerHeight:	724
window.outerWidth:	1147
window.outerHeight:	819
window.devicePixelRatio:	2
navigator.userAgent:	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
navigator.platform:	MacIntel
navigator.language:	en-US
screen.availWidth:	1440
screen.availHeight:	819
screen.width:	1440
screen.height:	900

Yes, the URL you see are not directly related to the directory structure of your collection. Nothing's wrong here (the "185" is an internal ID Ubooquity assigned to this book during the scan).

This white an grey cover is the default one, displayed when Ubooquity was not able to find the cover in the book:


It should not happen on Epub files (if you have an example of non-working Epub, I'd be interested in seeing it).
Mobi files are another story: the format is not public (and not documented) so Ubooquity extracts all images it finds (using a very empirical process) and tries to guess which one is the cover. That's the best I can do for Mobi files.

As for the mixed covers (the problem solved by a refresh), I have it sometimes on my iPad, but I have never been able to understand why. Never had it on Windows (with Firefox or Chrome).
Do you have this problem only with Chrome or also with Safari ?
(I don't own a Mac, so investigating this one will be difficult)

Greetings Ethan & Tom,

I believe I have a possible solution as follows:
Say my Ubooquity.jar lives in a folder "Resources", so ./Resources/Ubooquity.jar
There should be a "cache" folder livin ./Resources/cache/

$ ls ./Resources/

cache/
logs/
themes/
Ubooquity.jar

$

Delete, remove, or rename the folders corresponding with the book types you are missing covers for :

$ cd ./Resources/cache/
$ rm -rf ./books/
$ rm -rf ./comics/

Then open / launch Ubooquity, navigate to "books" and/or "comics" and click "clear books database".
Launch new scan. (and "Apply and restart server" if needed).
This should rebuild the cover archive and you should be back in business with enjoying your collection.

Unless there is a bug I don"t know about, the cache folders (books and comics) are cleared when you click the "clear database" button. There is no need to clear them manually.
And this will indeed rebuild your whole database, rescaning all files and regenerating all covers.

Thanks for looking into this. I realized a lot of the files were .mobi and I converted them to .epub and this allowed the files to be edited beyond metadata. From there I was able to see what made up the book and was able to assign "cover.jpg" as the actual cover; which seems to have fixed the books. It was just weird because any other viewer (Kindle, iBooks, etc) was showing it how I saw the books in Calibre before modification. I appreciate your time and your work with this application.

I've had this issue with some comics because they were created on a mac. The way I was able to fix it was to extract the book itself (on something other than osx) and delete the .DS_Store files that were in the archives and recompile them to a cbr or cbz. OSX has an annoying habit of creating those hidden files every-freaking-where and often are the first file detected by some readers so it thinks that's the cover image. Since it's not, it displays as blank in Ubooquity. Protip, windows based os's will show those files naitvely, but if you use linux to do it, any file that starts with a period makes it a hidden file. Hope it helps. If you need assistance with the process I'd be happy to lend a hand if needed.

I think the problem you had was fixed by the recompression step, not the deletion of the .DS_Store file.

And it seems I was wrong. A user sent me a comic which fails scan due to the .DS_Store __MACOSX folder.

Yeah, that's what I thought. I've had that issue for years on many different readers. Removing those files always worked for me. This is the main reason I only use linux to compile books. OSX Is annoying with that .DS_Store file creation.

The core of the problem is that this folder contains jpg files which are not real jpg.
It should never be included in a comic.
(and the idea of generating files with wrong extensions is beyond me)

I could add a filter to specifically ignore it, but that would be a hack since the problem lies more in MacOS thumbnail system than in Ubooquity itself.

EDIT: the folder I have is in fact "__MACOSX", not .DS_Store. So I have my answer, I don't want to have to guess all the names Apple might think of to generate folders full of fake images.

It'd be nice to find a way have the reader remove those files from the archive completely rather than just ignore them.

Ubooquity never modify you files, ever. That's an fundamental rule that I don't want to change.

But unless I change my mind later, I won't even ignore them. Ignoring these files would require to extract at least partially each image instead of relying on their name as Ubooquity does today.
The comics containing these file are just badly done and must be corrected.

I agree. That's why I use linux to extract, remove, and recompile every one I come across. It's been annoying me for years.

I wonder if it will be feasible to implement some kind of detection/warning system for when those types of files are detected?

It is possible, but it would impact performances and I prefer to use my time to develop more critical features.

I agree that for now I would like to see more core features added to Ubooquity than for it to scan each file for a malformed comic. I'm the one who sent Tom the broke files and he deduced that it was the ridiculous garbage files that OS X adds to the files. I still use my Mac to compile my books, I just do it from the command line now since it doesn't add the hidden files that way.

I've been having this issue for years. It's annoying as sin. I have no idea what apple is thinking with it. I don't mind using osx to read the books but I just don't even bother compiling stuff anymore. I'm a full time arch linux user anyways so I normally do all my work on there anyways so it's a non issue for me. At any rate, I'm glad I could help figure out a solution. :)