Bug 182504 - boggug time accumulation when performing suspend/resume of a laptop
Summary: boggug time accumulation when performing suspend/resume of a laptop
Status: REOPENED
Alias: None
Product: ktimetracker
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Zoltan Gyarmati
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-30 22:57 UTC by JeanpPhilippe Robichaud
Modified: 2019-11-12 23:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JeanpPhilippe Robichaud 2009-01-30 22:57:02 UTC
Version:            (using KDE 4.1.4)
OS:                Linux
Installed from:    Gentoo Packages

KTimeTracker (and KArm before that) does not manage cases where a laptop goes in suspend mode and is resumed later.

If I put my laptop in hibernation mode and re-open it 5 hours later, the 5 hours period gets added to the task that was active when the system went in suspend mode.

This has serious implication as some tasks now show 21 hours of 'effort' for one day!

Thanks,

Jp
Comment 1 Thorsten Staerk 2009-02-02 07:07:10 UTC
I have not had a chance to test this. Thanks for the report.
Comment 2 JeanpPhilippe Robichaud 2009-02-03 02:27:13 UTC
Thanks for looking into this!

Do you have access to a laptop to test this?  If not, I can test it.  I'm using gentoo on my laptop.  If you have a set of patches that apply against 4.1.4, I could test it easily...

Thanks again,
Comment 3 Dirk Hoffmann 2010-01-26 02:19:57 UTC
It should work with any PC that can go to "standby" and runs a Linux which handles it correctly.

I am not sure I observe an additional KArm/Ktt time of exactly the time that my PC went to sleep. I am afraid there is a more nasty rule to correct the entry. But I do not remember now (too late, maybe?)...

By the way: When my laptop sleeps, that does not mean I stop working! The behaviour (add time or not) should be an option, or should be suggested to the user, alike the window that pops up in "idle" state.
Comment 4 Thorsten Staerk 2011-10-08 07:39:31 UTC
I don't see a way of fixing this. Please reopen and set yourself as assignee to fix it.
Comment 5 Dirk Hoffmann 2011-10-08 07:51:06 UTC
I am surprised this should be so complicated.

You have a task which is detecting inactivity, probably periodically. If the PC is on standby or hibernate, then the task will not detect inactivity, as it will recognise a recent screen activity just before it is called the last time before the PC goes to sleep, and then just before it is called the first time after the PC woke up.

A simple timer (last_called = time()) with comparison similar to the already defined timeout value (if time() - last_called > timeout) should make do.

This would trigger a false inactivity, if for any reason the inactivity watchdog were not executed due to PC overload. Doh! To do it super-cleanly, you may want to distinguish in the configuration option: Detect screen inacitivity / detect computer inactivity / detect both.

PS: "Do it yourself" is not exactly the answer a bug reporter would expect from a software maintainer.
Comment 6 Thorsten Staerk 2011-10-08 15:10:46 UTC
The design is a bit different:

starting the task: adding a start datime
stopping the task: adding an end datime

if or if not there is a suspend/resume between starting and stopping the task is not visible to ktimetracker
Comment 7 JeanpPhilippe Robichaud 2011-10-19 17:19:56 UTC
I think that what Dirk is proposing make perfect sense and can be included in the current design:


if (time() - last_called > timeout){
  foreach tasks in activeTasks :
     add last_called() as a end datime
     add time() as a start datime
}

would that make sense?
Comment 8 Thorsten Staerk 2011-10-20 06:18:49 UTC
Setting it back on my queue.
Comment 9 Andrew Crouthamel 2018-09-04 18:55:00 UTC
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.