5

I've recently installed arbtt which seems to be an intersting, rule based, automatic time tracker. http://arbtt.nomeata.de/#what

I've got it working for the most part, but after 30 minutes or so of gathering stats, I end up with the following error.

Processing data [=>......................................................................................................................................................................................]   1%
arbtt-stats: Prelude.(!!): index too large

Does anyone have any suggestions on ways I can troubleshoot this issue, or better yet, solve it? I have 0 experience with the coding language used to create the rules (Haskell I believe). All I've done to this point is follow the documentation as closely as possible.

This error ultimately renders the tool useless since it doesn't gather data any longer than 30 minutes. To fix it, I have to delete the log and start from scratch. I'm primarily interested in the notion of having a customizable, rule based time tracker but I'm by no means tied to using arbtt.

Based on the comments below, I'm including some more information below.

When I try to run arbtt-recover I get a long list of errors that look like this. All of them seem to be related to an Unsupported TimeLogEntry.

Trying at position 1726098.
Failed to read value at position 1726098:
   Unsupported TimeLogEntry version tag 0

As for the configuration file, here is what I have so far.

$idle > 30 ==> tag inactive,

-- A rule that matches on a list of strings
current window $program == ["Chrome", "Firefox"] ==> tag Web,

current window $program == ["skype"]  ==> tag Skype,

current window $program == ["jetbrains-phpstorm"] ==> tag PhpStorm,

( current window $title =~ m!Inbox! ||
  current window $title =~ m!Outlook! ) ==> tag Emails,

( current window $title =~ m!AdWords! ||
  current window $title =~ m!Analytics! ) ==> tag Adwords,

It goes on further, but I'm fairly confident I've followed this same syntax for all other lines. The rest of the lines are following the same format but are project/client specific for me. If required, I'm happy to include the rest of the file.

MMMTroy
  • 1,256
  • 1
  • 11
  • 20
  • 1
    "All I've done to this point is follow the documentation as closely as possible." Presumably, however, you have customised the [example configuration](http://arbtt.nomeata.de/doc/users_guide/configuration.html) in your tests. If that is the case, can you point out what you have changed? Perhaps there is some mistake in the file which the program does not check for, leading to the crash. (`!!` is a Haskell operator for accessing a position in a list without bounds checking, so what you see is basically an out-of-bounds error somewhere in the program.) – duplode Jul 28 '15 at 03:44
  • 1
    It would be very helpful to have a detailed list of instructions that could be used to reproduce this error. The shorter the better -- but the most important thing is that it starts from scratch and produces the error every time, so that we can play along at home. – Daniel Wagner Jul 28 '15 at 04:02
  • 2
    It might be a data log corruption. Users occasionally report such errors; I never had them. You can run `arbtt-recover` and then move `~/.arbtt/capture.log.recovered` to `~/.arbtt/capture.log` and you will likely only lose one corrupt sample. But that’s just fixing symptoms; the cause is still unknown... – Joachim Breitner Jul 28 '15 at 07:49
  • @duplode I've added some samples from my configuration file within my question. It's not the entire file, but the rest is just more of the same. Let me know if this is enough, or if you need me to include the entire file. – MMMTroy Jul 28 '15 at 20:35
  • @JoachimBreitner I have tried this a few times. I included within my question the error I receive when I run arbtt-recover. After it's completed, I still get the same error when I try to run arbtt-stats. Also arbtt-dump does seem to work most times. – MMMTroy Jul 28 '15 at 20:36
  • N.B.: Joachim Breitner is the author of arbtt, so his comments on this are authoritative. – duplode Jul 28 '15 at 20:37
  • 1
    Did you copy `~/.arbtt/capture.log.recovered` to `~/.arbtt/capture.log` after running `arbtt-recover`? – Joachim Breitner Jul 28 '15 at 20:44
  • @JoachimBreitner after reviewing your answer further I realized I wasn't actually moving the recovered file to capture.log. This fixed it for me and arbtt-stats seems to be running again. Does this mean that one of the entries in my configuration file might be incorrectly setup? – MMMTroy Jul 28 '15 at 20:48
  • No, this is independent of the configuration. It might happen if `arbtt-capture` gets killed too hard in the wrong moment, for example. I’d be interested in a way to reproduce the problem. – Joachim Breitner Jul 29 '15 at 07:12
  • @JoachimBreitner I haven't had this issue happen in about a day now, so I have an idea how you might be able to reproduce the issue. I forgot that I had both a cron that was running arbtt-capture, as well as another console window running the same command. Since I killed it in the console and left it solely to the cron, I haven't had the error since. Perhaps running two instances of arbtt-capture at once creates the issue? – MMMTroy Jul 29 '15 at 18:47
  • “Perhaps running two instances of arbtt-capture at once creates the issue?” quite possible. Why do you run `arbtt-capture` from cron? It runs as a daemon, so you should simply start it with your desktop session – neither from cron nor from the console. – Joachim Breitner Jul 29 '15 at 21:51
  • @JoachimBreitner I was referencing this article when I set that up. http://darcs.nomeata.de/arbtt/doc/users_guide/effective-use.html. It made sense to me to set it up as a cron since in the description it was mentioned "you could also wrap it in an infinite loop to restart the daemon should it ever crash, with a command like". Is this ill-advised? – MMMTroy Jul 29 '15 at 22:25
  • 1
    Ah, using it with cron and `@reboot` should be fine as well. I thought you would run it repeatedly, which should not be necessary. – Joachim Breitner Jul 30 '15 at 07:43

1 Answers1

8

As discussed in the comments: This is a case of a corrupt ~/.arbtt/capture.log. You can usually fix this by

  • running arbtt-recover
  • and then moving ~/.arbtt/capture.log.recovered to ~/.arbtt/capture.log.

The second manual step is required to avoid accidentially deleting too much data. You can test that the recovered file is better by making arbtt-stats using the recovered file by passing --logfile=~/.arbtt/capture.log.recovered to it.

Data corruption happens for example when there is an unclean shutdown, or other undetermined reasons. But the log file format is such that even after a corruption (e.g. a partial write of one sample), further samples will be written correctly and should be picked up by arbtt-recover, so you did not lose more than a few samples.

Joachim Breitner
  • 25,395
  • 6
  • 78
  • 139