Thread: [Device Plugin] Kobo Touch Extended Driver
View Single Post
Old 09-16-2015, 06:34 AM   #1377
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by milady133 View Post
Then I can't think a reason why a book doesn't show a cover the first time you send it to the device and you get the cover when you delete it and send it the second time, unless it isn't the Kobo reader the one extracting the cover, but Calibre updating the cover in the Kobo database, when the entry for the book is already created, something similar to what happens with series information, only it isn't updated on connection but on resending the book.
Kobo can be a bit tricky to interpret cover metadata. A lot of reading programs use the opf:cover tag (sorry, I'm not in front of my computer so I don't know the exact syntax), but I don't know why, with some books, I need to add some extra piece in the files declaration part of the opf file to get the book cover identified. And that extra piece throws a warning message when I validate the epub with Sigil, although it causes no problems, at least with the reading programmes I have tried: Adobe, Mantano, and Kobo, of course. Sorry I can't give more details on the exact properties I'm using, I found them in this forum, but I need to access my computer to get them.
For kepubs, the cover is identified in the manifest of the OPF. The cover will be an entry with properties set to "cover-image". If there isn't one, then no cover will be used. When generating the kepub, the driver tries to work out which image is the cover and adds the property. If it can't do this, then the title and format cover will be used. For epubs, the cover is simply the first page of the book.

I have seen the problem reported for both epubs and kepubs. I'm pretty sure it isn't the books as it doesn't happen for all the sizes. If all the sizes end up as the title/format cover, then it probably is something wrong in the book.

Plus, it seems to happen after the initial generation of the cover. By that, I mean that the cover will get displayed and a couple of days later, I'll notice the cover has gone missing. With this, a possibility is that the generated cover was not written to the disk properly but it is in the memory cache. When the cache is cleared and the image file is reread, it doesn't work and the title/format cover is used. This definitely happened with firmware 3.16.10 and 3.17.0, but that was caused by the sickel reboots. With that, I would find a zero size file for the generated cover. For each of these, the title/format cover would be used. But, this isn't happening with 3.17.3, so the cause is something else.
davidfor is offline   Reply With Quote