Touch Cover image frustrations

[scoobertron]

Apologies, as this is a bit more of a rant than a question, though there is a question at the end.

I use my kobo purely for reading epubs, and have been a bit frustrated by the bug whereby any the cover image for the book is squeezed horizontally and has two white margins added to it. I even tried stretching the covers horizontally in the epub so that when they get squeezed they should revert to normal, but that didn't work.

In the end, I wrote a script that generated covers for each book, and replaced them in the kobo image directory so the kobo wouldn't generate new covers and just use the ones I created. All was well, until my library grew to around 3000 books. Now, when I create all the files that are needed (4 for each book, I believe), the device runs out of inodes. This means that I am back with ugly squeezed covers, despite the fact that my library is under 1GB (with both books and covers).

Is there another fix for this that I am not recognising? For example, is it possible to reformat the kobo drive to ext3 so I can hardlink all the cover files to one image, thus saving inodes? Or does anyone know if this is even on kobo's radar to fix.

[davidfor]

Originally Posted by scoobertron

I use my kobo purely for reading epubs, and have been a bit frustrated by the bug whereby any the cover image for the book is squeezed horizontally and has two white margins added to it. I even tried stretching the covers horizontally in the epub so that when they get squeezed they should revert to normal, but that didn't work.

You must be doing something wrong. The Kobo Touch takes the first page of the book and uses that as the cover. If there are white bars in the cover image used, then they are there in the first page of the epub as well. If you have an example that doesn't do this, post it, or at least the code for the first page and a cover so we can see what is wrong.

In the end, I wrote a script that generated covers for each book, and replaced them in the kobo image directory so the kobo wouldn't generate new covers and just use the ones I created. All was well, until my library grew to around 3000 books. Now, when I create all the files that are needed (4 for each book, I believe), the device runs out of inodes. This means that I am back with ugly squeezed covers, despite the fact that my library is under 1GB (with both books and covers).

That is only 12000 files. The maximum for a FAT32 directory is 65,534. Your not close, so running out of inodes doesn't make sense.

As to the files you are generating, what firmware version are you using? Pre 2.0.0 generated four or five cover sizes. 2.0.0 used two or three depending on some options. 2.1.4 and later uses up to three:
- N3_FULL is used for the Home screen and screensaver.
- N3_LIBRARY_GRID is used for the library lists
- N3_LIBRARY_FULL is used for the details screen

There is no way to open a book without having the first two. The last only gets generated when you visit the details page of a book. If you don't do that, you don't need to create it.

If you use calibre, the Kobo Touch driver has options to send the cover images as well. It will stretch the covers. But, it will send all three.

Is there another fix for this that I am not recognising? For example, is it possible to reformat the kobo drive to ext3 so I can hardlink all the cover files to one image, thus saving inodes? Or does anyone know if this is even on kobo's radar to fix.

The database on the Touch has the name of the image used for each book. If you look at the content table, for rows with ContentType=6, the column you want is "ImageID". You could change this for all the books to single image. There is a bit of discussion on this table in https://www.mobileread.com/forums/sho...d.php?t=194871.

I don't know if using ext3 is possible. I am sure I have seen a post somewhere here about someone trying, but I don't remember if they were successful.

I don't know if Kobo have it on their bug list as this is the first time I have seen this reported. Or at least the inodes part. The cover image size is not a bug but working as designed. Personally, I'd be unhappy if they changed it.

[PeterT]

I do recall from earlier threads people running into a limit of how many images were supported on the Touch; this was however from a pre 2.0 firmware if I remember correctly.

I wonder how this might have affected the person who had wanted to load his 30000 books onto an SD card before heading off to Thailand I think it was...

I also wonder whether the Kobo would be able to handle the images in different directories? Maybe a simple perl (or python) script that would move images to a sub-directory of .kobo/images and update the ImageID column for each book to add in that sub directory. I'll probably experiment this weekend to see what happens.....

[scoobertron]

Originally Posted by davidfor

You must be doing something wrong. The Kobo Touch takes the first page of the book and uses that as the cover. If there are white bars in the cover image used, then they are there in the first page of the epub as well. If you have an example that doesn't do this, post it, or at least the code for the first page and a cover so we can see what is wrong.

I have attached one of the epubs. The cover image is one I have generated to replace the original, which was also 600x800.

Originally Posted by davidfor

That is only 12000 files. The maximum for a FAT32 directory is 65,534. Your not close, so running out of inodes doesn't make sense.

