managing the space available for books on kobos

[anacreon]

Looking at the library parameters on my Kobo Glo today, there were 389 Mo available from 3232 according to kobo: 1.9 Go occupied by the books, 58 Mo by the 15 installed dictionaries. It didn't add up.

So I scanned it with the Where is it app:
- the capacity is 3.15 go, similar to kobo's 3,2
- .kobo is 374 Mo : 259 sqlite database, 109 dictionaries (twice kobo's 58 Mo for the same 15 dict.)
- .kobo-images 505 Mo
- fonts plus calibre metadata 30 Mo
- the rest calibre book files: I didn't add it up but the difference with the rest is close to kobo's 1.9 Go.

I discovered the compression tool only recently, and I've slowly modified old covers, but 505 Mo for images? I regularly clean the image directory.

The biggest on the kobo, an Atwood book has 4 files: 1081 ko N3-full (the size of the cover in calibre), 650 ko Android aspect, 650 ko library-full, 609 ko library grid, total 3Mo.

I experimented compressing the cover in Calibre to 79 kb then uploading the cover with Kobo utilities: only the 3 smaller files were reduced, the biggest unchanged. How can I get all the files to adjust?


EDIT: for the non French, units will be bits, not "octets", very similar, so read Kb instead of ko, Mb instead of Mo and so on.

[rraod]

I have a Kobo Aura H2O and installed a 16GB microSD card in it. All my books are on the 16GB microSD. I leave the internal space for the database and the dictionaries.

I am happy with this setup.

[davidfor]

Originally Posted by anacreon

Looking at the library parameters on my Kobo Glo today, there were 389 Mo available from 3232 according to kobo: 1.9 Go occupied by the books, 58 Mo by the 15 installed dictionaries. It didn't add up.

So I scanned it with the Where is it app:
- the capacity is 3.15 go, similar to kobo's 3,2
- .kobo is 374 Mo : 259 sqlite database, 109 dictionaries (twice kobo's 58 Mo for the same 15 dict.)
- .kobo-images 505 Mo
- fonts plus calibre metadata 30 Mo
- the rest calibre book files: I didn't add it up but the difference with the rest is close to kobo's 1.9 Go.

I discovered the compression tool only recently, and I've slowly modified old covers, but 505 Mo for images? I regularly clean the image directory.

The biggest on the kobo, an Atwood book has 4 files: 1081 ko N3-full (the size of the cover in calibre), 650 ko Android aspect, 650 ko library-full, 609 ko library grid, total 3Mo.

I experimented compressing the cover in Calibre to 79 kb then uploading the cover with Kobo utilities: only the 3 smaller files were reduced, the biggest unchanged. How can I get all the files to adjust?

In all that, the only thing you have direct control over are the sideloaded books and the fonts. The database is dependent on the number of books on the device plus recommendations and others from Kobo. The dictionaries on how many you install.

The cover images you don't have direct control over. The device either downloads the images (for purchase kepubs and recommendations) or generates them for sideloaded books. For most of the sideloaded books formats, the cover is simply the first page of the book rendered and saved. For sideloaded kepubs, the covers are generated from whatever image in the book is marked as the cover image.

There are three or four sizes generated depending on the firmware version you are looking at. The sizes generated are fixed for the device. The images are generated as needed and stored for later use. You have no control over any part of this. But, you can sideload the images. The KoboTouch driver in calibre has options to generate and sideload all the cover images when the book is sent. The driver should be generating images similar to the firmware.

There are only two ways that I can think of to reduce the size of the images directory:
- Delete the generated images. This is only temporary as they will be regenerated as needed. But, if you keep all your books on the device, you could delete the images for books you have read or are not likely to read in the near future.
- Generate your own images to your own specs. The simplest way to do this would be to run calibre from source and change options used for generating the images. Or you could create a driver subclassed from the KoboTouch driver that does this. Either is easy to do, but I have now idea how much benefit it would be.

You can also do is what rroad suggests: Use an external SD card. The firmware doesn't save generated images for books on the SD card. But, if they are there, they will use them.

Another possibility is to change the internal SD card. People have put 32GB cards in their Glo's so they can store more books. Even a 4GB card will give you a lot more space.

[frostschutz]

You can also try to optimize the database (VACUUM) using any sqlite3 utility... not sure if Kobo firmware ever optimized it (as long as you don't factory reset or switch kobo accounts)

[davidfor]

Originally Posted by frostschutz

You can also try to optimize the database (VACUUM) using any sqlite3 utility... not sure if Kobo firmware ever optimized it (as long as you don't factory reset or switch kobo accounts)

Good point. I think the firmware does this, but, I'm not sure when. It might just be when upgrading the the database version.

And of course, my utilities plugin does have the function to do it as well.

[anacreon]

Originally Posted by davidfor

In all that, the only thing you have direct control over are the sideloaded books and the fonts. The database is dependent on the number of books on the device plus recommendations and others from Kobo. The dictionaries on how many you install.

The cover images you don't have direct control over. The device either downloads the images (for purchase kepubs and recommendations) or generates them for sideloaded books. For most of the sideloaded books formats, the cover is simply the first page of the book rendered and saved. For sideloaded kepubs, the covers are generated from whatever image in the book is marked as the cover image.

There are three or four sizes generated depending on the firmware version you are looking at. The sizes generated are fixed for the device. The images are generated as needed and stored for later use. You have no control over any part of this. But, you can sideload the images. The KoboTouch driver in calibre has options to generate and sideload all the cover images when the book is sent. The driver should be generating images similar to the firmware.

There are only two ways that I can think of to reduce the size of the images directory:
- Delete the generated images. This is only temporary as they will be regenerated as needed. But, if you keep all your books on the device, you could delete the images for books you have read or are not likely to read in the near future.
- Generate your own images to your own specs. The simplest way to do this would be to run calibre from source and change options used for generating the images. Or you could create a driver subclassed from the KoboTouch driver that does this. Either is easy to do, but I have now idea how much benefit it would be.

You can also do is what rroad suggests: Use an external SD card. The firmware doesn't save generated images for books on the SD card. But, if they are there, they will use them.

Another possibility is to change the internal SD card. People have put 32GB cards in their Glo's so they can store more books. Even a 4GB card will give you a lot more space.

Thank you for your explanations. I tried to delete books with big covers, and transferring them again after severely reducing the weight of the cover, with no success whatever. I suppose I'd have to do a hard reset, but can't be bothered. The SD card wouldn't be a solution since I keep the H2o and the Glo HD synchronized and the first has no slot, and I wouldn't be comfortable opening any device to change the SD card and doing all that needs doing (I read the thread about the process a while ago).

I'll have to do what I do with my iPod: once the 56 GB available (from the very expensive 64 GB I bought) are full, I have to delete some anytime I want to add new music. The beauty of the digital age is nothing is lost - I archive books or music on Calibre or iTunes, unlike those paper books I had to give or throw away, or all the vynil records.

@frostschutz: I do regularly compress the database, with very little impact on its size.

[frostschutz]

Originally Posted by anacreon

I wouldn't be comfortable opening any device to change the SD card and doing all that needs doing (I read the thread about the process a while ago).

Can't really help you with opening the device - with the Glo the plastic "notches" of the bezel tend to break when opening it, and the area around the power button needs some extra care... I'm sure you can find something on YouTube that shows how it's done.

As for the process, it's automatic if you use my Magic Memory Upgrade Mod (External Alternative). It copies the OS and all books to the ext. card and all you have to do afterwards is put the ext. card in the int. slot.

You can find the mod here (also has a video):

https://www.mobileread.com/forums/sho...d.php?t=261578

The Kobos come with SanDisk cards that have decent (10-20M/s) read speeds so it's not the cheapest model (but no point in buying the most expensive ones either).

[davidfor]

Originally Posted by anacreon

Thank you for your explanations. I tried to delete books with big covers, and transferring them again after severely reducing the weight of the cover, with no success whatever. I suppose I'd have to do a hard reset, but can't be bothered. The SD card wouldn't be a solution since I keep the H2o and the Glo HD synchronized and the first has no slot, and I wouldn't be comfortable opening any device to change the SD card and doing all that needs doing (I read the thread about the process a while ago).

If your issue is that you want to make more space by resizing the stored cover images, it won't really work. Reducing the size of the covers in the epubs will work to reduce the space taken. But, the cover images are generated by rendering the first page in the book. A simple cover, say text only title and authors name, will probably produce a smaller image, but anything that is an actual image will probably be roughly the same size no matter what.

If you are sending the cover images from calibre, then they are rendered to be the same size that the firmware produces but are done from the cover image in the library. But, for the largest cover image used for the sleep and power off screen, the image won't be upscaled if it is smalller than what the device needs, or at least it isn't if the "Keep aspect ratio" option in the driver is used. That might save space. The smaller versions are always the same created to the size the firmware does.

The only other thing you can do is occasionally delete all the store cover images. The device will regenerate them as needed, but this will at least claim some space for a while. And it will get rid of the largest version until you open the book.

[GeoffR]

If you use Calibre to send the covers there is a 'Send balck and white covers' option in the driver that will convert the cover to greyscale before sending it to the device. I think this makes the filesizes about 10% smaller. (The cover images for books synced from the Kobo cloud are greyscale already.)

Edit: Also be aware that Calibre automatically replaces the cover image inside the ePub with the one you have set as cover in Calibre as a part of updating the metadata when it sends the book to the device. Often these are the same image and so there is no effect, but it means that if you edit the ePub to reduce the size of a large cover image inside the book, it will just be replaced with the original one that was in Calibre when the book is actually sent to the device.

Edit2: There is also a problem with the way Calibre treats books that have PNG covers, it will convert the PNG to JPG when it adds the cover to Calibre, then convert JPG back to PNG to replace the cover in the book when sending the book to the device. This can sometimes result in a large increase in the filesize of the cover inside the book because of the JPG to PNG conversion.