KUAL: Kindle Unified Application Launcher (v2.7)

[Ffan]

Kindle Paperwhite 1, FW 5.3.9

It contains about 430 books right now (but since I first noticed that problem a couple of weeks back I didn't add that many books maybe 2 dozen or so.

Not sure what the indexer actually is/or how I would know. If you could elaborate I might be able to give you some information on it.

I have set the screensaver mod to show the cover of the last read book. Works fine.

--------

I thought so myself, at least not the degree it is affected.
I know of course that current batteries degrade over the time, but normally I would have to charge it (on average) like twice a week. Now I basically started to charge it every night since if I don't chances are pretty good that the 2nd day of reading ends in a warning message due to low battery charge. I'm pretty sure this started happening a couple weeks back right around the time I jb'ed it. It doesn't feel like 'natural' degradation, far too rapid a change I think.

[NiLuJe]

At this rate, that does indeed look like the indexer/catalog looping like crazy on one/multiple books.

The usual, 'dumb' way to check is to search for a nonsense string from the Homepage, and see if anything shows up as 'Currently Indexing' (or whatever the header is actually called, can't remember OTOH).

The sensible way to check is to look at the output of htop, and check if the indexing thread is being silly. Checking the logs (showlog in a shell, ;dm in the search bar) is also generally a good idea.

As for the amount of books, yeah, I wouldn't go over 500 items, 1K at most, besides being a nightmare to navigate, it pretty much destroys the Homepage perf, and makes the boot/resume process churn forever when it checks the integrity of the catalog. (On the bright side: FW 5.x does much better in that respect than previous iterations of the software, and the better CPU of the PW2 is a tremendous help too. My old K3 w/ ~1K items is amazingly funny to watch over htop as it boots/wakes up...).

[Ffan]

@NiLuJe Yeah that is pretty much what I thought in regards to stuff I got installed.
I'm not sure what "TL;DR" means ? I'm not using any cloud service, actually most of the time I'm in flight mode (which I hadn't done previously but I thought it might help battery life at least some).

In regards to the JBPatch entry, thanks to what you just said, I went to look at every menu.json file in the editor and the one for starting the collections manager contained a second "item" ... the JBPatch. That'S fixed then thanks :P (Should have thought about that right away)

[NiLuJe]

TL;DR: Too Long; Didn't Read .

I personally use it when I realise most of what I just wrote is wall of text ranting or rambling, when the short answer was only a couple of words long .

And yeah, you don't have Cloud Collections on 5.3.9 .

[Ffan]

"TL;DR: Too Long, Didn't Read" right right right ^^ I was too focused on Kindle related terms and abbrevations ....

"The usual, 'dumb' way to check is to search for a nonsense string from the Homepage, and see if anything shows up as 'Currently Indexing' (or whatever the header is actually called, can't remember OTOH)."

So I just entered some gibberish into the search, all I can see happening is the little "ring"-thingy in the top left corner spinning, nothing else really.

"The sensible way to check is to look at the output of htop, and check if the indexing thread is being silly. Checking the logs (showlog in a shell, ;dm in the search bar) is also generally a good idea."

And this sounds good but kinda stumps me. htop I heard before in regards to linux other than that I'm drawing a bit blank. Could you give me something a little more "step-by-step"-ish or at least point me in the direction to some basic instructions for this ? :P

[knc1]

Originally Posted by Ffan

So I just entered some gibberish into the search, all I can see happening is the little "ring"-thingy in the top left corner spinning, nothing else really.

Not the expected behavior.
But does indicate that the indexer is somehow "lost" in its job and that the problem is of the same age of the book(s) you added that is causing it to act up.

(Lab126's indexer program is worse than a spoiled child as far as behavior is concerned.)

Originally Posted by Ffan

"The sensible way to check is to look at the output of htop, and check if the indexing thread is being silly. Checking the logs (showlog in a shell, ;dm in the search bar) is also generally a good idea."

And this sounds good but kinda stumps me. htop I heard before in regards to linux other than that I'm drawing a bit blank. Could you give me something a little more "step-by-step"-ish or at least point me in the direction to some basic instructions for this ? :P

One way:
With command line access, just run the program.
Usually that involves using either ssh or telnet over the USB cable -
both are included in the USBnet package.

Another way:
I don't recall that we have a KUAL button to capture the output of (h)top -bn1 as a "document".
But the Kindle Menu application will display a "task list" -
which may be enough to confirm it is the indexer gone dumb that is running down your battery.

- - - -

Strange Linux (or any *nix) terms encountered - -
All (should) have a related manual page.
Embedded systems (like the Kindles) do not have the manual documents installed.
AH -
But all the web search engines recognize the usage of the man(ual) command:
via google:
man htop
gives as first hit: http://linux.die.net/man/1/htop
and other interesting hits, such as:
http://mylinuxbook.com/htop-interact...ocess-monitor/

- - - -

Student assignment:
man ssh
man telnet

[NiLuJe]

Yup, as knc1 said, that would imply installing USBNetwork .

As for the search bar thing, just enter ;dm in the search bar from the Homescreen, it'll dump the logs in a txt file in the documents folder. In that case, that might be overkill/not very helpful. Clearly, it would be much clearer/simple to look at htop .

[Ffan]

Alright, so I deleted a bunch of books it didn't need anyway. Kinda hat to restart the Kindle since he was unresponsive to say the least after that. Anyways the ;dm in searchbar command worked this time around. So this left me with four files full of "information". I not sure what I am looking for. The one file not to big I attached. Of course I can upload the other 3 somewhere else if someone wants to take a look.

Anyways I'm trying my hand at the usbnetworking right now.

Edit:
-------------
Alright made it to htop. I'm not seeing anything "fishy". This is what I get so far:

[NiLuJe]

Ha, forgot that FW 5.x splits the dm dumps, and this a case where size does matter . Indeed, the largest one is the most interesting ^^.

As for htop, I'd recommend ditching telnet and using a real SSH client, because right now it's pretty much mangling htop's output, so I can't quite get what I'd like out of that screenshot, but what I can see of the CPU bar would imply that's it's @ 100%, and the loadvg supports that theory... (a nearly neat 1, meaning an average of 1 process/thread is constantly scheduled as running. For ref, the first Kindle I grabbed and plugged is idling at 0.05 w/ htop over SSH)

So, yep, a good look at htop in a proper terminal to confirm, but it does seem like *something* making the CPU busy...

On a sidenote: the forum supports image attachment, you don't have to use a 3rd-party service .

[knc1]

I see dropbear running in the first image, so may be ssh (since we can't see all the processes) in use, not telnet.

All of those cvm-thread pool threads with high cpu percentage is unusual (and the cause of that is the cause of the high cpu usage).

This will be a 2.6.x series kernel -
So the "load" numbers is just a count of the tasks waiting to run on the run queue each time the scheduler hits the inner re-schedule code.

And "normal" operation is way less than "1.0" - way, way less.
(I.E: Mostly, there is nothing to do (on the cpu's time scale of events) - resulting in a low "load number".)

ah - "cvm" - "Kindle speak" for the Java virtual machine.

We (the members at this forum) do not write much Java (Kindlets) - so it is probably something lab126 wrote.

[[ Whoot! 5858 - I may retire at 6,000 ]]

[NiLuJe]

@knc1: The sshd (dropbear indeed by default) doesn't get killed just because you connect over telnet . I was referring to his choice of client terminal (cf. the window title) .

As for the cvm threads, if you were thinking of the 25.8, that's the MEM% column, unfortunately, and that looks okay .

But yeah, we agree that the load implies something is indeed looping, I just can't quite see what with the way the terminal mangled htop's output .

EDIT: Fun fact, while we're talking about htop: there might be a bug in the htop version bundled with the latest USBNet release where some rows (i.e. threads/process) just go poof, which is kind of a shame ;D. The one from the snapshots should hopefully be okay.

[Ffan]

Alright, now I used PuTTy for something like this:

[knc1]

Originally Posted by Ffan

Alright, now I used PuTTy for something like this:

Which is pretty clear that it is the indexer spinning in its exception handler.
Specifically, it looks like the indexer is running out of RAM.
Perhaps enabling swap will fix it. (twobob has some posts here about enabling swap)

(But this was a useful experience anyway - information gained on forensics of a mis-behaving Kindle.)

Remove those "20 or so" new books you added, see if they contain the problem book.

Your picture now has a reference: https://www.mobileread.com/forums/sho...d.php?t=237083

[Ffan]

Little bit of problem here. So I went about deleting books in increments of about 20, up to a hundred by now. Still the indexer is running my kindle fullsteam. I did even restart the Kindle inbetween. Are we certain a book is the only possible cause ?
Just looking at the timeline I deleted everything going almost 3 months back. It might be possible the problem was evident back then, I just didn't realize it but it doesn't seem likely to me I have to say. One other thing came to mind, will the book cause the same problem again, if I put it on the kindle again ? I mean how am I gonna find the culprit if so ? =(

[knc1]

Use: "half split" search method.
Remove books until the problem goes away.

Re-install half of them -
If problem recurs - it is among that half, take half of those out, repeat.
If problem does not recur - it is among the other half, split those into two groups, repeat.

I.E: do a "binary search" for the problem book - keep in mind there may be more than one "problem book".
If only one "problem book" and less than 512 books - you'll find it in less than 10 test groups.
(Which is a tad bit less work than testing 500 books, one at a time. )