search

aardappel / procrastitracker

a Windows time tracking application
http://strlen.com/procrastitracker/
500 stars 53 forks source link

Data over 30 days ago ignored #38

Closed VelocityRa closed 6 years ago

VelocityRa commented 6 years ago

Hello, thank you for this very useful piece of software.

I've been experiencing a bug: The database files are there, yet procrastitracker doesn't read anything before ~30 days. (I did set it to "All Time"). I remember a while ago it wouldn't read anything before 2 to 3 months, I think. Now it's 30 days.

Also all my tags have reset (again), but I guess that's a different bug. Maybe I'll open a new Issue.

I've built it locally, if you want me to use the debugger for anything.

Thanks.

aardappel commented 6 years ago

That sounds weird. Not a bug I've heard of before, nor something that I have a hunch for what code could cause it.

Actually, I have one hunch: there's code that prunes part of the DB on load, to join entries with very few seconds with their parents, to keep the DB small. But there is no code in there that checks for date ranges or anything. This is in nodedb.h:load().

One thing to try first, go to where your database files are stored (link from the start menu), and you should see dated backup files, depending on how often you restart your computer or PT. Look at the dates and the sizes. If there is a particular date at which the file became a lot smaller, then that's where your data got pruned?

If the DB never got smaller, it may mean that the data is still in the file, but simply always filtered for display. The code that relates to display and filtering is e.g. in node.h:accumulate(), in particular in day_is_in_filter() it checks if it is inside the date range. You could add code in there that remembers the earliest day that is the DB (smallest value for o), then compare that against starttime to understand more of what is going wrong.

VelocityRa commented 6 years ago

The DB did get smaller, there's a jump from 233KB -> 27KB, about a month ago. All entries after that are also small, slowly increasing (and some times decreasing, but not as much). Should this pruning happen? I don't understand the point.

Edit: Also happened in late 2017 where it went from 146KB -> 8KB.

aardappel commented 6 years ago

With that big a jump in size another theory is that maybe at that date it wasn't able to load the old DB at all and started a new one from scratch.

If that is the case, the 2 DBs are non-overlapping, so you could use the merge DB feature (in the popup menu) to merge in the old one. Back up your DB files before attempting :P

Not sure what would cause that to happen though.

You could try loading the old DB to see if the data in there is not corrupted somehow.

VelocityRa commented 6 years ago

Merging works fine, apparently, I went through and merged in every place that broke, by finding the last day that there's records of and merging the database before that. Created a final db of 421KB.

Thank you for your help! You can close this if you want, since it looks like it's a rare bug and not related to db corruption? Really hard to debug anyway, I'd imagine, we have no way to repro.

A question: Are tags saved in the .db file, or somewhere else? It's the second time (I think) that I've lost all those too which kinda sucks since I had lots.

aardappel commented 6 years ago

Yes, I suspect somehow the database read failed.. hard to tell why.

Tags are saved in the DB yes. It may have ignored them on merge..