Developers: Which reader has the best KOReader integration?

[zmixnyc]

I have seen some great e-readers coming out and as much as I love my Pocketbook ERA it seems to have some issues with highlighting text consistently.

I figured that any e-reader I might get will be fine as I will only ever use KOReader on it.

So... What's the best hardware these days?

[mergen3107]

There were similar discussions here, please search.

You can use tags like "bug" and a platform ("Kobo", "Kindle", "Android", or others) and see what tickets are still open.

Also on MobileRead: https://www.mobileread.com/forums/showthread.php?t=347826

From my observations for recent new hardware, new Kobos (Clara BW/Color, Libra Color) are quite good - because they have MediaTek processors.

Clara BW is probably a sweet-spot: 1 GHz single-core MediaTek + 512 MB RAM. However, I don't know if there kernel/platform related quirks.

Clara Color has 2 GHz dual-core MediaTek + 1 GB RAM, but it needs to drive both 300 ppi content and 150 ppi color content, so I don't really know how much faster/slower it is against Clara BW when compared on similar things.

Other Kobos from MK7 are quite good as well (maybe except only Libra 2 revisions with quirks). In my own experience, Kobo Clara HD is excellent.

From my own experience again, I know for a fact that Kindle Scribe is great (1 GHz MediaTek + 1 GB of RAM), barring you can get one with low enough firmware (≤5.16.2.1.1) to get JailBreak on it.
This is my everyday device and I love reading books, manga in CBZ, and even scientific articles without zoom (downloaded straight from my Zotero account) on its gorgeous 300 ppi 10 inch screen.

Android is probably the worst of all, first reason because Android frame buffer handling add much more delay in drawing eink frames. Other reason include but are not limited to bad/terrible OEM implementation that might prevent or impede with your experience, like light controls, etc.

However, in my own experience again, besides that slowness of the screen (which I only realized only after comparing it to Kindle Scribe directly for the first time) Onyx Boox Kon-Tiki 2 KOReader experience was great. I fixed a thing or two while I had device (exporter plugin and light control), so it is even better now :D

You want to avoid older Onyx Boox devices with RockChip CPUs and go for Qualcomm CPUs for many reasons (performance, battery life, and root availability - but that one is beyond the topic of KOReader since you don't need root for pleasant KOReader experience).
I saw good feedback from Onyx Boox Leaf 1/2, Onyx Boox Page users. Maybe others on similar platforms.

I can't say anything about PocketBooks just because I hadn't one, but I know there is a lot of interest and activity about it here on GitHub, many of which were successfully solved (upon my quick throwback in my memory).

[zmixnyc]

Thanks for the reply. I did do search here before I posted, so sorry, I must have missed something.

I saw the new Onyx Book Palma today and pretty much hated the built in reader software, but liked the small(ish) form factor and the screen looked great.

Those of you who have tested KOReader on multiple platforms have you been happy with the consistency?

[Commodore64user]

Kindle Paperwhite 3/4 (?) - Sometimes crashed due to not enough free ram

my kindle voyage and k4 don’t seem to suffer from this… (touch wood)

[Frenzie]

Depends on the types of documents you open. Outside of heavy PDFs it's generally not an issue.

[Commodore64user]

I thought PDFs would use less memory since all the computation has already been done. But then again, you can indeed get very large PDF files unheard of in the ePub world (unless is one of those ridiculous omnibuses with like 20 novels in them)

[mergen3107]

PDFs with large uncompressed images are usually an issue.

PDFs with mostly text are OK.

[Frenzie]

With PDF the size of the document doesn't matter much, but the (resulting) size of an individual page does. There's an issue around here somewhere of someone with a page that allocates 200+ MB to render.

There is however a strong correlation between the two.

[pazos]

So... What's the best hardware these days?

1. A recent Kobo that has no issues.
2. A recent Pocketbook that has no known issues??.
3. A recent Android device that is supported and has no known issues?????.

You can also repurpose a kindle if you can jailbreak it.

I will only ever use KOReader on it.

Pocketbook and Android can open links in a web browser.
Pocketbook home screen provides a library view for KOReader.
Android supports 3rd party dictionaries and sharing text with other apps.

Kobo/Kindle/Remarkable have none of those. If they're not relevant to you go for a kobo. The one that @NiLuJe vouches for ;)

[NiLuJe]

they changed something for the worse.)

Spoiler alert: they did ;p.

any news on that front?

Something might be coming up Soon(TM).

But depending on how up-to-date your device is, that may not do you much good for now, because of the above (i.e., armhf).

why @NiLuJe is no longer a kindle evangelist

My stance hasn't changed much: the hardware is very good, everything else is a massive PITA.

[Commodore64user]

Something might be coming up Soon(TM).

Eyes shine brightly

But depending on how up-to-date your device is, that may not do you much good for now, because of the above (i.e., armhf).

I'm f***ed. 5.16.8 what can i say, I'm a serial updater.

everything else is a massive PITA.

Luckily my KV does not get new updates so one thing less to worry about

they changed something for the worse.)

Is that from everyone's perspective or just from a "modding one"?

[Commodore64user]

In a world where there is no JB available past 5.16.2 (and assuming there is not going to be one soon) what does this mean #11986 for kindle users? What if we assume that there is a JB due soon?

btw 5.16.9 is out now

[mergen3107]

Technically, when you have JB and accidentally get updated to > 5.16.2, JB still work (which allows you to run custom commands to downgrade). But that's it for now.

With at least KOReader working, there is hope that Kindles are useful again :D (but I think gandalf - JB permission binary/script needs to be recompiled too).

For non-Scribe users, I don't think there is much difference between FW versions.

For Scribe users, they can finally keep up with notebook updates while still having KOReader.

[Commodore64user]

I see, thanks!

[dmalinovsky]

I'm a happy user of KOReader on Pocketbook Inkpad Color 3 (and I like its crappy pastel colors :).

After some color rendering related fixes I've made, it's working really well on it, performance wise it's similar to the build in reader, and it has pretty good integration — at least I didn't find anything lacking. Also, Pocketbook Sync plugin adds nice bits for the home screen integration.

[NiLuJe]

The InkView loop is tick-based, with a really awful resolution, so it starts with a pretty severe (self-inflicted) handicap.

Like I said, you might not be able to notice it and/or it might not bother you, but it's there.

[dmalinovsky]

Oh, interesting, I didn't know that. I guess my perception isn't sharp enough. :)

[Frenzie]

@NiLuJe

The InkView loop is tick-based, with a really awful resolution, so it starts with a pretty severe (self-inflicted) handicap.

I presume that explains what @Biep wrote here? #11668 (comment)

[NiLuJe]

I presume that explains what @Biep wrote here? #11668 (comment)

It doesn't help; but the main explanation for that issue probably lies in the lack of timerfd support for the handling of hold timers, which means we fall-back to a userland timer, and, worse, possibly one based on the time of input processing on platforms with (kernel) timestamps we can't trust and/or interpret properly.

That's definitely the case on PB, where we use a gettimeofday we compute ourselves when we catch an IV pointer event (and that's the tick-based loop with a crap resolution of something like 50ms I was talking about earlier).

On Android, we don't do timerfds, but we can at least trust the kernel timestamp if it looks sane (I don't actually recall when that might not be the case, though, but it should be pretty obvious from looking at verbose debug logs: on a sane (Android) device, you should see different timestamps for each individual event, instead of one per input frame).

[Frenzie]

Thanks, I didn't know that about PB