Kobo Clara BW: huge battery usage, gesture for light/warness lagging

[kyxap]

• KOReader version: koreader-kobo-v2024.04-32-geb6e5e3c2_2024-05-10
• Device: Kobo clara bw

Issue

I know this is maybe too early to talk since I'm using pre release version but I want to report/ask what to expect in future releases

I'm completely new user of koreader but in the same time I'm surprised how many awesome stuff is already build and how much potential stuff can be build in the future!

Two issue that let me think if I should keep Clara BW or look for another e-readear for better koreader support

1. Battery life

• I'm loosing around 10% per ~1.5h while reading 1 book with light/warm enabled, occasionally go back and force for footmarks

Is this expected? Is this kobo issue? clara? some improvement could be done in new release version?

2. Default gesture up and down on left/right of the screen for light/warmness is lagging
   UPD:
   By "lagging" I mean when you do swipe up/down it randomly ignores the move (no light/warmness change).
   It hard to understand how fast or slow you should do the swipe and it seems like it just randomly decide to change it. Same for how far from the left/right screen border you should do swipe.
   For example you can do 3 swipes up and device will react only on 1 of the swipes.
   Mainly I'm comparing the same gesture with original firmware/reader app, it works much smoother with almost zero delay.
   You can change the lights even without taking finger off the screen which is much cooler since you can't actually be sure if its will be +1 +3 +5 change. So not sure if its a bug or something to improve in ux

Steps to reproduce

see above

[offset-torque]

Your total reading time of ~15 hours is nearly same as my Kobo Libra, which has the same capacity battery as your device kyxap. Remember that our devices has pretty small batteries. Even entry level phones these days has 3 times larger battery than these devices. And manufacturers mislead by promising "weeks of battery life" but when you read the small letters it is like "30 minutes of reading per day with wifi off...".

Probably KOReader is already optimized to the max on your device which leaves your options to:

• Charge more frequently or carry a power bank
• Upgrade your battery with a larger one from third party sellers (void warranty, technical and risky)

There are devices with bigger batteries but they generally have Android OS which has relatively higher power consumption due to all background services. So I am not sure that would be a meaningful upgrade for reading time. Someone else who has experience with them can comment here.

[NiLuJe]

1. Enable a standby timer in the relevant device settings (this is disabled by default, and wouldn't have been accessible in the original PR if you ever tried that manually).

Also, never trust the actual value shown in the battery gauge. Trust how long it actually lasts until it shuts down instead. This has always been true, but is especially true on those new devices because the PMIC does wonderfully wonky things with the battery gauge.

2. Define "lagging"? I don't see anything out of the ordinary on the Libra Colour, which supposedly uses the same PWM controller. Said controller is very very very awful, though. Keep in mind the perceived results might also depend on what's actually being shown on screen, because those devices have funky refresh semantics (e.g., on the color models, if you swipe on a page with an image, the notification dismissal will trigger a full page flash).

[NiLuJe]

FWIW, the power efficiency on these SoCs is roughly as expected.

The lab126 imp is still more efficient, but it's nonetheless a fair bit better than previous NTX boards used on kobos (even the ones that weren't horribly broken like the sunxi ones ;)).

c.f., #9435 (comment)

(Which, yes, is completely useless as you can't compare shit in this table; re-doing proper captures to generate a table is on my pile of crap to eventually get to).

(And, not seen is this table: they have sane standby resume performance, i.e., ~4ms, with very few outliers up to 10ms. This matches sunxi, where this was basically the only PM thing working nicely on those boards ;p. Except when they broke it on later kernels and it started to cause missed inputs, but I digress ;p).

[jonnyl2]

Also, never trust the actual value shown in the battery gauge. Trust how long it actually lasts until it shuts down instead. This has always been true, but is especially true on those new devices because the PMIC does wonderfully wonky things with the battery gauge.

@NiLuJe: Does this equally apply to the stock software? Or does that have different and more accurate ways of measuring charge state available to it than KOReader does?

[Frenzie]

I've never noticed any difference in that regard when reading in Nickel.

[kyxap]

Your total reading time of ~15 hours is nearly same as my Kobo Libra, which has the same capacity battery as your device kyxap. Remember that our devices has pretty small batteries. Even entry level phones these days has 3 times larger battery than these devices. And manufacturers mislead by promising "weeks of battery life" but when you read the small letters it is like "30 minutes of reading per day with wifi off...".

Not sure if I understand how small letters (you mean font size) impacting the battery? I was using 25.5 for last book, not sure if can be considering "small".

Also I'm coppering this to my previous kindles, the one I have is pw 7th gen which has similar battery capacity it actually takes weeks before re-change. Not like 3 days and you got 50% left. But there no "warm" light so maybe that is a difference?

[kyxap]

1. Enable a standby timer in the relevant device settings (this is disabled by default, and wouldn't have been accessible in the original PR if you ever tried that manually).

I forgot about this but some how I've enabled it the first hours of using of koreader

Also, never trust the actual value shown in the battery gauge. Trust how long it actually lasts until it shuts down instead. This has always been true, but is especially true on those new devices because the PMIC does wonderfully wonky things with the battery gauge.

I was reading somewhere that its not recommended to wait till device is goes to 0% and shuts down

2. Define "lagging"?

I've updated the original post

[Frenzie]

Not sure if I understand how small letters (you mean font size) impacting the battery? I was using 25.5 for last book, not sure if can be considering "small".

The small print refers to the illegible stuff they sometimes put on contracts.

[NiLuJe]

@NiLuJe: Does this equally apply to the stock software? Or does that have different and more accurate ways of measuring charge state available to it than KOReader does?

Yup. There's no secret sauce anywhere.

I was reading somewhere that its not recommended to wait till device is goes to 0% and shuts down.

Again, the battery meter is a lie ;). 0% does not mean a dead battery. It'll shut down well before the voltage gets low enough to be problematic.

(I'm not necessarily recommending that you always do that, mind you ;)).

Basically, the only thing you should rely on the battery gauge for is to check whether you need to charge your device or not. Anything else is a fool's errand.

[NiLuJe]

As for .2, the behavior is just different: the % delta is computed based on the gesture's distance, so it's always an "on lift" change.

If you want an "on pan" change, swipe inside the brightness/warmth bar in the frontlight widget itself.

[NiLuJe]

I cannot vouch for the accuracy of the gesture on your device, as it's using a different touch panel than mine.

Verbose debug logs will tell us whether there's a gesture misdetection or not.

EDIT: Oh, and it doesn't report per-contact lifts, so there may very well me some wonky behavior if you've got stray contacts.

So, yeah, verbose debug log, please.

[kyxap]

added debugs in upd2: ^

[NiLuJe]

Please attach an actual file, and please post it in a dedicated answer; updates are extremely hard to track and make everything super confusing when you review an issue later.

[NiLuJe]

This will also ensure that the log is complete, because that excerpt is way too short to be meaningful.

[kyxap]

crash.log
done

[NiLuJe]

You have Wi-Fi enabled, of course battery life is terrible -_-".

Besides Wi-Fi itself being the largest source of power consumption on that device, it also means that any and all other power management features are disabled while Wi-Fi is on.

(You also have restore wifi on resume enabled, which should mostly no longer be necessary, especially on Kobo, unless you have some very specific workflows. My recommended setup would be: Disable wifi when inactive / Turn on when wifi is off / Leave on after done with wifi. Disable when inactive being the most congruent one for this PR ;).).

[kyxap]

I've never turned off wifi on kindle manually :| it just automatically goes to some kinda sleep mode, why to stay connected if there no reason for that? Anyway I'm not sure I fully understand all settings that you mentioned above but now I have those:

is what you've recommended?

all other power management features are disabled while Wi-Fi is on.

is there a list for such features or specific menu to make I've not enabled for some reason?

Thanks for looking into power consumption, also I've uploaded the crash log more for issue #2 which is no response/lagging on swipes for lights, not sure if there any issue in the logs but seems to be in shows all screen manipulations

[Frenzie]

My recommended setup would be: Disable wifi when inactive / Turn on when wifi is off / Leave on after done with wifi. Disable when inactive being the most congruent one for this PR ;)