Yeah, something funny is going on. When I was copying the image files I had made, I was getting errors that there was no disk space, even though there was plenty. Using df -i showed 0 free inodes, which made me think that I had run out, but looking again it shows 0% used, so I am wondering if the filesystem is borked.

Originally Posted by davidfor

As to the files you are generating, what firmware version are you using? ... The cover image size is not a bug but working as designed. Personally, I'd be unhappy if they changed it.

I am using 2.1.5. The reason I was thinking it is a bug is that the image is already the right size to fit the screen, so adding the margins changes the aspect ratio, which distorts the text.

[scoobertron]

Originally Posted by PeterT

I do recall from earlier threads people running into a limit of how many images were supported on the Touch; this was however from a pre 2.0 firmware if I remember correctly.

This seems to be the issue. I found this old thread http://tinyurl.com/8u5ljt5
which talks about the problem a bit more. So I can copy images into the folder till I get a disk full error, and then copy more into any other folder on the device. It even seems to be around the same number of images (7500 or so).

Annoyingly, this means it seems I have a choice between not having my library on the touch, even though it has loads of space left, or putting up with the kobo adding margins to all of my covers.

[RG1]

Have changed the cover page of your book. No white margins available any more. You don't need to copy cover and library images to your kobo for this book. The kobo will generate all images without margins.

[thp1017]

I've been having issues with new books as well - I think for all of the books I've copied over to the onboard storage since updating to 2.1.5 (previously on 1.9.14), the covers just aren't getting generated.

All are run through calibre's command line tools (ebook-convert), so I know that the cover is on the first page... and the ImageId column in the DB is set up correctly.

Any bright ideas?

[davidfor]

Originally Posted by scoobertron

I have attached one of the epubs. The cover image is one I have generated to replace the original, which was also 600x800.

RG1 has made a change to the book that fills the first page properly and hence the cover images have no borders. That is the change I would have made.

Yeah, something funny is going on. When I was copying the image files I had made, I was getting errors that there was no disk space, even though there was plenty. Using df -i showed 0 free inodes, which made me think that I had run out, but looking again it shows 0% used, so I am wondering if the filesystem is borked.

I checked the details of the max files, and there is a comment about the number being reduced if long file names are used. I don't know by how much, but I wouldn't have thought by that much.

My Linux skills are enough to know what "df" is, but not to go that much further. But, is an inode count valid for a FAT32 file system? If it wasn't, that would explain the strange numbers.

One other thing is path length. I have had a couple of strange things happen with the image files because of very long names. Because the device uses the full path of the book plus a suffix for the image file name and then puts it into a subdirectory, the path can get very long. It is actually possible to get the device to create an image so that the path is longer than 260 character when looked at under Windows. You can see the file, but not do anything with it. And I have also put a book on so that some of the cover images weren't generated because of the path length being exceeded.

If you are hitting this, it shouldn't give a disk full error. But, it is also possible that something is misinterpreting the error.

I am using 2.1.5. The reason I was thinking it is a bug is that the image is already the right size to fit the screen, so adding the margins changes the aspect ratio, which distorts the text.

I can see way you thought that. But, the thing to remember that the Kobo devices don't use the image file in the epub, but the first page of the book. But an option to stretch this when generating the cover image would be very popular.

[davidfor]

Originally Posted by thp1017

I've been having issues with new books as well - I think for all of the books I've copied over to the onboard storage since updating to 2.1.5 (previously on 1.9.14), the covers just aren't getting generated.

All are run through calibre's command line tools (ebook-convert), so I know that the cover is on the first page... and the ImageId column in the DB is set up correctly.

Any bright ideas?

My ideas, bright or not, are:

- What are you actually seeing? A blank rectangle or a text cover with the title and type of book?

- What book type? TXT, RTF and one other type that escapes me right now, never use a cover image. These always just show the title and type.

- Path length as explained above. If you use calibre and the new driver to send the books to the device, it keeps the path length for the books short enough not to hit problems with the path length for other files.

- How many books on the device? Maybe you are hitting the limit that scoobertron seems to be hitting.

- Have you checked the images directory for the image file? I was doing a lot of playing last night because of this thread and another. I had a couple of books come up with blank covers. When I looked at the images directory, the cover images where there. But they where blank. I deleted them and they were generated correctly after the disconnect.

[thp1017]

Originally Posted by davidfor

