Procrastitracker started to drastically undercount time.

[solf]

I've used Procrastitracker and it used to work just fine.

However something happened now (and I didn't update the system and can't even think of any changes I might've done except maybe for video drivers update) and it started to drastically undercount the time.

Like looking at the last 7 days, for example, one day has 10+ hours (which is in line of what I'd expect, as I use computer for both work & entertainment) and other days are between 3-4 hours (which is drastically lower than what I'd expect).

Is there some logging that I can enable to see what's going on or something?

P.S. Also -- whether related or not -- I've noticed now that the UI would completely hard-lock and crash the application if I leave it open (I mean the statistics window), it happened just now while I was writing this ticket because I had it open and switching back-and-forth to get statistics data for the last 7 days.

P.P.S. Right now it's using the latest version (I've updated when I've noticed the problem) -- May 1, 2025; and this is on Windows 10 Home 21H2 (yes, like I said, I'm not updating my system).

[aardappel]

The only cases of "missing time" I've ever noticed in the past were certain games.. my guess was that they were getting mouse/keyboard input in a way that bypasses PT and thus stopped counting after a while, but I am not sure.

First step would be to see if on the days where you expect 10 hrs but got 3-4, what application was missing? Or were all uses scaled down equally, even web browsers etc?

Another thing to check is the advanced settings, to see if "idle time" didn't accidentally got set to 0 or something. It defaults to 180 I think. It indicates how long it will still track time after the last keyboard input / mouse movement.

[solf]

On the low count days Firefox seems to be entirely missing (like barely a few minutes total listed) and other stuff (e.g. games) seem to be scaled down drastically.

Advanced settings seem fine (5 sec sample, 300 sec idle, and other stuff seems to be fine as well).

I think realistically some kind of debug logging is needed to figure what's up, I take it from your response that it's not really available?

[solf]

and re-reading your comment -- what's that about mouse/keyboard input? I do, in fact, use Autohotkey extensively, but it didn't ever seem to be the problem before?

[aardappel]

No, there's no special tools or logging present in PT, because well, we've never had such problems (in the case of the few games where it happened it usually was noticed much after the fact and never felt like debugging it :)

Autohotkey inserts input events but I'd hope it doesn't block normal ones. It may use the same input hooking technique that PT uses though, so not impossible there is interference there.

Firefox missing seems really weird yes.

You could run some tests. With your current setup, read an article or watch a vid in firefox for 10 mins or whatever (while occasionally moving the mouse), see if that particular url is represented correctly. If its not, try the same without Autohotkey (disable it, reboot), etc.

[solf]

That seems like it may well not produce any particularly useful results. Are the instructions on how to build PT still valid? I might try doing that instead to see if I can use AI to add some logging.

[aardappel]

Yup should be.

[solf]

So the issue has to do with browser stuff DDE (firefox; possibly in combination with weird symbols in title). This seems to be both the cause of not-tracking-properly and UI crashes.

The fork is here: https://github.com/solf/procrastitracker

• Adds debug logging
• Disables (via flag) browser DDE completely
• Adds option to exclude stuff from tracking (by exe or by title)
• I had issues losing the entire DB data during crashes or smth, so attempted to make it more bullet-proof
• Fixed (hopefully) rare race condition which sometimes causes idle to be detected when it's very much not idle

I am a software engineer, but I basically don't know c/cpp and I definitely don't know windows threading/thread-safety stuff.

The code was written by cursor-ai, it looks passable to me (and I did get it to rewrite various clearly stupid things it first tried) but I have no idea if the code is properly thread-safe and otherwise 'good' in terms of c/cpp & windows threading.

[aardappel]

Ok, that is a lot of extra code.. we'll need a PR for each feature individually to consider if it can go in, and I don't think we want these extensive AI generated docs for each. The smaller the change, the more likely I can merge it.

And it is also not clear from your description what the actual original problem is:

• Are you saying that if you don't interact with FireFox with DDE then time tracks correctly?
• Did we maybe just get an update from Firefox that changes how its DDE works that broke this?
• Should we instead investigate what that change is and if it can be fixed?
• Because if you disable DDE, you don't get URLs anymore, which PT has always relied on to get more detailed time tracking from browsers (since url is more significant than window title) ?

[solf]

The comments in the code state basically that DDE doesn't work and hasn't worked for a long time for any of the major browsers. Including firefox and chrome (there's some other path for chrome urls I think).

I can confirm that it hasn't really worked for me for a LONG time (I didn't really pay attention, but recent history doesn't have URLs).

If URL tracking works for you, I'm guessing you're using chrome and that 'other path' works for you.

As for the rest -- I'm unlikely to spend an effort creating individual PRs. It's something I knocked out in a couple of hours using AI just to resolve the issues I've long had with PT (and in particular this latest "basically doesn't work" issue). You're welcome to use any or none of this. There aren't really that many changes and they should be isolated to an individual set of commits for the most part.

[aardappel]

I still get correct URLS in chrome, yes.

I also don't have time to sort this all out, and don't think we can merge this as-is, so we'll leave this open for a future effort.

[solf]

Sure.

To make things a bit easier -- here's the version with debug logging removed, so it's easier to see what logic was changed -- https://github.com/solf/procrastitracker/tree/no-debug-log

[lslatr23]

The database is broken : If some windows names contains some characters or sequences (i could not identify which ones, maybe some UTF8, or unicode or I dont know), the database gets truncated somehow. I'am 100% sure of this, but I was not able to debug it. Could we maybe let AI try to check the code? How could I do that?

[aardappel]

You can use AI all you want, but at the end of the day there needs to be a human submitting a PR that they have full understanding of every last detail.

If you submit something that AI made and you have no idea, you put all the work of reviewing on me.. that is not acceptable.