One-Click Install Packages for KOReader & Plato

[artsybrute]

I'm thick. I put both zips into a new directory. I unzipped the nix archive. Then I ran the script. I got:

len@lendebssd:~/Downloads/KOBO_OCP_reader$ ls
install.sh kfmon.png OCP-KOReader-v2020.05.zip
kfm_nix_install.zip koreader.png
len@lendebssd:~/Downloads/KOBO_OCP_reader$ ./install.sh
No supported packages found in the current directory (/home/len/Downloads/KOBO_OCP_reader)!

[artsybrute]

The script seems to be looking for KOReader...zip but I have OCP-KOReader...zip, I think.

from the script:
AVAILABLE_PKGS=()
for file in KOReader-v*.zip Plato-*.zip KFMon-v*.zip KFMon-Uninstaller.zip

But in the directory:
OCP-KOReader-v2020.05.zip

Did I download the wrong install script somehow?

[NiLuJe]

You did. It was updated a few days ago, and the download is up to date on my end :?.

[artsybrute]

Wow, magic! I love this reader!

Thank you.

[mirage]

I installed Plato and KOReader via the Mac install script on posts 1 and 2. Thanks for this work!

KOReader is extremely slow for me with epubs and kepubs, the only file formats I've tried. Is that common behavior? I gather from earlier posts that changing things like margins can take awhile. Most changes I made were slow and overall performance is sluggish. This is with a Libra H2O. Not a complaint, just wondering.

[NiLuJe]

@mirage: CRe (KOReader's main ePub engine) is not a chunked renderer. It takes the full book, processes it, and caches it. This essentially ends up as a giant roll of papyrus. Rendering a page is then as simple as picking a starting point from that roll.

This makes actually navigating a book extremely fast (moderately faster than the KePub render, slightly faster than any of Kindle's various renderers, massively faster than the RMSDK).

The obvious trade-off is that generating this first intermediate layer is time consuming (but most of it only affects the first time a book is opened, since this ends up being cached). That's the tiny progress bar you see in the top-left corner when opening a book.
The other trade-off is that changing anything that affects how the text will be laid out (on the book's scope, not on the page's scope) means a part of this intermediate rendering has to be thrown out and re-done (and, once again, tiny progress bar after a short while).

On a novel-sized, sanely coded fiction ePub, initial open should take a couple seconds at most, and re-layout roughly a second at most.

Larger books will affect that performance penalty adversely. As would tricky/degenerate code. Given how KePubs are made, a KePub will be very slightly worse off that a plain ePub.

Since you ultimately end up spending 99.99% of your time reading, and that every setting can be remembered as default, that's an acceptable trade-off in my book.

It might not be for you. Fair enough.

On the other hand, if your first instinct was to play with every setting affecting layout, and you happened to do that in a giant/poorly coded book, that definitely won't be any fun.
Try to do that in a short book first (e.g., KOReader's quickstart guide) to get your sea legs .

[mirage]

Originally Posted by NiLuJe

@mirage: CRe (KOReader's main ePub engine) is not a chunked renderer. It takes the full book, processes it, and caches it. This essentially ends up as a giant roll of papyrus. Rendering a page is then as simple as picking a starting point from that roll.

This makes actually navigating a book extremely fast (moderately faster than the KePub render, slightly faster than any of Kindle's various renderers, massively faster than the RMSDK).

The obvious trade-off is that generating this first intermediate layer is time consuming (but most of it only affects the first time a book is opened, since this ends up being cached). That's the tiny progress bar you see in the top-left corner when opening a book.
The other trade-off is that changing anything that affects how the text will be laid out (on the book's scope, not on the page's scope) means a part of this intermediate rendering has to be thrown out and re-done (and, once again, tiny progress bar after a short while).

On a novel-sized, sanely coded fiction ePub, initial open should take a couple seconds at most, and re-layout roughly a second at most.

Larger books will affect that performance penalty adversely. As would tricky/degenerate code. Given how KePubs are made, a KePub will be very slightly worse off that a plain ePub.

Since you ultimately end up spending 99.99% of your time reading, and that every setting can be remembered as default, that's an acceptable trade-off in my book.

It might not be for you. Fair enough.

On the other hand, if your first instinct was to play with every setting affecting layout, and you happened to do that in a giant/poorly coded book, that definitely won't be any fun.
Try to do that in a short book first (e.g., KOReader's quickstart guide) to get your sea legs .

Thank you for the detail!!! I figured it was probably "reformatting" the whole book, thus the extra time after making those sorts of adjustments. Good to know that it's not a constant thing. Having tweaked a lot of epub css, I'm not surprised that the messier implementations can slow that down all the more.

It did seem to me, though, that even going through the menus in KOReader was pretty sluggish. Plato was snappier. I deleted it all, but I'll probably reinstall. I just got the device, so I'm experimenting a lot.

[NiLuJe]

With very, very few exceptions, menus should pretty much show up before you've even started thinking about tapping somewhere to show one ;p.

I mean, it's a pet peeve of mine (tapping a menu and having the time to go sip a coffee before it shows up), so I've spent quite a bit of time and effort in making pretty sure of that.

[serdar0020]

I've just done my first update from 2020.05 to 06 and I didn't re-install the ps1-script with powershell, I just extracted the zip contents to the root directory. Seems to have been successful. That was sufficient, right?

And if there's just the plain KoReader update, but no One-click package update, would it be possible to just replace the contents of the KoReader folder?

[jsessions]

Having an issue installing using the Windows script (install.ps1), just returns following error:

Get-Disk : Invalid property
At C:\Users\Jason\Desktop\install.ps1:19 char:18
+ $KOBO_MOUNTPOINT=Get-Disk | Where BusType -eq USB | Get-Partition | G ...
+ ~~~~~~~~
+ CategoryInfo : MetadataError: (MSFT_Disk:ROOT/Microsoft/Windows/Storage/MSFT_Disk) [Get-Disk], CimExcep
tion
+ FullyQualifiedErrorId : HRESULT 0x80041031,Get-Disk

Couldn't find a Kobo eReader volume! Is one actually mounted?
* Nothing to do! Press Enter to exit:


My ClaraHD was plugged in and showing in explorer.

I can obviously install by extracting zip directly to eReader's root directory but it would be handy to understand why I'm getting the error for the future! (PS both the install.ps1 and KOReader zip was downloaded today so are latest versions).

[NiLuJe]

@serdar0020: That's essentially the only thing the script does. So, provided you did it right (which, apparently, is harder than it sounds for some people, hence the script ;p), and actually used the OCP zips, you're good.
If you just need a KOReader update, use the OTA update feature built-in KOReader itself.

Trying to be cute is only likely to bite you on the ass (and you will miss on potentially useful NM/KFmon updates).

@jsessions: Which version of Windows is that on?

[jsessions]

Windows 10 (1909) build 18363.900.

I have previously (last year) successfully installed KOReader/Plato using the script but later uninstalled so failure this time around was unexpected!

[NiLuJe]

@jsessions: Huh. Microsoft errors being the mess that they are, plus me not being a Windows user, I'm not sure there's anything more I can say, unfortunately :/.

Except that, yeah, it should have worked ;p.

[NiLuJe]

A quick Google reveals that it might just be Windows doing a Windows: https://stackoverflow.com/q/52324009

(i.e., Here be dragons!).

[jsessions]

@NiLuJe ~ Not a problem. I'll install manually.