View Single Post
Old 08-11-2013, 10:01 AM   #5
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 11,742
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by PatNY View Post
Good news, Charles ... all is working fine.

I put Calibre in debug mode, and since I was running it for a log, I waited it out this time. The sync did complete. I guess I was just too impatient when first testing.

But it did take almost 9 minutes to finish just the "Waiting for Calibre" stage, during which time Calibre's interface is locked up -- when clicking on the jobs area in the lower right corner, the jobs window does not pop up; the wheel is stuck and not spinning; and the cursor is also stuck on the hourglass. That's why I thought it wasn't working. If the little wheel in Calibre were at least spinning during that time, I would have known the process was progressing normally.
I thought that this might be the case.

What is happening during that time is calibre is recomputing the cover at the requested size. IIRC you have around 1,000 books on your device, so that is around 2 covers/second. That seems slow. I would have expected around 4 covers/second. Perhaps I have the number of books wrong?

In any event, calibre must do that recomputation sometime, so the time must be spent. I am looking at whether I can move it to the device driver so the UI doesn't lock, but that possibly opens another can of worms related to the user deleting and renaming books while the sync is happening. I can see scenarios where the rename might fail if the cover is being computed at the same time the user changes a title or an author.

A second thought I had was to just send the original cover file to CC and avoid the compute, but doing that would a) explode the size of a book in the DB, and b) cost much more in network time. Neither of these are good things.

A third thought was to do (for example) 100 books per connect so that the time is spread out, but then people would need to understand this process. I am sure (!) that we would get no end of bug reports saying that only half the covers were updated.

A fourth thought is to always transfer the large cover even if the user asks to see small ones. This would eliminate cover retransfers at the cost of some space on the device to store the larger thumbs. This is the only option discussed so far that would require a CC change.

Quote:
Subsequent connections as a Wireless Device progress as usual (relatively quickly). It's just when you change the cover size that it takes a long time. That is the first thing I did when I installed the beta; I changed the cover size for the book details page to Large.
Good. That is how it is supposed to behave.
Quote:
Patterned gray or aged gray wood are fine. Both would look great. It is more the overall color that matters to me.

Regardless of the color, the new shelf design looks fantastic. That will be my default view.
OK, so offering a set of "papers" of differing colors would work. What about the shelves? In your mind, would you still see shelves with the books sitting inside the shelf space, or would the books be sitting against the textured background but not "on" a shelf?
chaley is offline   Reply With Quote