Cover View Browsing crashes Paperwhite

[rashkae]

One problem I have observed with every Paperwhite, (1, 2 and 3.) and many firmware versions, including the latest, is that browsing my library in "Grid View" will eventually cause the Paperwhite to self-restart.

This can be reproduced once I have about 500 books on the device, by browsing the books. Usually, if the Paperwhite is recently restarted, I can make it through the entire library once, but trying to do so a second time, or to page backwards several pages, it will crash and re-start.

All of my books are sideloaded with Calibre, so the cover thumbnails are Calibre generated. I guess my question is, does this same crash happen with the Amazon supplied thumbnails? It seems odd to me this bug would have existed for so long and never been corrected if it also affects Amazon loaded books.

[tomsem]

It's quite possible the algorithm used to load in cover images for display has issues once you exceed some numerical threshold (whether the images are from Amazon or anywhere else). Kindle system resources are relatively limited, so there are always trade-offs between performance and stability.

Also possible that there are certain calibre-generated cover images that the thumbnail algorithm has problems with. I've seen a number of discussions where it seemed they had to be of specific dimensions, or thumbnails would not get generated and that sort of thing.

But knowing there is a problem doesn't necessarily give way to some simple solution. It could take considerable effort to isolate the origin of the problem. And you could be getting some reading in instead.

If you were to raise the issue with the right people in Amazon Customer Support, they could pull logs off of your Kindle and probably ascertain something about why it is happening. That doesn't necessarily mean a solution would be forthcoming from their side, of course, but in my experience they do try. The calibre forums here might also be a good place to ask about this.

Short of that, the advice I would take away would be to use Cover View more sparingly. "Doctor, it hurts when I do THIS" "Then don't do THAT".

In general, I almost always find it a lot quicker to use Search to find things in my library. A few keystrokes is usually sufficient.

[Axanar]

Originally Posted by rashkae

One problem [...] is that browsing my library in "Grid View" will eventually cause the Paperwhite to self-restart.

Confirmed with my Paperwhite 2 (6 Gen) and 5.7.2 Update. Exactly this happened yesterday to me.

[rashkae]

Originally Posted by Axanar

Confirmed with my Paperwhite 2 (6 Gen) and 5.7.2 Update. Exactly this happened yesterday to me.

Are your books sideloaded or sent from Amazon? (or a mix.). I'm trying to figure out if Calibre sideloaded thumbnails are what's triggering this.

[Axanar]

Originally Posted by rashkae

(or a mix.)

I have a mixture of both. My Library contains around 40 books whith 2/3 of it downloaded from Amazon. Though I really doubt that this is Calibres fault and I would like to explain this:

The Kindle underlaying system is Linux if I recall correctly. The Kernel differs between Userland and Kernel processes. If a Userland application crashes (by any means) then this should never ever cause a full system crash (including reboot).

Therefore the issue might be related elsewhere and could be anything. Starting from experimental gcc compiler flags (or maybe they use clang). The Kernel as well as libraries (like libpng or some xlib libraries) could be compiled and generate badly optimized code (cpu mnemonic) and so on. Of course it could also be Kindle's proprietary Startpage and Booklauncher. Though even if this has issues, it shouldn't cause the Kernel to completely reboot or reset.

Anyways I don't know much about how the Kindle stuff really works, therefore I am more speculating here.

The explaination about "big" covers might make sense. Amazon usually has 300x500 pixels or something. And if you use covers with bigger sizes then it might cause crashes because the covers must be load into memory. And if there is not enough ram... Well then it might crash.

But then. All books sideloaded with Calibre (on my system) has covers from amazon only! so the covers should match the requirements.

But! if you have 500 books and eveyone of them is thumbnailed on Kindle launch (e.g. all covers loaded) then you might end up with this. Example!

300x500x32 (300 pixel width, 500 pixel height, 32bit png)

= 4.8mb per cover

If you have 500 books and all of them load on the go (rather than on demand) then you might end up with this:

500 x 4.8mb = 2.4gb of ram

That's theoretically now. If you go into the thumbnails folder of your Kindle, then you usually end up seeing gray-scaled png or jpg files. Maybe 16 colors ? (8 bit). This could be calculated like this:

300x500x8 = 1.2mb per cover

500 x 1.2mb = 600mb of ram

In case the covers are loaded on demand (e.g. loaded when swiping) and removed once the next page got loaded. Then it may be that the covers are not memory free'd correctly. E.g. memory leaks.

Now if we continue:

I saw that the entire kindle shop seems to be based upon index.html page containing a shitload of javascript magic. It could be that the underlaying javascript engine - in case it's used the same way for the "grid books library" - may suffer from heavy memory leaks. This of course (if you swipe through a library full with 500 books) end up in a shitload of memory leaks - which causes the system to ... yea .... to crash!

[Axanar]

I just verified it again.

The covers downloaded from Amazon (For Kindle eInk) are usually between 200-220 width and 300-330 height grayscale (8bit).

Using the same maths will result in around 500kb ram for one cover displayed. For 500 covers you might end up in using 256mb of ram (in case all covers are loaded once rather than 6 covers on demand per slide).

It might make sense (and I keep a mental note for myself here). To scale all calibre covers to around that size + turning them into 8 bit grayscale. To avoid possible crashes.

Maybe calibre has an option to scale covers before side-loading them to the Kindle ?

[HarryT]

Originally Posted by Axanar

I just verified it again.

The covers downloaded from Amazon (For Kindle eInk) are usually between 200-220 width and 300-330 height grayscale (8bit).

Using the same maths will result in around 500kb ram for one cover displayed. For 500 covers you might end up in using 256mb of ram (in case all covers are loaded once rather than 6 covers on demand per slide).

I very much doubt that the library loads all covers in your library into RAM; it would be far more sensible to load them for each page as it's displayed.

[rashkae]

This is purely speculation on my part, but I suspect there's a memory leak in the cover thumbnail view, and the 'crashes' are OOM process terminations.

[eschwartz]

Question is, if it is really restarting.

I assume you just saw the boy-under-the-tree, with the progress bar.



If you use Menu ==> Settings ==> Menu ==> Restart, you will notice it takes a little while to start up.
After a while, the progress bar starts loading, and then it stutters halfway through. (The stutter is when the java framework takes over drawing the screen.)

If you restart the framework from the command line (or during the MrPI hack) you will go back to that screen, but it goes much faster (i.e. it starts loading almost immediately).

I've had my KT crash on me (running skipstone, some websites are complex and crash everything somehow). It has the same effect of restarting the framework, not a complete reboot.



So, is it rebooting, or just restarting the framework?

[rashkae]

Originally Posted by eschwartz

Question is, if it is really restarting.

I assume you just saw the boy-under-the-tree, with the progress bar.



If you use Menu ==> Settings ==> Menu ==> Restart, you will notice it takes a little while to start up.
After a while, the progress bar starts loading, and then it stutters halfway through. (The stutter is when the java framework takes over drawing the screen.)

If you restart the framework from the command line (or during the MrPI hack) you will go back to that screen, but it goes much faster (i.e. it starts loading almost immediately).

I've had my KT crash on me (running skipstone, some websites are complex and crash everything somehow). It has the same effect of restarting the framework, not a complete reboot.



So, is it rebooting, or just restarting the framework?

Just re-starting the framework.

Sometimes that's ok. Other times, even after the framework has restarted, the Kindle remains slow and relatively unresponsive until a proper restart is done.

[Katsunami]

Originally Posted by Axanar

But! if you have 500 books and eveyone of them is thumbnailed on Kindle launch (e.g. all covers loaded) then you might end up with this. Example!

300x500x32 (300 pixel width, 500 pixel height, 32bit png)

= 4.8mb per cover

How do you end up with this number?

32 bits is 4 bytes. 300x500 is 150.000 pixels. Total memory consumption would be 600.000 bytes, or roughly 586 KB.

[Axanar]

Originally Posted by Katsunami

How do you end up with this number?

Damn! Yes you are right. I totally forgot, dividing my calculation by 8 (8bit => 1byte). Nice catch!

[Katsunami]

Originally Posted by Axanar

Damn! Yes you are right. I totally forgot, dividing my calculation by 8 (8bit => 1byte). Nice catch!

Forgot to divide by 8. I see it now. Should have seen it myself