- What are you actually seeing? A blank rectangle or a text cover with the title and type of book?
- What book type? TXT, RTF and one other type that escapes me right now, never use a cover image. These always just show the title and type.

It is the kobo generated thing, with "Book Title [epub]" stamped on it. Definitely all epubs.

- Path length as explained above. If you use calibre and the new driver to send the books to the device, it keeps the path length for the books short enough not to hit problems with the path length for other files.
- How many books on the device? Maybe you are hitting the limit that scoobertron seems to be hitting.

Paths are same as before - in one case, the book in question is just the next in a series, so instead of 'Saganami 02: Storm from the Shadows' it is 'Saganami 03: Shadow of Freedom'. First one worked last year when I got it, this one didn't Also I think all are shorter paths than what worked in the past.
I actually only use calibre to convert and clean up the books, I don't bother with the GUI or the kobo driver, never have. I just use rsync to copy new files over. Only at ~850 books at this point, so that shouldn't be a problem.

- Have you checked the images directory for the image file? I was doing a lot of playing last night because of this thread and another. I had a couple of books come up with blank covers. When I looked at the images directory, the cover images where there. But they where blank. I deleted them and they were generated correctly after the disconnect.

Yeah, took a quick look at that, and they aren't there. I'd also at one point tried deleting the entries from DB and letting it re-process them, but that isn't fixing it.

Don't get me wrong, this isn't exactly the end of the world, but it'd be nice to know what the heck is going on Thanks for your help!

[scoobertron]

Originally Posted by RG1

Have changed the cover page of your book. No white margins available any more. You don't need to copy cover and library images to your kobo for this book. The kobo will generate all images without margins.

Thanks RG1. However, it wasn't just the one, so I will need to process my entire library. This is possible through Calibre, which is going to be quite time-consuming for all my books, and I am going to need to pick each cover by hand if I want to use my simple generated covers (for 3000+ books).

Originally Posted by davidfor

I can see way you thought that. But, the thing to remember that the Kobo devices don't use the image file in the epub, but the first page of the book. But an option to stretch this when generating the cover image would be very popular.

This gives me something I can work with if I don't want to go the Calibre route and want to script something myself. But I don't quite understand what is actually causing the margins to be added. This has happened with every epub, from various sources. Right now I am predominantly using epubs from feedbooks.com, whose formatting is generally very good. If the kobo is just reading the first page, then it would imply that feedbooks (and the other publishers) are setting up their first page to squeeze the cover image and add margins, which seems odd.

And yeah, I think the inode thing was a complete red herring. I don't quite know why I was thinking that.

[vice-versa]

At the begining with my Glo, it generated some "auto-covers" with the title and the type of file (though my books had images on the first pages) and then, without knowing why, the device showed them... Never understood what happened, but it works, and I don't try to understand why, just happy with it. I hope your concern will find a solution

[davidfor]

Originally Posted by scoobertron

Thanks RG1. However, it wasn't just the one, so I will need to process my entire library. This is possible through Calibre, which is going to be quite time-consuming for all my books, and I am going to need to pick each cover by hand if I want to use my simple generated covers (for 3000+ books).

Fixing this for 3000 books is going to painful.

This gives me something I can work with if I don't want to go the Calibre route and want to script something myself. But I don't quite understand what is actually causing the margins to be added. This has happened with every epub, from various sources. Right now I am predominantly using epubs from feedbooks.com, whose formatting is generally very good. If the kobo is just reading the first page, then it would imply that feedbooks (and the other publishers) are setting up their first page to squeeze the cover image and add margins, which seems odd.

It depends on the image they are using on the cover. Personally, quite a few of my ebooks are replacing paperbacks. So, I find the a scan of the cover. These have a different aspect ratio to the ereaders screen. As I don't want then stretched out of shape, I get space down the sides on the front page and hence the cover images.

Even if they are using images that are the right ratio, they might still put a margin in. The designer of the book might have thought a margin was a good idea. Without seeing an example, it's hard to know what's going on.

[RG1]

During cover image generation the margins you have set in preferences will be added. I have used a class for body to get around this. You can prevent kobos own margins in generated images if you set the preference for margins to zero before adding a book. This will work for books stored in main memory only. (The images for books stored on sd card are generated on-the-fly and are not persistent.)

[ottdmk]

I've had the covers for two side-loaded (in main memory) books disappear. One epub and one pdf. Weird.