Significant differences between reporting of aw-server and aw-server-rust

[nicolae-stroncea]

I looked at my events for a day a month ago, and there are a couple of significant differences between what aw-server-rust and what aw-server reports.

Not sure if it's due to the migration or one/multiple transform issues.

1. Individual application time:

Application	aw-server	aw-server-rust
Firefox	48m26s	46m38s
Chromium	38m41s	9m31s
Gedit	9m	8m57s
Guake	1m	1m35s
Unknown	14s	15s

Note: Individual application time seems to vary everywhere, and in all of the tabs.

2. Total Active time

aw-server	aw-server-rust
1h 38min	1hr 6 min

3. Active browser time in Browser tab:

aw-server	aw-server-rust
1 hr 21 min	52 min

Another potential bug: If you sum up ALL of the times for each browser domain, they won't be equal to the total active browser time for aw-server-rust. This issue doesn't occur for aw-server.

4. Top categories amounts are also all very different between the 2 servers. This however, is expected given point 1.

5. Timelines look the same(from a high level view)

OS: Fedora 32, Gnome 3.36, Xorg

[johan-bjareholt]

Are you running the latest master or the last pre-built binary from 0.9.2?
And did you do this while running both at the same time or was if after migrating from one to the other?

1. Individual application time:

The individual application time for chromium worries me a lot, the other ones seem to be fine.

2. Total Active time
3. Active browser time in Browser tab

The total active time query is pretty simple, shouldn't be too hard to find out where they differ here.
The flooding algorithm are quite different between aw-server-python and aw-server-rust, but they are supposed to have the same output so somethings likely wrong there is my guess.

Not really sure why they are so mure more different in browser active time than afk active time though.

Another potential bug: If you sum up ALL of the times for each browser domain, they won't be equal to the total active browser time for aw-server-rust. This issue doesn't occur for aw-server.

Definitely an issue as all browser events have a domain.

Timelines look the same(from a high level view)

The timelines do not do any transformations at all and only shows raw events, so that's good at least.

[johan-bjareholt]

I have completely different results (but don't use chromium, so that might make a difference? Maybe? I don't know)

Exported my main database (from aw-server-rust) and imported it into aw-server-python and here are my results (running aw-server-rust master, aw-server-python master and aw-webui master on both):

rust/python

• Total active time: 4h / 4h 1s
• firefox usage for that day: 2h 13m 56s / 2h 14m 11s
• URxvt usage for that day: 1h 38m 12s / 1h 38m 8s
• active browser time for that day: 2h 13m 52s / 2h 14m 7s
• time on domain github.com: 1h 21m 24s / 1h 24m 6s
• Active editor time: 56m 3s / 56m 31s

notes:

• aw-server-rust seems to discard the domain "127.0.0.1:27180"
• I have not calculated the total of the domains, but they certainly seem to be way off (but seem to do so on both aw-server-python and aw-server-rust, aw-webui issue?)

