For the first 5/10 pages, the speed of page turning is ok as well as menu response.

After some time the device stops responding and I have to force turn off and boot again.

Any clue?

(Kobo aura 2013, 3.1.1 firmware)

Interesting. Does it do this with all your pdf-files?

Could you create an new issue on github with ideally this problem description, a link to the pdf-file that generates the bug, a link to your koreader.log for the entire session between starting of koreader and forced turn off?

Please mention that you have a Kobo Aura HD, instead of Kobo Aura (2013).

Could you create an new issue on github with ideally this problem description, a link to the pdf-file that generates the bug, a link to your koreader.log for the entire session between starting of koreader and forced turn off?

Please mention that you have a Kobo Aura HD, instead of Kobo Aura (2013).

I'm going to open create new issue on github. For now I can say that crash,log contains only "killed" just as if It was stoppet by powering off (?)....
The question is that after some pages kobo aura (not hd) becomes so slow (not responsive) that every command is executed with a delay of (increasing seconds). It happens only with text reflow of pdfs (the interested pdf is a small one - 16 pages - Melville's "Bartleby").
Is just like if a sort of "buffer" become full and every command is processed with delay.

I'm going to open create new issue on github. For now I can say that crash,log contains only "killed" just as if It was stoppet by powering off (?)....
The question is that after some pages kobo aura (not hd) becomes so slow (not responsive) that every command is executed with a delay of (increasing seconds). It happens only with text reflow of pdfs (the interested pdf is a small one - 16 pages - Melville's "Bartleby").
Is just like if a sort of "buffer" become full and every command is processed with delay.

Ken; I might well be wrong, but I don't think that the "killall -STOP nickel" would close any files that nickel had open for writing; it will just ensure that the process is paused leaving all resources that it had open, open.

Ken; I might well be wrong, but I don't think that the "killall -STOP nickel" would close any files that nickel had open for writing; it will just ensure that the process is paused leaving all resources that it had open, open.

3<&- means that file descriptor 3, opened for writing(same as stdout), is closed.

Howdy all.
I believe I found a way to run koreader and nickel from kobo launcher with a fully operational touchscreen in all. Steps below. Appreciate any feedback.

This method involves writing a custom script into /tmp/exec.sh when koreader or nickel buttons are pressed in kobo launcher followed by terminating kobo launcher. When the launcher exits the custom script executes and launches the other software.

3) Run Kobolauncher from the startup script /etc/init.d/rcS (or other) via the following code, appended to the end of rcS, instead of the default nickel (i left the hinderburg process running at all times):

I was thinking that if the history folder were on the external uSD card along with the ebooks, then you could take your SD card from device to device, running Koreader, and have the same reading settings and position. Perhaps the program could check if there is a .History folder in the SD root and use that one, over the internal one?

I was thinking that if the history folder were on the external uSD card along with the ebooks, then you could take your SD card from device to device, running Koreader, and have the same reading settings and position. Perhaps the program could check if there is a .History folder in the SD root and use that one, over the internal one?

Luck;
Ken

In koreader/frontend/apps/filemanager you can find filemanagerhistory.lua. On line 61:

Code:

local history_dir = "./history/"

You could manually edit the file to point to wherever, or use the startup script to check whether there is another history directory with newer files and than use sed to edit the line before starting koreader and reverse it to normal after.

I think you could also write the whole thing at that point in the script.

Your main problem is probably motivation as your sdcard is only a little more mobile than your reader. With the chance of small things getting lost it is probably even less effectively mobile for reading.