After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597406 - Stop tracking when suspended
Stop tracking when suspended
Status: RESOLVED OBSOLETE
Product: hamster-applet
Classification: Deprecated
Component: general
2.26.x
Other Linux
: Normal enhancement
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
Depends on:
Blocks:
 
 
Reported: 2009-10-05 11:26 UTC by Jan Rüegg
Modified: 2012-09-24 18:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Rüegg 2009-10-05 11:26:20 UTC
It would be nice to be able to "Stop tracking when suspended" (=> when the computer is in standby or sleeping).

Maybe a checkbox for this would be right, as in "Stop tracking when computer becomes idle" or "Stop tracking on shutdown".
Comment 1 Ashton Kemerling 2010-01-06 15:46:49 UTC
I looked into this a while ago. The trick is that Hamster merely records beginning time, and ending time; as such there is no real good way to "pause" the tracking. The only option would be to stop tracking once the computer is in standby, and start a new tracking item when the computer comes out of standby. I'll look into the possibility.
Comment 2 Patryk Zawadzki 2010-01-06 15:54:35 UTC
The problem is there is no guarantee of delivering any signals (or being able to handle them) before suspend kicks in. Detecting resume is easy but it won't tell us when the suspend happened (actually, adding the suspension timestamp to the "resumed" signal seems to be the best solution - any kernel devs around?).
Comment 3 Ashton Kemerling 2010-01-06 15:56:00 UTC
Then how do we currently stop tracking during suspend?
Comment 4 Patryk Zawadzki 2010-01-06 16:03:44 UTC
We rely on the signal from power manager... which fails under load when sometimes the machine goes to sleep before you get to receive/handle the signal :)
Comment 5 Aleksandar 2012-02-21 15:54:55 UTC
Why not record current clock time (prev_wall_clock_tm) every-so-often (e.g. time tracker resolution / 2 == T).

Then sleep for T.

In each loop compare prev_wall_clock_tm with the current time; if the difference is > than (T + some_tolerance) then we must have gone through a suspend period. In that case, conclude the previous timing with the prev_wall_clock_tm and start new tracking item.
Comment 6 Toms Bauģis 2012-09-24 18:32:53 UTC
moved https://github.com/projecthamster/hamster/issues/8