Comment 2 for bug 1543524

Unfortunately, that is a foible of the Kobo firmware.

When you sideload a book, it is processed and details added to the internal database. The firmware then generates covers images as they are needed. And if the book is on the main memory of the device, the cover images are stored in the memory.

If you manually sideload replace an epub, when the firmware checks for new books, unless it has exactly the same files size as in the database, all the current details of the book in the database and the cover images are removed. This means the current reading status, any bookmarks and collections the book is on.

Because of this, when a book is resent, the driver removes the cover images and updates the file size in the database.

This all works except for one problem. There's a memory cache of cover images. The firmware keeps a few cover images in memory. When the cover image files are removed or updated by the driver, the copy in the memory cache isn't removed. This means the old cover can still be displayed for a while. The new cover image is only regenerated if the cover image is removed from the cache. That either means enough other books are opened to push the replaced books cover out of the cache, or the device is restarted.

The exact behaviour has changed with different firmware releases, but the basics are the same. The main change is exactly when cover images are generated and how many are in the cache. And I don't know exactly how many are in cache. I'm not sure, but the difference between the Glo and the Glo HD is probably down to RAM size. The Glo has 256MB of RAM and the Glo HD has 512MB. The firmware probably allocates a large cache size on the Glo HD, so more cover images are in memory and that should improve speed in the library.

The test for this is simple: restart the Glo HD and see if the new covers are displayed.