[chaley]

Originally Posted by jackie_w

ETA: If known, how about adding the disk space currently used by covers on the last line to give people an idea of the overhead?
e.g. Current value = 320 pixels (nnnMB)

We don't know. It depends on the cover, the compression, and the phase of the moon.

Originally Posted by kaufman

1) Is size in pixel the horizontal or vertical number? Or both? People are going to ask that question, so you might want to tell them up front.

Size of the largest dimension, almost certainly vertical.

2) If the current default is 320, maybe it makes more sense to have only one smaller and two larger. Devices are tending to get bigger and higher resolution, not smaller and lower. How about adding a 640 instead of the 160?

We have had requests from people who use phones to make the images smaller. Doing so will increase metadata sync speed, perhaps substantially, and also increase performance when using the content server. A phone user will gladly trade off speed for image size, assuming they are using small thumbnails.

3) I had a thought about this today. Maybe this should be an option, or maybe it should just be the default. Why don't you just store the book database in the same folder as books? If someone puts their books on an SD card, then the extra space of the larger covers will not have much of an impact even if they have a large library. I checked, and my database is currently 120meg for 4500 books. If it increased to (for example) 360 meg with large covers, I wouldn't care as long as it was on the SD card. Is there any reason not to store the book database with the books? Or perhaps in a folder under the books?

We have thought of this. Our concern is that people will hack on the db or even delete it, then complain that the program doesn't work. Keeping the db hidden ensures that we control it. Of course people with rooted phones can do what they want.

Originally Posted by PatNY

So glad to see we may be getting even more goodies in the next release!

I’m very satisfied with the quality of the covers in CC as is. However, the highest screen resolution I have on my current devices is 256 ppi, and I can easily see needing higher resolution covers when I eventually move to a 300+ ppi device. Even with my current devices, I will definitely opt for the higher res covers and larger thumbnails if those choices are available (so long as they don’t slow down the interface of the program). I don’t mind longer download times whatsoever. It’s a very small price to pay for better quality and/or larger covers.

You were one of those I had in mind when I was noodling about permitting larger covers. Some people like you care a lot, and some people like me don't care at all. I will probably cut the cover size down.

As for the wording, I don’t know if the following is any improvement, but it is a tad shorter:

I like that. Taking kaufman's comment into consideration, I will make it

Choose the maximum resolution of covers imported from Calibre. More pixels give better images but increase download times and storage requirements. Changing the value causes all book metadata to download on the next wireless connect.

I added "maximum" in hopes that it says that a dimension can be less than that. I removed the "default" because the user will see that number as the "current value".

Note that if the cover in calibre is smaller than the requested resolution, that cover will be transferred as is.