It seems to be off by default. Shall we change some defaults?

[kyxap]

It seems to be off by default. Shall we change some defaults?

also maybe change the naming, like from "On" to "Always On" which may force people like me to think.... hey always on is not what I need and it could drain my battery or add that nice info button inside of the menu to give the explanation that always is to use for such thing like ssh server or else (that my understanding at this moment). I think i've turned it on because connection to wifi with multiple pop-up gave me feel its better to be on instead of waiting every time for connection if I wanna look for quick wiki search

[Frenzie]

Which naming are you referring to precisely?

[NiLuJe]

It seems to be off by default. Shall we change some defaults?

It's contingent on actually being implemented, and I don't recall exactly on which platforms that is exactly or why exactly, but, yeah, that would probably make more sense as a default where we can.
(e.g., I know it works on Kobo, that it theoretically works on Kindle but not practically unless you severely nerf the stock system to not call home every 2 seconds, but I don't remember if we actually have an easy Device cap to check for that).

Push comes to shove, if Kobo works ;).

EDIT: There's probably a semi sensible way to check for that, since we don't expose the setting in the UI otherwise, duh' ;).

[NiLuJe]

On means on, you're just conditioned by Nickel's own default which is to aggressively kill wifi. In the land of IoT, that's the exception, not the rule.

A Kindle doesn't ever kill Wi-Fi on its own either, knowing what you do with your device is how Amazon makes money off of it, they hate it if you enable Airplane mode.

The actual Wi-Fi chips have power-management features to reduce their own power consumption when mostly idle, but that's neither here nor there (and I suspect the current MTK kernels may not be entirely up to snuff on the wifi front right now anyway), as it still prevents the rest of the system from entering lower power states.

[NiLuJe]

is what you've recommended?

Yup, looks good.

Just to double-check that there wasn't a weird bug, you did have "Restore Wi-Fi connection on resume" enabled when the logs were produced, right?

[NiLuJe]

Thanks for looking into power consumption, also I've uploaded the crash log more for issue #2 which is no response/lagging on swipes for lights, not sure if there any issue in the logs but seems to be in shows all screen manipulations

Oh, right, had forgotten about that.

There's no logging around the frontlight codepaths, so it'd be hard to tell exactly, but at least I can't see anything wrong with the swipe detection, so I'm assuming it behaves as expected.
It'd take someone with the exact same device to confirm whether the frontlight ramping needs some tuning there or not. I can only say that it looked terrible on the Libra Colour before I clubbed it over the head.

[NiLuJe]

EDIT: There's probably a semi sensible way to check for that, since we don't expose the setting in the UI otherwise, duh' ;).

Yup:

koreader/frontend/ui/network/manager.lua

Lines 1021 to 1024 in 40814bf

	-- Allow auto_disable_wifi on devices where the net sysfs entry is exposed.
	if self:getNetworkInterfaceName() then
	common_settings.network_powersave = self:getPowersaveMenuTable()
	end

With the caveat mentioned earlier that it won't help on unmodified Kindles (because the native system is way too chatty).

[kyxap]

Just to double-check that there wasn't a weird bug, you did have "Restore Wi-Fi connection on resume" enabled when the logs were produced, right?

yes, correct

[kyxap]

I guess this one can be closed?