Inconsistency in tracked times

[gsabater]

First of all, i don't know if I should post this here, or in the activitywatch repository, or in the forums.
Anyway, feel free to move the post where you think.

I have been using activity watch with vscode watcher for some time in addition to wakatime, and I have found the following inconsistencies.

Let's take today as an example.
First, in aw, the tracked (non afk) time for vscode is 52m, (1h20m total time with afk time)

Then, the time tracked by vscode-watcher is 22minutes.
From those 22minutes, the time tracked by project is the following:

Now in wakatime, i know their heartbeats are more spaced than activitywatch, but their tracked time is pretty different. 1h47min in total, with this project time:

Thanks for your time

[johan-bjareholt]

I think this is both a case of wakatime being a bit too inclusive and us being a bit too exclusive.
The window time should be accurate, so if it's significantly different from the editor activity something is fishy.

I am maintaining the aw-watcher-vim watcher as well and that has the same issue as this one that it is not inclusive enough I believe and I have some guesses on why, but this one I'm not sure. We would have to investigate a bit to find out.

[gsabater]

Thanks for answering @johan-bjareholt

I don't know how your extension or the wakatime extension works, but as far as I know, aw-watcher sends a heartbeat per second, while wakatime sends a heartbeat every 15 minutes? That could be a reason of why wakatime logs much more time.

So, according to you, the most accurate times would be in window, right? That's good to know.

If I can help with anything, just let me know.

[johan-bjareholt]

I don't know how your extension or the wakatime extension works, but as far as I know, aw-watcher sends a heartbeat per second, while wakatime sends a heartbeat every 15 minutes? That could be a reason of why wakatime logs much more time.

So, according to you, the most accurate times would be in window, right? That's good to know.

Correct, that's why I think WakaTime is overshooting while we are undershooting. The window times should be very accurate, if we are far off from them the editor activity is inaccurate.

There are three things which impact the lengths of the editor events and that is:

• The heartbeat pulsetime: 20s
• The heartbeat frequency: 1s
• The event emitters which requests a heartbeat: https://github.com/ActivityWatch/aw-watcher-vscode/blob/master/src/extension.ts#L55

The pulsetime looks good, the frequency is very often so my first guess would be that our emitters are not good enough and need to be more varied for more types of actions within vscode.

EDIT: Maybe we should increase the heartbeat pulsetime as well, not sure. Will do some testing on aw-watcher-vim what a sane pulsetime for editors is.

[gsabater]

Frequency looks good to me, it's high but sends data to a local machine so it should be okay.
I think that pulsetime is a little low, as a lot of times a dev can be reading code, or looking something for more time. 45-60s feels more natural to me.

Maybe you could see at which events are registering other trackers like wakatime or software.com
I have seen other events there: onFileCoding onActiveFileChange and onIntentlyWatchingCodes

[johan-bjareholt]

I think that pulsetime is a little low, as a lot of times a dev can be reading code, or looking something for more time. 45-60s feels more natural to me.

@gsabater That depends on how you want to define what time spent coding means. To us (ActivityWatch devs) it means time spent using your editor. If you read code inside your editor that should count (and probably will as you usually move your cursor), if you read documentation in your browser for a longer period of time that should not be included as that would just be a wild guess. If someone wants to have a longer span (for example want to know if they have touched their editor for the past 5 minutes) that could be done through a custom ActivityWatch query afterwards, so we'd prefer to have slightly lower pulsetimes as the "raw data" should be as raw as possible and interpretation and visualization of the raw data then should be possible to do in many different ways.

Maybe you could see at which events are registering other trackers like wakatime or software.com
I have seen other events there: onFileCoding onActiveFileChange and onIntentlyWatchingCodes

Yep, this is probably what we should start with doing and then see what the result becomes. If that's not enough we should consider increasing the pulsetime.

[notaustil]

Hi there, noticed the exact same issue today. The window watcher is right with 1h41min of work with VSCode while the vs watcher is way behind at 51min. The problem is extremely apparent on the timeline view :

I'm using Activity Watch 0.8.3 & the VS Plugin 0.4.0.

[johan-bjareholt]

@Austil hm, yes in that timeline screenshot it's clear that you are not afk and constantly using the vscode, very likely an issue with how the watcher reports.