Koreader running on Kobos (all of them, hopefully!)

[Frenzie]

That's (mostly) nice to hear. Pity about the battery life.

[Uncle Robin]

Originally Posted by Frenzie

That's (mostly) nice to hear. Pity about the battery life.

It is, but I bought an ex-demo Libra H2O last month, and "push progress" is now a gesture on both devices, so interruptions to reading are minimal - when the Sage is in single digit battery figures, push the progress, plug it in and pick up the Libra H2O. Synching sideloaded epubs across devices, yet another win for KOReader

[NiLuJe]

FWIW, enabling auto-standby should yield similar to better battery life than in Nickel (with the usual caveats on i.MX devices, where it'll tank page turn latency to almost as bad as Nickel levels ).

[Uncle Robin]

Originally Posted by NiLuJe

FWIW, enabling auto-standby should yield similar to better battery life than in Nickel (with the usual caveats on i.MX devices, where it'll tank page turn latency to almost as bad as Nickel levels ).

Thanks, I'll give that a go when my Sage is finished charging

[mbrisco]

Originally Posted by NiLuJe

Nope, apparently the Libra 2 is just a broken mess ;o).

The crashing is known, and we can't do anything about it, unlike for the Libra 1, where we ultimately managed to tame the worst of it, putting it at only a slight disadvantage on the "weird Mk. 7 EPDC crash" podium, compared to its buddies the Clara & the Forma (which also suffer from a wide range of weird epdc bugs and/or crashes).

What's fairly new is that it *has* been reproduced (a lot.) on Nickel. (Well, technically, not that new, the Libra 1 EPDC issues were also reproducible in Nickel, albeit at a lower frequency, and were somewhat sneakier to catch in the act for untrained eyes).

The higher than expected power drain for an i.MX SoC has also been mentioned before, but it's harder to quantify because battery gauges are broken by design on NTX boards. (And because it was overshadowed by the truly horrendous power efficiency of the boards with a sunxi SoC; especially on the Sage because of its tiny battery).

With the frequency of crashes I’m seeing on KOReader on both revisions of the Libra 2, I thought there’d be more reports from stock reader users too though. And no way anyone’s getting more than 2 weeks of battery with the standby drain rate on KR. I’ve seen people claim 6 weeks from it, but at the rates I’m seeing it wouldn’t even survive 2 weeks even if you let it on standby from 100% to 0% by never using it.

[NiLuJe]

The EPDC crashes on these NTX boards have always been tightly linked to race conditions and timing issues.

To make a long story short, we have way less UI latency than nickel, which will exacerbate issues like these. (Among other things, Nickel suffers through Qt's inability to fully handle Y8 as a first class pixel format, which means it runs in full color at RGB32).

(This was fairly marked on the Clara, which you mostly won't be able to crash unless you run it UR @ 8bpp, because that's when the epdc has to least amount of work to do. That's something we never did in KOReader, because UR is not the canonical portrait and we don't do HW rotations; but Plato does, and had to disable it on that device because it became a crashfest. And Plato's refresh requests are a lot more fenced than ours, which should theoretically help with this).

The Libra, first of its name, happens to be in the unfortunate situation where UR *is* its canonical portrait rotation. That should have been a good news in theory, but in practice, it probably means more issues .

On a Libra 2, installing NickelClock (which essentially tacks on a tiny refresh to display a clock *immediately* after *most* refreshes) led to most devices not even managing to finish *booting* because of the boot anim refreshes ;o).

[NiLuJe]

As for the battery drain, when I mean "standby", I actually *mean* standby (i.e., in suspend but with the lights & input on), not idle-but-awake.

In KOReader, that implies having opted-in to enable Autostandby (which comes with a big fat warning that it may horribly implode broken ass kernels like the Libra's, so, YMMV ;p).

(It's the default behavior in Nickel, and you can't disable it, short of leaving Wi-Fi on or the device plugged in; which also happens to magically fix most of the Libra 2's issues).

[Uncle Robin]

Originally Posted by NiLuJe

As for the battery drain, when I mean "standby", I actually *mean* standby (i.e., in suspend but with the lights & input on), not idle-but-awake.

In KOReader, that implies having opted-in to enable Autostandby (which comes with a big fat warning that it may horribly implode broken ass kernels like the Libra's, so, YMMV ;p).

I figured that's what you were referring to - this setting here, no?

[ojijo]

Has anyone figured a way to trigger a page turn remotely in KOReader?

As far as I can see, BT gets killed immediately after KOReader is launched, so that's out of the question.

Remaining options seem to be:
A wired controller, not sure if there is support for external devices via USB in the Kobo kernel (probably not), but from the KOReader side remapping seems to be trivial.
Connecting to some simple web server (since Wi-Fi is working) and using a webhook to send the page turn trigger. But that would require too much work for something this trivial and won't be very effective.

[Aleron Ives]

Originally Posted by Uncle Robin

I was AMAZED at how how much better the battery life was under Nickel. After 2-3 hours reading, the battery was at 75%, when it would have been well under 50% in KOReader.

Wouldn't this suggest that it's possible to fix the poor battery life in KOReader through an update?

[NiLuJe]

@Uncle Robin: Yup.

@Aleron Ives: It landed a few months ago, but it's opt-in because it's not without its drawbacks on most devices; c.f., the post right above you.

[Uncle Robin]

Originally Posted by NiLuJe

@Uncle Robin: Yup.

Thanks. Enabling it has had an immediate impact. The battery loss is now a venous bleed, not an arterial bleed.

[mbrisco]

Seeing as the new Clara 2E is running the same CPU as the Libra 2, I wonder what the KOreader experience will be like on it.

@niluje Thank you for writing that explanation for me, even though try as I might, even as a developer myself, I couldn’t parse most of the technical jargon of it From what I understand, the Libra 2 stock UI (Nickel) tries to work around the problems by slowing down the latency, while KOReader runs in real time and thus has problems. Is that what you meant? And Nickel also uses Autostandby, which KOReader doesn’t by default because it causes stability issues? If I got that right, then why doesn’t the autostandby cause these issues in Nickel too?

I don’t quite understand how stock Nickel can run so well but KOReader has a hard time: it seems like either it’s not worth optimizing KOReader for the i.MX6SLL chip like Nickel has, or KOReader has to run on top of Nickel and the i.MX6SLL can’t handle both. Is it one of those? :P

[NiLuJe]

No, it's just that we run (by design, for performance reasons; and because of the way our UI loop functions) in conditions that exacerbate potential EPDC issues.

Nickel, on the other hand (by constraint, mostly because Qt), doesn't. So, while similar issues can (and have been) reproduced in Nickel, they should occur much more rarely (if ever for Joe Random) there.

(But this is a much more complex issue, possibly compounded by multiple subtle factors, because we've tried to run in a setup that more closely matches Nickel, and it apparently didn't help).

This is also kind of black box, as I don't have the device myself, so this is based on a few assumptions based on results from remote testing and my own experience with possibly similar issues on other devices (most of which are *also* based on results from remote testing, or on very hard to reproduce stuff that I couldn't get any debugging info out of), and, I'd need a local device with serial access (and possibly a custom debug kernel) to actually say for sure what the hell's happening (or not). And even if I did figure something out (and that's a big if), we probably couldn't do anything about it anyway.

What's for sure is that lab126 took their sweet time to polish a brand new board on a brand SoC for the PW5, but it payed off, as it's been rock-solid and hilariously more efficient than the competition, while the whole slew of boards that NTX put out and ended up in Kobo devices starting with Mk.8 have been... err, let's say *very* rough around the edges, to varying extents...

----

It's a bit early to say anything about the Clara 2E, seeing as we've only seen a single tester on a single device (and the kernel drop isn't out yet... *wink, wink, nudge, nudge*), but it's going... significantly worse than it ever did before ;D. Early days, though, and resolving the more obvious issues might magically make the rest better.

[MartinezzzLV]

So the last update for KOReader is live and I'm wondering what this line mean:

Kobo: Flag all the boards similar to the Libra 2 as unreliable (Clara 2E & Nia) @NiLuJe

https://github.com/koreader/koreader/pull/9691

Does it mean that team has given up on a way to work with a broken kernel of Libra or NiLuJe implemented some additional fixes for stability?