Comments (9)
@nikanar Thanks a lot!
I don't want information duplicated or spread out in a bunch of READMEs so I added that to the documentation (ActivityWatch/activitywatch@c05dac0) and will link to it from the aw-client README.
I committed in your name and will make some further modifications myself.
Closing now.
from aw-watcher-afk.
Oh, and you might find this funny @nikanar.
from aw-watcher-afk.
I modified your code slightly to print the duration as well, try this.
#!/usr/bin/env python3
import aw_client
ac = aw_client.ActivityWatchClient("_")
ac.connect()
bucket = "aw-watcher-afk_johan-laptop2"
events = ac.get_events(bucket, 50)
events.reverse()
for e in events:
print(e["timestamp"], ",", e["duration"], ",", e["data"]["status"])
It's hard to understand the context if you do not print the duration of the events. This is how it looks for me.
Long log
2017-07-11 19:13:53.079000+00:00 , 0:12:40.080000 , afk
2017-07-11 19:26:34.161000+00:00 , 0:00:00 , afk
2017-07-11 19:26:34.161000+00:00 , 0:00:03.039000 , not-afk
2017-07-11 19:26:37.200000+00:00 , 0:15:53.349000 , afk
2017-07-11 19:42:30.549000+00:00 , 0:11:51.299120 , hibernating
2017-07-11 19:54:22.913000+00:00 , 0:00:00 , afk
2017-07-11 19:54:22.913000+00:00 , 0:09:33.739000 , not-afk
2017-07-11 20:04:00.657000+00:00 , 16:13:49.770485 , hibernating
2017-07-12 12:18:03.503000+00:00 , 0:12:48.943000 , not-afk
2017-07-12 12:30:52.446000+00:00 , 0:16:26.395000 , afk
2017-07-12 12:47:19.843000+00:00 , 0:00:00 , afk
2017-07-12 12:47:19.843000+00:00 , 0:00:37.086000 , not-afk
2017-07-12 12:47:56.929000+00:00 , 0:04:38.411000 , afk
2017-07-12 12:52:36.342000+00:00 , 0:00:00 , afk
2017-07-12 12:52:36.342000+00:00 , 0:00:49.101000 , not-afk
2017-07-12 12:53:25.443000+00:00 , 0:03:51.330000 , afk
2017-07-12 12:57:17.775000+00:00 , 0:00:00 , afk
2017-07-12 12:57:17.775000+00:00 , 0:35:38.709000 , not-afk
2017-07-12 13:32:56.484000+00:00 , 0:03:43.311000 , afk
2017-07-12 13:36:40.797000+00:00 , 0:00:00 , afk
2017-07-12 13:36:40.797000+00:00 , 0:06:53.560000 , not-afk
2017-07-12 13:43:34.357000+00:00 , 0:03:42.314000 , afk
2017-07-12 13:47:17.672000+00:00 , 0:00:00 , afk
2017-07-12 13:47:17.672000+00:00 , 0:44:36.415000 , not-afk
2017-07-12 14:31:54.087000+00:00 , 0:07:25.529000 , afk
2017-07-12 14:39:20.618000+00:00 , 0:00:00 , afk
2017-07-12 14:39:20.618000+00:00 , 0:00:23.059000 , not-afk
2017-07-12 14:39:43.677000+00:00 , 0:03:48.251000 , afk
2017-07-12 14:43:32.929000+00:00 , 0:00:00 , afk
2017-07-12 14:43:32.929000+00:00 , 0:00:25.058000 , not-afk
2017-07-12 14:43:57.987000+00:00 , 2:54:02.027531 , hibernating
2017-07-12 17:40:44.256000+00:00 , 0:06:08.493000 , not-afk
2017-07-12 17:46:52.749000+00:00 , 0:09:14.808000 , afk
2017-07-12 17:56:08.558000+00:00 , 0:00:00 , afk
2017-07-12 17:56:08.558000+00:00 , 0:07:01.536000 , not-afk
2017-07-12 18:03:10.094000+00:00 , 0:03:05.236000 , afk
2017-07-12 18:06:16.331000+00:00 , 0:00:00 , afk
2017-07-12 18:06:16.331000+00:00 , 0:37:57.812000 , not-afk
2017-07-12 18:44:15.144000+00:00 , 0:50:56.425404 , hibernating
2017-07-12 19:35:12.603000+00:00 , 0:33:28.495000 , not-afk
2017-07-12 20:08:42.100000+00:00 , 11:34:11.354582 , hibernating
2017-07-13 07:42:55.508000+00:00 , 0:26:52.996000 , not-afk
2017-07-13 08:10:01.520000+00:00 , 0:23:22.251522 , hibernating
2017-07-13 08:33:24.801000+00:00 , 0:52:58.946000 , not-afk
2017-07-13 09:26:24.749000+00:00 , 0:00:33.763687 , hibernating
2017-07-13 09:26:59.546000+00:00 , 0:05:37.423000 , not-afk
2017-07-13 09:32:36.969000+00:00 , 3 days, 7:05:09.746631 , hibernating
2017-07-16 16:37:47.759000+00:00 , 1:33:11.145000 , not-afk
2017-07-16 18:11:01.907000+00:00 , 19:45:40.359956 , hibernating
2017-07-17 13:56:43.332000+00:00 , 0:54:32.106000 , not-afk
In my case, every time there's a not-afk and afk evenet at the same time it's due to aw-watcher-afk asumes that you are afk when the computer wakes from suspend or you start the watcher. It might not look clean and could be fixed, but since the visualization in aw-webui only filters by the not-afk events it doesn't break anything.
Regarding config.timeout
, we rewrote the watchers and aw-server a few months ago to work as heartbeats, and if a heartbeat is missed by more than the timeout time it will create a new event instead of expanding the existing one.
from aw-watcher-afk.
@nikanar We try to never assume anything in the watchers (such as if someone is afk now, we do not assume that they will be afk for 10 more seconds or something like that). And due to how heartbeats work, as soon as something crashes it stops logging so the data should always be correct. However, since the watchers only report to aw-server every X seconds, the last X seconds before a shutdown or crash will go unreported in aw-server (But since the reporting is 15s at max unless you change your config, we do not see this as an issue).
from aw-watcher-afk.
Aah, right, I entirely missed the duration property, and indeed, it clarifies the picture.
So if I understand correctly, afk events of duration 0:00:00 are glitches mostly, and once we remove them, leaving hibernation aside, only remain a series of alternating afk/not/afk/not events, where if e0
and e1
are consecutive events, we have
e0.timestamp + e0.duration == e1.timestamp
.
Then I don't need to understand the config, because this gives the whole picture.
If it is so, then 0-duration events look like a small issue to me, but I can move forward with that knowledge. Thanks :)
But I see in my log that there is one occurrence of two consecutive not-afk events, which there isn't in yours. Running it again, there's such a thing again :
2017-07-16 18:04:20.395000+00:00 , 2:42:51.409000 , not-afk
2017-07-16 20:47:11.804000+00:00 , 0:07:07.764000 , afk
2017-07-16 20:54:19.568000+00:00 , 1:08:34.161000 , not-afk
2017-07-16 22:56:31.960000+00:00 , 0:39:18.139000 , not-afk
2017-07-16 23:35:50.099000+00:00 , 0:03:37.364000 , afk
2017-07-16 23:39:27.463000+00:00 , 0:01:13.126000 , not-afk
2017-07-16 23:40:40.589000+00:00 , 0:07:29.694000 , afk
[... afk/not/afk/not, good.]
What happened between 20:54+1:08 = 22:02 and 22:56 ? That's probably 17-18h in my timezone, other logs say I was not-afk. AW crashed, probably, but wouldn't restarting the watcher introduce a 0-duration afk event ?
Going further down the log yields yet more ugly series of events :
Another log, with durations, for you to explain, please. It's possible that several aw-watcher processes were alive at the same time for a short while (I tend to avoid it, but it happens).
2017-07-14 17:58:24.598000+00:00 , 0:27:26.646000 , not-afk
2017-07-14 18:25:51.244000+00:00 , 0:06:09.640000 , afk
2017-07-14 18:32:01.885000+00:00 , 0:00:00 , afk
2017-07-14 18:32:01.885000+00:00 , 0:37:54.936000 , not-afk
2017-07-14 19:14:29.761000+00:00 , 0:03:23.509000 , not-afk
2017-07-14 19:24:42.399000+00:00 , 0:06:01.657000 , not-afk
2017-07-14 19:30:44.056000+00:00 , 0:04:32.453000 , afk
2017-07-14 19:35:17.510000+00:00 , 0:00:00 , afk
2017-07-14 19:35:17.510000+00:00 , 0:05:41.033000 , not-afk
2017-07-14 19:48:40.904000+00:00 , 0:03:08.379000 , not-afk
2017-07-14 19:55:05.394000+00:00 , 0:01:45.662000 , not-afk
2017-07-14 20:08:51.753000+00:00 , 0:04:03.461000 , not-afk
2017-07-14 20:17:01.156000+00:00 , 0:03:17.564000 , not-afk
2017-07-14 20:36:01.193000+00:00 , 0:02:38.159000 , not-afk
2017-07-14 20:42:24.074000+00:00 , 0:00:12.104000 , not-afk
2017-07-14 21:28:39+00:00 , 0:00:45.166000 , not-afk
2017-07-14 21:35:52.674000+00:00 , 0:01:33.249000 , not-afk
2017-07-14 21:41:06.704000+00:00 , 0:00:08.088000 , not-afk
2017-07-14 21:47:58.883000+00:00 , 0:02:49.631000 , not-afk
2017-07-14 21:50:50.518000+00:00 , 0:06:32.060306 , hibernating
2017-07-14 21:57:23.655000+00:00 , 0:00:27.043000 , not-afk
2017-07-14 21:57:50.698000+00:00 , 0:01:27.185701 , hibernating
2017-07-14 21:59:18.939000+00:00 , 0:08:26.776000 , not-afk
2017-07-14 22:07:51.724000+00:00 , 4:29:12.043762 , hibernating
2017-07-15 02:37:04.792000+00:00 , 0:08:19.757000 , not-afk
2017-07-15 02:45:24.549000+00:00 , 0:03:19.337000 , afk
2017-07-15 02:48:44.888000+00:00 , 0:03:00.298331 , afk
2017-07-15 02:48:44.888000+00:00 , 0:00:00 , afk
2017-07-15 02:48:44.888000+00:00 , 0:00:00 , not-afk
2017-07-15 02:51:46.223000+00:00 , 3:34:49.910000 , afk
2017-07-15 06:26:37.135000+00:00 , 0:00:00 , afk
2017-07-15 06:26:37.135000+00:00 , 0:02:21.365000 , not-afk
2017-07-15 06:28:58.500000+00:00 , 3:06:29.947000 , afk
2017-07-15 09:35:29.448000+00:00 , 0:00:00 , afk
2017-07-15 09:35:29.448000+00:00 , 0:00:37.148000 , not-afk
from aw-watcher-afk.
from aw-watcher-afk.
Additional question is "what happens when logging is abruptly interrupted ?", like killall aw-qt
. Up to when are the buckets correct ? The crash moment or the start of the last event ? Does something remain in an interupted state, and what happens to it when AW is restarted ?
from aw-watcher-afk.
@nikanar Can we close this?
If there is any specific documentation you feel would be useful, please give me a brief list and I'll see what I can do.
from aw-watcher-afk.
What follows is made up of shots in the dark based on my expectations. Please review closely! (and move where it belongs)
Q : How to programmatically use this ActivityWatch thing ?
A : Look in the aw-client
repository.
Q : How to understand the data that is stored ?
A :
Get some events with
ac = aw_client.ActivityWatchClient("")
ac.connect()
events = ac.get_events(<bucket_name>)
Events from the aw-watcher-afk bucket have the fields ['timestamp']
, ['duration']
, and ['data']['status']
. The status can be one of afk
, not-afk
, or hibernating
. If e0
and e1
are consecutive events, you should expect
e0['timestamp'] + e0['duration'] == e1['timestamp']
(within some milliseconds) and report issues when it is not the case. Actually this is only true for aw-watcher-afk, because aw-watcher-window doesn't record anything when afk or asleep.
In principle, afk
and not-afk
events alternate, but there are currently many edge cases where it doesn't happen.
Not two events should cover the same moment, but right now in some cases hibernating
events overlap entirely with some afk
events.
Q : How to determine bucket name ?
A : <name of watcher>
(one of aw-watcher-afk
or aw-watcher-window
) + _
+ <name of your machine>
(how to determine ? look in "activity" tab)
Q : What happens when AW is down or crashes ?
A : Stored data up to the crash is not corrupted (up to few seconds before). When AW is restarted, it will first register a not-afk
event. Several not-afk
can come one after the other if AW is interrupted in between. No data will be stored when AW is off.
Q : What happens when my computer is off or asleep ?
A : When asleep, aw-watcher-afk will record a "hibernating" event. aw-watcher-window will record nothing, i.e. some event's timestamp+duration will not match the following event's timestamp. When turned off, no data is logged. (is this true ? does the afk watcher record "hibernating" ? if not, why not ?)
Q : Some events have 0 duration. What does this mean ?
A : It's a glitch (caused by 3 consecutive heartbeats having different data ?).
And I guess it should mostly go in the aw-client README, with some things being specific to watcher-afk or -window (like the 100% expected coverage of time and the "unknown"/None windows I didn't mention), maybe these can be repeated in their respective README/docs.
from aw-watcher-afk.
Related Issues (20)
- Crash on suspend HOT 2
- Odd behavior after suspend HOT 2
- Add support for gamepads HOT 1
- Hibernation and afk events sometimes heavily overlap. HOT 15
- Keeps sending afk events if xserver is restarted HOT 2
- Use macOS API directly to detect input (instead of PyUserInput) HOT 2
- Incorrect AFK detection HOT 4
- Fail to build for developer install HOT 1
- Detect when audio is active HOT 4
- Custom watcher visualization not working as expected HOT 2
- Avoid detecting AFK when watching a video in chrome HOT 1
- Replace pyuserinput with pynput
- No Documentation: Mofify the data manually
- [bug] aw-watcher-afk over freerdp HOT 3
- document the default `timeout` better HOT 2
- Movies count as AFK(?) HOT 1
- Data is often doubled with two events starting at same timestamp but different durations HOT 1
- Apps shown as AFK despite configured as "always count as active pattern"
- [macOS] Set state to AFK when screen is locked or computer is asleep HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aw-watcher-afk.