search

Hoglet / TimeIT

The unobtrusive time tracker
GNU General Public License v3.0
19 stars 7 forks source link

When idle quiet then a flood of zero length entries every 20 seconds #23

Closed srguiwiz closed 3 years ago

srguiwiz commented 3 years ago

After or while investigating issue #22 I decided to run a build from master in Ubuntu 20.04. That is more satisfactory.

There is however, a specific problem.

Have set quiet. For testing, have set idle to three minutes. Then, when idle the list gets flooded with three entries per minute, apparently zero length.

The usability problem are hundreds of those zero length entries between the few actual work entries. The total work time shown is right, but one couldn't easily read "from when to when did I work". And also it floods the database with useless zero length entries.

As I'm looking at IdleDetector.cpp I see a line if (idleSeconds < 20) and that matches the three entries per minutes.

[updated strikethrough because wrong] So far that is factual reporting. Now I am starting to guess, please let me know if right or wrong looking there: I am looking at if (now - lastPoll > 30) and am wondering whether that should be <=. I will try that in a build. But I thought I'd report what I found so far, in case you recognize the actual problem faster than I can.

Getting this to be usable in Ubuntu not only serves a purpose for me immediately in itself, but also as a stepping stone towards maybe then figuring CentOS 8.

srguiwiz commented 3 years ago

Now I recognize that flood of zero length entries while idle, one every twenty seconds, may only be in the UI of showing entries, but not in the database.

I found out because after quitting the application UI, killing the process, uninstalling one build and installing another build, then only the good time spans show in the list for that day, from the earlier run.

srguiwiz commented 3 years ago

Updated issue above because the guess with <= 30 was not useful. The problem is with the UI showing zero length entries.

The workaround is killing the process, for example with pkill timeit or if you are more cautious with pgrep timeit and a kill. When launching TimeIT again, then one can read the actual time spans worked.

Quitting the application UI is not enough to achieve the same goal.

Hoglet commented 3 years ago

low/zero length time spans can occur by different reasons and are removed at next start. Please continue searching, maybe you find out what is happening.

srguiwiz commented 3 years ago

Would be awesome if it removes them when opening a detail view, so the user would be able to report when they worked.

Maybe more efficient to not even enter zero length entries? 12 hours of a machine sitting idle could be 2160 zero length entries.

Hoglet commented 3 years ago

Additional note: The zero length time spans ARE in the database as the UI is "always" showing what is in the database. The exception is before committing something manually edited..

Hoglet commented 3 years ago

Would be awesome if it removes them when opening a detail view, so the user would be able to report when they worked.

Maybe more efficient to not even enter zero length entries? 12 hours of a machine sitting idle could be 2160 zero length entries.

Yes, I agree and I think that something is really wrong as I have not observed the behaviour. It did happen before when moving between workspaces.

I think that closing a time span should also check if it is of a reasonable length. You should look in TimeKeeper.cpp and see how it handles it

srguiwiz commented 3 years ago

Question 1: Do you think you could comment some of the code, for example in IdleDetector.cpp, so it would be somewhat easier for an additional person [yours truly] to work on this problem?

Not trying to get you to do "real work", rather thinking you may recollect what you thought certain code, conditionals, etc. were meant to do, and if you put it into comments that would make it easier to debug now.

I appreciate what this application does. Simplicity is a virtue.

Question 2: Are you using a specific debugger or IDE? I am embarrassed to say, while that used to be my forte, I haven't on this platform for this programming language, so I am wondering in case you do, which one?

In case I don't keep up debugging this, I have come to live with the workaround. But, I would read newly commented code.

Hoglet commented 3 years ago

Answer 1: Yes, I can maybe comment some things but I think that it is probably better that I write the code so it is clearer instead.

Answer 2: I am using CLion at the moment and was before using Eclipse.

We can also have some closer sessions and do some pair programming if you like. I am using Discord for my hobbies so you could join there. Invite: https://discord.gg/MV6YEnRC

srguiwiz commented 3 years ago

Great. I can agree. I avoid committing to a specific schedule at this time.

Meanwhile I have submitted a PR that fixes an obstruction in the installation process in Ubuntu 20.04.

srguiwiz commented 3 years ago

If you annotate IdleDetector::pollStatus() with comments I could do some more thinking or experimenting when I get to it.

Hoglet commented 3 years ago

Problem is identified. Working on a redesign.

srguiwiz commented 3 years ago

For the record, the problem analysis has been, as observed in version 2.0.1: In Controller::on_idleDetected() when satisfying if (quiet) a call to on_action_revertAndContinue() causes a twenty second cycle; in which ten seconds each are alternating states, one state starting after IdleDetector::pollStatus() satisfying enabled && idleSeconds > idleTimeout causing isIdle = true, the other state after on_action_revertAndContinue() via timeKeeper->enable(true) via IdleDetector::reset() causing isIdle = false.

Therefore this would only occur when using Quiet Mode, and only would become annoying if trying to look for time spans in Show Details.

As mentioned, as a workaround, a flood would be cleaned up on an application restart, either a machine restart or a kill of the timeit process and launching it again.