@poire-z I'm still a bit unsure between this and the other variety. How about you?

I think this 2-lines PR is fine.
Maybe add a comment in main.lua: -- as a key event, reset any standby/suspend timer

I thought this was fixed, so I downloaded latest beta, but the issue is still there?

• Autosuspend timeout set to 20 minutes
• Page turning by sending commands via HTTPInspector
• Device suspends in 10 MINUTES while reading...
  crash.log

Edit: when disconnected from WiFi and left alone for 20 minutes, device autosuspends as expected. KOReader running in standard mode (not the frameworkless one)

The logs show this PR working as intended.

09/06/25-14:37:39 DEBUG HttpInspector: Received request: GET /koreader/event/GotoViewRel/1 
09/06/25-14:37:39 DEBUG HttpInspector: Sending response: HTTP/1.0 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 23
Connection: close

Event sent: GotoViewRel 
09/06/25-14:37:39 DEBUG AutoSuspend: onInputEvent 
09/06/25-14:37:39 DEBUG AutoSuspend: onInputEvent 
09/06/25-14:37:39 DEBUG goto relative screen: 1 in mode: page 

Suspend didn't come from KOReader but from the Kindle itself:

09/06/25-14:37:47 DEBUG Kindle:intoScreenSaver via UNKNOWN_SUSPEND (3) 

@NiLuJe @hius07 Is this something that would be affected by no framework mode?

@NiLuJe @hius07 Is this something that would be affected by no framework mode?

I don't actually remember, but I assume we keep powerd alive, otherwise we'd be sort of crippled ;).

So, to actually answer the question: no, I don't think so ;).

In context I suppose the real question is whether it can be told that yes, we're active right now.

I seem to recall us pinging powerd... somewhere, to ensure it honors our suspend timer and not its baked in one; but I don't recall the exact details (but I would hope this approach would Just Work(TM) without anyone having to think about that implementation detail).

I seem to recall us pinging powerd... somewhere, to ensure it honors our suspend timer and not its baked in one; but I don't recall the exact details (but I would hope this approach would Just Work(TM) without anyone having to think about that implementation detail).

Yep, it's handled by AutoSuspend automagically (by which I mean, it uses the same last_action_time ticker updated by the plugin's onInputEvent handler).

Then it sounds like everything should be working.

This is the last time it triggered before suspend.

09/06/25-14:32:52 DEBUG AutoSuspend: scheduling next t1 timeout check in 299.5326

09/06/25-14:37:47 DEBUG Kindle:intoScreenSaver via UNKNOWN_SUSPEND (3) 

Which would suggest either the default isn't 10 minutes and it's merely 5 (with the update triggering just prior the first time by sheer coincidence) or that it's not working at all.

I imagine they could have somehow tweaked the default timeouts, which device and FW version was that running on?

(I don't remember the command OTOH, but the whole lot of powerd timeouts are stored in the elektra db that's.. somewhere I can't remember in /etc ;p).

No tweaking on user end. PW5, FW 5.14.1.1,, default Amazon timeout is 10 minutes (timeout is non adjustable, unlike on newest firmware versions.).