I'm starting a new thread because this involves different problems than we've been discussing, on my iMac this time, rather than on my MBP. I've been getting this "system clock. . ." message repeatedly for the past three days (since starting to use v2 on this computer). These are scheduled 1am backups.

Other strange things also seem to be happening. A few files have been "recaptured" for some reason, and yesterday afternoon the app ran a verify action that seemed to start all by itself. One capture died after a "broke stale lock file" entry. I'm sending a Report.

Ralph Strauch wrote:I've been getting this "system clock. . ." message repeatedly for the past three days (since starting to use v2 on this computer).

This is normal. The 2.0 scheduler now monitors the system clock for changes. Whenever it is notified that the system clock has been adjusted, the scheduler reevaluates the scheduled actions. This was to solve a problem of users who change their clock to something way in the future, and then set it back. The result would be actions that wouldn't start again for months, even years, because they were waiting for some future date that was now way in the future.

It turns out that OS X adjusts the system clock all of the time, mostly millisecond changes to keep the clock in sync with NTP. Every time this happens, the scheduler dutifully reevaluates its schedule.

For the most part, these messages can be ignored. It's just the scheduler doing its job. There's a reason these log messages are classified as "minutia." (I might even demote them to "debug" messages, as it turns out they are only rarely interesting.)

Other strange things also seem to be happening. A few files have been "recaptured" for some reason,

Determine why an item was recaptured is a really complicate topic, as there are lots of (sometimes obscure) reasons why an item would be recaptured.

The only definitive way of determining why requires that you first set the QRLogCaptureDecision (Log Capture Decisions) setting to true before the next capture. In 2.0, you can do that in the advanced preferences. When this is set, the capture action will log the reason it captured each item. Warning: this setting can result in a tremendous number of log records. I do not recommend leaving it on.

and yesterday afternoon the app ran a verify action that seemed to start all by itself.

That's a new one. The log should indicate what started that action. I'll take a look at your report.

One capture died after a "broke stale lock file" entry.

We were just discussion that in this thread.