So i definitely need to look into why the total of the domains are way off at least, that one is critical (possibly caused by ActivityWatch/aw-webui#203 maybe?)

[johan-bjareholt]

I calculated how much the domain time was off and it was about 12% off (2h14m total, manually summing domains was 1h57m).
It is the same on both aw-server-rust and aw-server-python.

[nicolae-stroncea]

Are you running the latest master or the last pre-built binary from 0.9.2?
And did you do this while running both at the same time or was if after migrating from one to the other?

So i definitely need to look into why the total of the domains are way off at least, that one is critical (possibly caused by ActivityWatch/aw-webui#203 maybe?)

I'm running it on 0.92 without any changes/customizations, therefore I don't think it's vityWatch/aw-webui#203. I also ran them one at a time to record the changes.

[nicolae-stroncea]

I compared data on 5 different days.

• The biggest difference between apps that weren't Chromium was 3-4 minutes. In your previous comments that didn't surprise you. Why is there a difference at all?
• It seems I captured the day where Chromium was misbehaving by complete chance. On the other days Chromium is within a reasonable difference on aw-server-rust and aw-server, so I'm not completely sure it's a Chromium problem, might just be a problem that happened to Chromium in that instance.

Here's the Chromium events reported on that day from Top Applications and Top Browser Domains

Window Title	aw-server	aw-server-rust
Messenger-call Chromium(opened in a new call-specific window(not sure what the term for those are)	10m 7s	1m 36s
Facebook	17m 23s	1m 39s

And then a bunch of others that show up in the top 20? for aw-server but not for aw-server-rust, so their recorded time was less than 1min. These events were (~4min) in aw-server

[nicolae-stroncea]

I tried to compare weekly aggregations. Here's what I found( I only put the top 4-5):

Week 1:

application	aw-server	aw-server-rust
Total time	27h 3m	24h 22m
Firefox	17h 13 m	15h 31m
Code	4h	3h 14 min
Chromium	50m	48m
Tilix	52 min	47 min

Week 2:

application	aw-server	aw-server-rust
Total time	27h 30m	24h 55m
Firefox	16h 41m	15h 5m
Gedit	6h 2m	5h 28m
Code	1h 2m	1h 2m
Chromium	41m	40 m
Nautilus	40m	35 m

Week 3:

application	aw-server	aw-server-rust
Total time	47h	46h 7m
Firefox	25h 33m	25h 5m
Code	10h 14m	10h 14m
Gedit	5h 40m	5h 37m
Tilix	1h 38m	1h 32 m

[nicolae-stroncea]

Some more observations:

• Previously aw-server-rust migrated all of the events automatically. I deleted all buckets, and instead exported them from aw-server and imported them into aw-server-rust using the Import/Export functionality. The results were identical for aw-server-rust (across the summations for the 3 weeks)
• Tried to run aw-server-rust in testing( by calling the aw-server-rust executable with --testingbut it still binds to port 5600. Is this a bug?

[johan-bjareholt]

The biggest difference between apps that weren't Chromium was 3-4 minutes. In your previous comments that didn't surprise you. Why is there a difference at all?

The implementations are not identical (even though very similar for most transforms).
Things like the flooding algorithm is completely different but when I made it I think the output should be the same but I'm not certain.
Some bugs are even fixed (such as when fetching events when there are events close to the next day now behaves correctly) and some new ones are likely added but not found yet.
Wasn't the worst one 2 minutes out of 49min? 2min out of for example 49min is about 4% which is indeed more than I expected, but I wouldn't say that I'm surprised.
Not sure why yours are so much more off than mine though, for me for example firefox was 15 seconds different over a total of 2h 14min for example.

I tried to compare weekly aggregations. Here's what I found( I only put the top 4-5):

Week 1 and 2 are on average about 10% off while week 3 is about 2%. I wonder why.

Tried to run aw-server-rust in testing( by calling the aw-server-rust executable with --testingbut it still binds to port 5600. Is this a bug?

It is a bug on 0.9.2 but which is fixed on master. There are lots of changes on aw-server-rust since 0.9.2.

[nicolae-stroncea]

Wasn't the worst one 2 minutes out of 49min? 2min out of for example 49min is about 4% which is indeed more than I expected, but I wouldn't say that I'm surprised.

In one of my days, aw-server-rust reports github(which was on Firefox) as: 20m 1 s, and aw-server: 23m 21s for Top Browser Domains, which is a 15% difference

[johan-bjareholt]

In one of my days, aw-server-rust reports github(which was on Firefox) as: 20m 1 s, and aw-server: 23m 21s for Top Browser Domains, which is a 15% difference

Not worse than for vscode on week 1 which was at 18.75%.
On week 2 and 3 however the same application was perfect.

[nicolae-stroncea]

I queried the actual databases for the day when Chromium was reported 38 minutes(server) and 9 minutes(server-rust):

Number of events:

Aw-server:
SELECT count(id) FROM eventmodel where timestamp LIKE "2020-06-16%" and datastr LIKE "%Chromium%";
157

Aw-server-rust:
SELECT count(id) FROM events WHERE starttime > 1592265600000000000 and starttime < 1592352000000000000 and data LIKE "%Chromium%";
157

Total time reported by database:

Aw-server-rust
SELECT sum(endtime-starttime) FROM events WHERE starttime > 1592265600000000000 and starttime < 1592352000000000000 and data LIKE "%Chromium%";

4131272999985 nanoseconds = 1hr 8 m 51 s

Aw-server
SELECT sum(duration) FROM eventmodel where timestamp LIKE "2020-06-16%" and datastr LIKE "%Chromium%";

4131.273 seconds = 1hr 8 m 51 s

EDIT: afk-buckets for that day are also identical

[johan-bjareholt]

@nicolae-stroncea So with that in mind there's nothing wrong with the migration, but with the query language or the transforms.

So you can instead write a custom query which tests each step and compare between aw-server and aw-server-rust to see where it differs the most.
Here's an example you can put in the query explorer which returns each step, might need some small tweaks though, works on my machine at least

afk_events = query_bucket(find_bucket("aw-watcher-afk_"));
flooded_afk_events = flood(afk_events);

window_events = query_bucket(find_bucket("aw-watcher-window_"));
flooded_window_events = flood(window_events);
window_events_chromium = filter_keyvals(flooded_window_events, "app", ["Chromium"]);

intersected_events = filter_period_intersect(window_events_chromium, filter_keyvals(afk_events, "status", ["not-afk"]));
merged_events = sort_by_duration(merge_events_by_keys(intersected_events, ["app", "title"]));

RETURN = {
    "afk": sum_durations(afk_events),
    "afk_flooded": sum_durations(flooded_afk_events),
    "window": sum_durations(window_events),
    "window_flooded": sum_durations(flooded_window_events),
    "window_chromium": sum_durations(window_events_chromium),
    "intersected_events": sum_durations(intersected_events),
    "merged_events": sum_durations(merged_events)
};

[nicolae-stroncea]

Don't think the query works for me(everything below is for aw-server):

Interestingly enough, the default query doesn't work at all.

afk_events = query_bucket(find_bucket("aw-watcher-afk_"));
window_events = query_bucket(find_bucket("aw-watcher-window_"));
window_events = filter_period_intersect(window_events, filter_keyvals(afk_events, "status", ["not-afk"]));
merged_events = merge_events_by_keys(window_events, ["app", "title"]);
RETURN = sort_by_duration(merged_events);

I will press the button, and it won't return anything. Checking the developer console, or the aw-server doesn't show anything either

Any ideas on what might be wrong?

[nicolae-stroncea]

@johan-bjareholt I anonymized all of the data for the day with the big difference between Chrome on aw-server and aw-server-rust, and sent you the buckets on the forum in a PM.

You should be able to directly import the file from the aw-webui

EDIT: To get the exact times as I'm getting, you might also need to set your timezone to America/Toronto (UTC-4)

[johan-bjareholt]

@nicolae-stroncea The result looks correct, you just need to select the "Raw JSON" mode as it's not returning events but a total duration in seconds. Sorry for not explaining that.