Book covers not showing

[jlynton]

Since fw 2.5.1 (I am now using 2.5.2 and calibre 0.9.31) none of the books that I load onto my glo (main memory) show their covers, either on the home page, book index or sleep cover. Books that I loaded previously all show their covers.

Is there a limit to the number of covers that the glo will store (I have approx. 4000 books on the device)?

[davidfor]

While there isn't a limit on the books, there is a limit on the covers.

The user partition of the device is formatted as FAT32. This allows 64K files per directory. Or, more correctly, has 64K directory entries per directory. For the traditional short file names, that is 64K files. But, long files use multiple directory entries per file. So for a directory with files that have long names, the maximum number of files is a lot less.

The image file names used for sideloaded books is basically the full path for the file plus some extra characters. Because of that, it isn't hard to have an image file name that is 100 characters long. The device also creates three cover images per book. From previous discussions, this problem tends to start when you have 2000 or more books.

There are some things you can do to alleviate this, but there is no permanent fix. The simplest thing is to shorten the file paths used for your books. I use the default calibre save template of "{author_sort}/{title} - {authors}". If I dropped the {author} from that, it would shorten the name a lot.

In a discussion on this a while ago, I posted a set of suggestions of different ways to handle this. Except for shortening the file paths used, they all needed some changes made to the database on the device for each book. Unfortunately, I can't find that thread right now.

Last thing, the covers for books on the main memory and the SD card are handled differently and has changed with the firmware. At the moment, the covers for books on the SD card don't get saved, so they won't have this problem.

[jlynton]

Thank you very much for your detailed answer, I think that I have found the thread that you refer to - https://www.mobileread.com/forums/sho...d.php?t=207932 - which I will read through properly, and hopefully find a solution within.

[jlynton]

Having read through that post, I gather that by changing my calibre save template from "{author_sort[0]}/{author_sort}/{title}/{authors} - {title}" to "{author_sort[0]}/{author_sort}/{title}" would make a considerable difference.

Alternatively, if I erase my books from the main memory, and load them on to and SD card using calibre ("{author_sort[0]}/{author_sort}/{title}/{authors} - {title}"), then there would be effectively no limit to the number of books that would display their cover correctly.

Am I on the right track?

[RZetlin]

The book cover does it show up as a tiny dot on the Kobo Reader?

If it is, it is the book cover in the epub.

Use Sigil to open the book, Go to Tools->Add Cover and select the cover.

Reload the book back using Calibre.

[jlynton]

Originally Posted by RZetlin

The book cover show up as a tiny dot on the Kobo Reader?

If it is, it is the book cover in the epub.

Use Sigil to open the book, Go to Tools->Add Cover and select the cover.

Reload the book back using Calibre.

Thanks, but that is not the problem.

[GeoffR]

Originally Posted by jlynton

Having read through that post, I gather that by changing my calibre save template from "{author_sort[0]}/{author_sort}/{title}/{authors} - {title}" to "{author_sort[0]}/{author_sort}/{title}" would make a considerable difference.

Your original template has the title and authors included twice in the pathname, that is even longer than Calibre's default template, so it should help a lot to only include them once.

If you used only the surname of the first author that could save even more space, especially if you have lots of books with multiple authors. You could do that by replacing {author_sort} with {author_sort:list_item(0,\,)} in the template.

Alternatively, if I erase my books from the main memory, and load them on to and SD card using calibre ("{author_sort[0]}/{author_sort}/{title}/{authors} - {title}"), then there would be effectively no limit to the number of books that would display their cover correctly.

I think that is correct, at least for the current 2.5.2 or previous 2.4.0 and earlier firmware (not sure about 2.5.0/2.5.1). But it would mean that once you ran out of directory space, any new books would have their covers generated from the first page of the book each time they are needed, which would slow down browsing of your library listings, use more battery power, and the covers would not look as good as the ones sent by Calibre (covers that were not 3:4 would be shown with white bars at the edges).

[jlynton]

Many thanks for your clarification Geoff

[davidfor]

As GeoffR mentioned, 2.4.0 and 2.5.2 don't save the cover images for books on the SD card. But, for 2.5.2, I believe this is a bug. Saving the images started with 2.5.0 and was in 2.5.1, but both these generated lower quality covers than they did for the books in the main memory.

With 2.5.2. the image seem OK, but the sleep/power off cover is a text only cover that shows the title and type of the book. It only happens for books on the SD card. This is definitely a bug and I know Kobo have looked at it. Not saving the cover images might be deliberate, but if the image files exist, they are used. For that reason I think it is a bug as well.

The main reason to mention this is that using the SD card to avoid the cover issues, is probably not going to work long term. I hope that both these problems will be fixed in the firmware version.

Right now, the simplest workaround is shortening the length of the path used for the books and hence the image file names. But, I don't really know how much of a benefit that will be.

[jlynton]

Thanks David, I will do as you suggest.

[edit]I shortened the file path from "{author_sort[0]}/{author_sort}/{title}/{authors} - {title}" to "{author_sort[0]}/{author_sort}/{title}", then removed all the books from the device. After re-loading them the problem still exists. The .kobo/images directory maxes out at 8371 files (about the same as before, so shortening the route does not seem to have helped).[/edit]