Due or Flagged View not Updating
 

I leave a perspective open all the time that has all items that are due today or flagged. Sometimes, especially after putting the machine to sleep, the view does not update overnight to include the new items that are now "due today". If I look at another perspective, they are dated correctly, but they are not the color of due today items either.

It seems as if they are somehow not being included in the update to what is Due Today. I remember having this problem a while ago, but thought it was fixed with one of the point releases.

The only resolution appears to be restarting OF.

Is there some other way to get the app to "touch" these items and bring them into the perspective without restarting the app? Is this a known bug? Thanks for any feedback.

What happens if you bring up another window? Does it have the missing actions included and styled properly? I wonder if the issue is as simple as being asleep when the date changes causes the view not to be recomputed...

No - a new window doesn't help.

I was informed by Omni that this is a known bug.

I am really surprised that this isn't affecting a lot of people. How are people getting around this issue? All of my Due items are not updating as being Due every day, and I have to remember to relaunch Omni every morning.

This doesn't seem like Omni's usual quality control, but maybe I am missing an easy workaround...

It's not really a workaround, but I just don't sleep my machine overnight. I have the display set to sleep after a few minutes of inactivity, but the machine set to never sleep. The main reason I don't sleep the machine is that I have cron jobs and other backup scripts that run overnight.

Do you put your machine to sleep manually, or do you just let it fall asleep on its own? If you're doing it manually, you could use an Applescript. The script could exit OF, then put the machine to sleep. That would hack around the problem of forgetting to relaunch OF in the morning. It's admittedly a kludge, but would get you by until Omni fixes the bug.

Thats a good suggestion for the AppleScript - I may give that a shot.

I can't not sleep my machine - I tested the power draw on it once, and it is costing $10/month to run in electricity. I am hoping Apple comes out with quad-core iMacs at some point so I can replace it with a more power-efficient version.

Thanks for the script suggestion!

[QUOTE=wolfneuralnet;62997]Sometimes, especially after putting the machine to sleep, the view does not update overnight to include the new items that are now "due today".[/QUOTE]

Oh! Sorry, I don't think I'd ever seen "especially after putting the machine to sleep" associated with this bug before. In our database, it simply talks about how the Due Soon views sometimes won't update until view is refreshed somehow—but every time I've tried to reproduce this bug those views have refreshed on schedule for me, and without being able to reproduce the bug I wasn't sure how to try to solve it (other than to take some random stabs in the dark, hoping something will help).

But it sounds like the problem was that I wasn't putting my machines to sleep! Now that I know that's part of the issue, hopefully this will be much easier to track down. (My apologies to anyone else who'd already reported this detail in their own bug reports!)

Thanks Ken - that makes sense. I knew there must be something preventing you guys from addressing it quickly. It is very reproducible for me when the machine is put to sleep overnight.

Perhaps there is a way to to listen for the wake from sleep in OF and get it to check that the items are updated properly.

Glad we are making progress! Trying to save some money and be a little "green" at the same time here :)

[QUOTE=wolfneuralnet;63400]
I am really surprised that this isn't affecting a lot of people. How are people getting around this issue? [/QUOTE]

It's affecting me! Only workaround, restart OF...
Waiting for a fix by the Omni people
:-)

The issue appears to be limited to those who sleep their computers, unless I've missed something. If you're going to put your computer to sleep to save some energy, why not shut it down and save even more, plus have a freshly started copy of everything in the morning? Reduces problems with memory leaks, this bug becomes a non-issue, and you can set the system to boot itself at a specific time so it is ready to go when you are.

I have a different solution: I use it around the clock, and if I'm not sleeping, my computer isn't going to be either :-)

This bug has just bitten me again today (missed an action to get my niece a birthday card) :-(

I reported this to the 'support ninjas' some months back, highlighting the fact that 'sleeping' the computer was involved. Any further news on being able to reproduce/fix?

[QUOTE=MikeM;66234]This bug has just bitten me again today (missed an action to get my niece a birthday card) :-(

I reported this to the 'support ninjas' some months back, highlighting the fact that 'sleeping' the computer was involved. Any further news on being able to reproduce/fix?[/QUOTE]

This is still happening to me as well in 1.7.1 - there doesn't seem to be any rhyme or reason to when it decides to update the "due today" view when they machine goes to sleep.

If you have a laptop, forget it - you have to restart the app once a day just to make sure you aren't missing anything.

Having to remember this is really not good GTD practice :)

Now that the new version is out, and ready for Leopard, any chance we can get this bug fixed???

Sleeping your machine may be involved, but that doesn't seem to be necessary for the bug to appear. As I mentioned earlier in this thread, I put my MBP to sleep at night, but I've seen this problem occur even in the middle of the day, hours after having been woken from sleep.

What makes this issue particularly troublesome is that it's so intermittant and unpredictable. I'll go weeks without seeing any related problem and then it'll suddenly appear again. But then, when it does appear, I can never reproduce it a second time.

-Dennis

Thanks Toadling - I didn't realize that. I guess I am not sure what you mean though. Tasks that are due Today should switch to the due today list at some point based on the time (i.e. 12 midnight) when they are considered to be due Today.

I presumed the problem was that the machine was asleep during the transition, and whatever monitored the tasks for their status wasn't picking up that the date had changed.

Is this the same issue you were experiencing, that things are not being added to the "Today" list or being updated? I didn't realize that was also a problem if the machine was awake. Not sure what the problem is then...

Toadling,
Are you saying that once your machine has awoken from sleep, it remains awake for the rest of the day? I would have thought most people have their Macs sleep after a certain period of inactivity and so they could sleep multiple times during a a given day?

There have been multiple threads over the months (years ?) describing what appears to be the same bug - all of them appear to have their Macs going to sleep at some point.

Perhaps if someone from Omni like Ken could describe the code logic involved in updating an action's status we could deduce what might be happening here - is there some 'monitor' thread running at regular intervals to update action states (every minute for example) that looks at specific actions due within the same interval some (Due Soon) days hence? A 'sleeping' Mac would could mean that some of the actions in intervals that would have been 'scanned' had the Mac not been sleeping would be missed.

Here's hoping this one can be squashed!

Ken has explained the algorithm on the forums. I'm afraid I don't have a ready link, but some searching for posts from Ken would turn it up.

Curt,
I'm not finding anything by Ken detailing an 'algorithm', but then Ken has submitted a lot of posts.

I'd be interested if anyone can find it and post a link.

Ok, I think I've found it now:

[QUOTE=Ken Case;64878]We maintain a schedule of upcoming events, and schedule a timer to wake up and update the task status at the time of the first unprocessed event within the next few hours. If there isn't anything scheduled to happen in the next few hours, we schedule an event to check the schedule again later. And, of course, we update and rescan the schedule when task dates are edited.

When the timer fires, we scan through all the tasks and update their status. Any groups to which that task belongs (projects, contexts, folders) should update their status and counters as well, and finally any views displaying any of those tasks or groups should redraw with the new status.[/QUOTE]

Thing is: What happens when a 'timer' should run and the computer is 'sleeping'?

[QUOTE=MikeM;66253]Thing is: What happens when a 'timer' should run and the computer is 'sleeping'?[/QUOTE]

The timer remains in the timer queue, and we double-check that timer queue against the system clock each time OmniFocus receives input from the user (such as moving the mouse over an OmniFocus window). (The queue is ordered by date, so we just have to compare the current date against the date of the first entry in the queue. We weren't always quite so paranoid about this, but we found that we couldn't rely on the timers to fire appropriately otherwise.)

So I guess I have to think that we've actually seen the timer fire if it was scheduled, but it didn't end up doing its work properly for some reason. (Or perhaps the problem is that we failed to correctly schedule the timer in the first place?)

P.S. — If you'd like to help us debug this, try turning on this debug setting to get more information logged to the Console:

[CODE]defaults write com.omnigroup.OmniFocus OFMTaskElapsedDateControllerDebug -bool true[/CODE]

When you're ready to turn that debug log back off:

[CODE]defaults remove com.omnigroup.OmniFocus OFMTaskElapsedDateControllerDebug[/CODE]

P.P.S. — If you're debugging this, it would help to know what clears it up. I know that relaunching the app does, and it seems likely that rebuilding the database (with File->Rebuild Database) does, but does it also start working properly if you close the window and reopen it? Or if you switch view modes?

[QUOTE=Ken Case;66269]P.P.S. — If you're debugging this, it would help to know what clears it up. I know that relaunching the app does, and it seems likely that rebuilding the database (with File->Rebuild Database) does, but does it also start working properly if you close the window and reopen it? Or if you switch view modes?[/QUOTE]

I ran into this issue again last night. I had several items due next Friday at 5:00 PM. My "Due Soon is in the next:" preference was set to "week".

At around 7:00 PM yesterday (Friday), only one of the items due at 5:00 PM next Friday was colored orange. All the others were still colored blue (SAL tasks).

I tried closing and reopening the window and changing perspectives. Neither updated the tasks. Finally, I relaunched OmniFocus and the coloring was corrected.

Unfortunately, I did not try rebuilding the database and didn't have the debugging preference enable. I wish I had read this thread first. :-(

But I've got debugging enable now and will try rebuilding the database if I see this issue again.

-Dennis

PS - I caught a screenshot of the problem if anyone in support wants to see it. There's really not much to see though, just a couple of obviously mis-colored actions and one properly colored action, all with the same due date and time.

This is biting me as well. Thanks to everyone for pointing the quick and dirty restart OF solution. I look forward to the proper fix arriving.

This bug is actually worse than I realized. Since I have two computers that I am syncing, and both sleep overnight, I have to restart OF on BOTH machines in order to get the proper items to show up under the "Due or Flagged View".

Not only that, but when things have gone awry, presumably with the timers, they do not fix themselves, even if another time point that should trigger a change is crossed (i.e. the due time is passed). Items that should be added to the view, are NOT added.

For example, if I have closed my MacBook overnight, and forget to restart OF in the morning, and cross my 7PM boundary for Due Items, new tasks from the next day (next 24hr period) that should be added to the list are NOT added to the due or flagged. Its as if once the timers are off, they do not update that view anymore with new tasks.

I can't understand how this is not a problem for more people, or maybe most people don't have this view set up so that its noticeable.

I am not sure how this is not reproducible easily at Omni -- it happens every day to me on two machines. Perhaps a test machine can be put to sleep every night in order to see what is causing this.

What are your complete view bar settings in the view(s) where you have this problem? I do grouping by Due, actions Due Soon for my views where I'm looking at due dates, and I don't believe I've ever seen the behavior you report, though there are certainly plenty of candidates and opportunities! My machine gets put to sleep frequently (it's a laptop that I carry nearly everywhere), and I tend to keep a couple of windows open (including that Due Soon window -- the Due (soon) or Flagged view tends to be more transient in my usage).

If this really is so easily reproducible for you, why not do this: set your OmniFocus backup prefs to save a copy of the database whenever you quit. Then, before turning in for the night, quit OmniFocus. Make a zip archive of your OmniFocus preferences file and the database backup. Now restart OmniFocus and let your computer go to sleep in the normal fashion. If in the morning you find that it hasn't updated correctly, you can provide the zip archive to the support ninjas, and they can use them to reproduce your environment on a machine that has had the clock dialed back to the timestamp on the backup file.

What is your setting for "Due Soon"? I don't think your default due time setting (7PM) should influence when OmniFocus scans to add new items to the due lists, because it needs to do that work on an item by item basis as each action could have a completely different setting for due time.

I have been told by support now that they are aware of the issue and are working on it, but that they are not sure when it will be addressed. Clearly it is affecting a number of users based on the posts here.

@wh -- Your post suggests that not everyone is having this problem, which is interesting. Perhaps it is some combination of software I have on my machines that is interfering with the timers, etc. I don't have any haxies, etc. installed though, just standard stuff.

Support hasn't asked me for anything like what you have suggested -- I am happy to do this if they think it will help diagnose the issue. I try not to bombard them with info unless they ask for it.

-- Ken -- would what he suggests be helpful in figuring this out?

Regarding the view settings -- it doesn't actually matter which view I am in, now that I have looked at it again. When this happens, the labels don't change (due today or tomorrow) on the current tasks, and the windows that use Due in any fashion don't show the new "due in 24 hours" tasks.

Let me know if this answers your questions -- glad this bug isn't affecting everyone.

[QUOTE=wolfneuralnet;68291]-- Ken -- would what he suggests be helpful in figuring this out?[/QUOTE]

If anyone can figure out a consistent recipe which we can follow to reproduce the problem, that would be very helpful and by following the recipe here we should be able to track down the problem very quickly. (So if Bill's suggestion results in that sort of consistent recipe, then yes, we'd love to see it!)

But even if you haven't been able to figure out a consistent recipe, it would help to enable our schedule debugging logs (as described in [URL="http://forums.omnigroup.com/showthread.php?p=66268#post66268"]my earlier post[/URL]) and send us console output covering the period where something should have come due but didn't. (That way we can see if the problem lies in the scheduling code itself or somewhere totally different.)

This issues seems very sporadic, at least for me. Last week, I saw it occur two days in a row. But since then, I haven't seen it once (and I use OmniFocus *a lot*). I have the debugging preference enabled now, so maybe the problem will crop up again and I'll get some useful info for the Omni folks.

Possibly related observation: When I saw the problem occur last week, I had just changed my "Due soon is in the next:" setting from "3 days" to "week". The problem popped up a few hours after the change. Since then, I've gone back to using a setting of "3 days" and I haven't seen the problem since.

It could just be coincidence, but maybe it's a clue. What settings do you guys use?

-Dennis

I have turned on the debugging, and will forward the logs when it happens again. When I get a chance I will try Bill's suggestion as well, since it seems to happen most consistently to me.

I use 24 hrs as my due soon timeframe, so that doesn't seem to be it.

OK -- have forwarded logs and screenshots of the problem to the devs.

There didn't appear to be any timers fired when the machine was woken from sleep -- they didn't fire until the app was restarted. The only thing I could see from the logs was that the initial sync didn't work because it started before my machine had fully joined the wireless network, but I don't know whether that is related.

Has there been any progress on this issue since I sent the logs and screenshots in? I never heard back from support on this. Thanks!

Further to wolfneuralnets's enquiry above, I'd also like to know if any progress has been made here?

The problem now occurs with such regularity for me that I habitually quit and restart OmniFocus every morning to ensure I'm not missing anything of importance.

I have debug messages turned on as directed in another post - as far as I can see (as mentioned by wolfneuralnet) no 'Due Soon' timer fires at the appropriate time to 'flag' due soon items. I'd appreciate any assistance as to what I should be seeing in respect of 'Due Soon' timer messages in my console log.

Thanks for posting this Mike -- I am hoping that this is fixed in 1.8 since they are in pre-beta with it. We should know soon...

I still have to restart on both machines every morning. Its a pain.

Hi,
I've just seen a raft of my 'actions' get flagged by OF as 'Due Soon' - trouble is at least some of them should have been flagged as such yesterday some time!

As mentioned in a previous post, I have debug messages turned on. As far as I can tell, when scheduling when the next 'isDueSoon' timer should fire, the elapse time is far too far in the future: i.e. 180000 seconds or 50 hours (my 'Due Soon' preference is set at 2 days). I find this extremely odd given that I know there are tasks [B]within[/B] the next 50 hours that should be flagged as 'Due Soon' within that time period - what gives? This also appears to be borne out by subsequent messages issued when the timer eventually does fire where tasks are identified as 'elapsing' some substantial period back in time:
[CODE]
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: next task date elapses in -148228.0 seconds
[/CODE]

I attach what I believe to be the pertinent debug messages from my console log - I have substituted task/project descriptions with '<text description>' for privacy reasons:

[CODE]
29/01/2010 08:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: Setting limit date of 2010-01-31 10:10:27 +0000 with predicate isDueSoon == 0 AND effectiveDateDue < CAST(286625427.931984, "NSDate")
29/01/2010 08:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: No minimum date, using limit date 2010-01-31 10:10:27 +0000
29/01/2010 08:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: next task date elapses in 180000.0 seconds
29/01/2010 17:45:55 OmniFocus[13018] tasks = {(
{
"__self__" = "<OFMTask:0x7b6220 - eKOoVa7E9OA '<text description>'>";
objectID = "<ODOObjectID: 0x7b6500>";
values = {
attachments = {(
)};
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x7b6390 ProjectInfo gjYNtHILLdC>";
containsNextTask = 0;
context = "<OFMContext:0x14a1ea00 - eW6W-jLeki_ '<text description>'>";
creationOrdinal = 0;
dateAdded = 2009-11-08 23:31:48 +0000;
dateCompleted = <null>;
dateDue = 2010-01-29 17:00:00 +0000;
dateModified = 2010-01-10 12:59:09 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-29 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 1;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <3c746578 743e3c70 3e3c7275 6e3e3c6c 69743e4e 65656420 746f2070 75742073 69676e61 6c6c696e 67207374 72756374 75726573 20696e2e 3c2f6c69 743e3c2f 72756e3e 3c2f703e 3c2f7465 78743e>;
parent = "<OFMTask:0x7b62a0 - gjYNtHILLdC '<text description>'>";
projectInfo = <null>;
rank = -1759743546;
rankPath = 268435456.536870912.387740102;
repetitionString = <null>;
sequential = 0;
};
}
)}
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> timer fired
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: Clearing timer
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> processing 0 tasks
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> processing {(
)}
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: Setting limit date of 2010-02-02 12:10:27 +0000 with predicate isDueSoon == 0 AND effectiveDateDue < CAST(286805427.933059, "NSDate")
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: Found minimum date of 2010-01-31 17:00:00 +0000
31/01/2010 10:10:27 OmniFocus[13018] tasks = {(
{
"__self__" = "<OFMTask:0x14b0d3c0 - fyqbPO3yif0 '<text description>'>";
objectID = "<ODOObjectID: 0x14b0e480>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x14a02910 ProjectInfo fvB-eJU3zXC>";
containsNextTask = 0;
context = "<OFMContext:0x14a1f8d0 - f5oiA48LxZa '<text description>'>";
creationOrdinal = 0;
dateAdded = 2009-07-26 08:15:35 +0100;
dateCompleted = <null>;
dateDue = <null>;
dateModified = 2009-10-17 01:23:23 +0100;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'>";
projectInfo = <null>;
rank = 1073741824;
rankPath = 134217728.3154116608.3221225472;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'>";
objectID = "<ODOObjectID: 0x7ef070>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 2;
childrenCountAvailable = 2;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "fvB-eJU3zXC";
containsNextTask = 1;
context = <null>;
creationOrdinal = 0;
dateAdded = 2009-07-25 09:02:47 +0100;
dateCompleted = <null>;
dateDue = 2010-01-31 17:00:00 +0000;
dateModified = 2010-01-24 23:15:25 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "Personal : Week Off";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = <null>;
projectInfo = "<OFMProjectInfo:0x14a02910 ProjectInfo fvB-eJU3zXC>";
rank = 1006632960;
rankPath = 134217728.3154116608;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x14b06a70 - lP8FdR59AQg '<text description>'>";
objectID = "<ODOObjectID: 0x14b06e00>";
values = {
attachments = {(
)};
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x14a07ef0 ProjectInfo ecnFBBil5vu>";
containsNextTask = 0;
context = "<OFMContext:0x14a1f460 - dC_Dwt7awQp '<text description>'>";
creationOrdinal = 0;
dateAdded = 2010-01-10 14:40:57 +0000;
dateCompleted = <null>;
dateDue = 2010-01-31 17:00:00 +0000;
dateModified = 2010-01-10 14:42:17 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <3c746578 743e3c70 3e3c7275 6e3e3c6c 69743e48 61766520 61206c6f 6f6b2061 74204a75 72792661 706f733b 7320496e 6e3c2f6c 69743e3c 2f72756e 3e3c2f70 3e3c703e 3c72756e 3e3c6c69 743e5072 656d6965 7220496e 6e202d20 4b696e67 2661706f 733b7320 43726f73 733f3c2f 6c69743e 3c2f7275 6e3e3c2f 703e3c2f 74657874 3e>;
parent = "<OFMTask:0x14b06d40 - ecnFBBil5vu '<text description>'>";
projectInfo = <null>;
rank = -2080374785;
rankPath = 872415232.2147483648.67108863;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7eb460 - nqw2HGysauL '<text description>'>";
objectID = "<ODOObjectID: 0x7eb060>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = {(
)};
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x14a04c00 ProjectInfo fOXhouKLr4u>";
containsNextTask = 0;
context = "<OFMContext:0x14a1ea00 - eW6W-jLeki_ '<text description>'>";
creationOrdinal = 0;
dateAdded = 2010-01-28 16:40:47 +0000;
dateCompleted = <null>;
dateDue = 2010-02-01 14:00:00 +0000;
dateModified = 2010-01-28 16:41:55 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-02-01 14:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7e7700 - fOXhouKLr4u '<text description>'>";
projectInfo = <null>;
rank = -2147467264;
rankPath = 268435456.268435456.16384;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x14b12d00 - jQbvycKeNEJ '<text description>'>";
objectID = "<ODOObjectID: 0x14b128a0>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x14a019f0 ProjectInfo hrWszuD--ts>";
containsNextTask = 0;
context = "<OFMContext:0x14a1f8d0 - f5oiA48LxZa '<text description>'>";
creationOrdinal = 0;
dateAdded = 2010-01-24 23:24:54 +0000;
dateCompleted = <null>;
dateDue = 2010-01-31 22:30:00 +0000;
dateModified = 2010-01-24 23:24:54 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 22:30:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7ef310 - hrWszuD--ts '<text description>'>";
projectInfo = <null>;
rank = -1073745920;
rankPath = 134217728.3187671040.1073737728;
repetitionString = "@1(s)w";
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7e8e10 - aCRpLVm4QX3 '<text description>'>";
objectID = "<ODOObjectID: 0x7e8e00>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x7b50d0 ProjectInfo daD_eAr21i9>";
containsNextTask = 0;
context = "<OFMContext:0x14a1ea00 - eW6W-jLeki_ '<text description>'>";
creationOrdinal = 0;
dateAdded = 2009-10-16 10:46:47 +0100;
dateCompleted = <null>;
dateDue = 2010-01-31 17:00:00 +0000;
dateModified = 2010-01-07 10:57:17 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7b5020 - daD_eAr21i9 '<text description>'>";
projectInfo = <null>;
rank = -1264629266;
rankPath = 67108864.882854382;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x14b12050 - fZ8w1x9PlyB '<text description>'>";
objectID = "<ODOObjectID: 0x14b11cb0>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x14a02910 ProjectInfo fvB-eJU3zXC>";
containsNextTask = 0;
context = "<OFMContext:0x14a1f8d0 - f5oiA48LxZa '<text description>'>";
creationOrdinal = 0;
dateAdded = 2009-07-25 09:03:15 +0100;
dateCompleted = <null>;
dateDue = <null>;
dateModified = 2009-10-04 11:58:55 +0100;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'>";
projectInfo = <null>;
rank = 0;
rankPath = 134217728.3154116608.2147483648;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7e57f0 - mtfpmqljfkw '<text description>'>";
objectID = "<ODOObjectID: 0x7e57e0>";
values = {
attachments = {(
)};
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x7b50d0 ProjectInfo daD_eAr21i9>";
containsNextTask = 0;
context = "<OFMContext:0x14a1ea00 - eW6W-jLeki_ '<text description>'>";
creationOrdinal = 0;
dateAdded = 2009-12-14 13:34:23 +0000;
dateCompleted = <null>;
dateDue = 2010-01-31 17:00:00 +0000;
dateModified = 2009-12-14 22:26:54 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <3c746578 743e3c70 3e3c7275 6e3e3c6c 69743e39 20342f37 20646179 73207265 6d61696e 696e6720 61732061 74203134 2f31322f 30393c2f 6c69743e 3c2f7275 6e3e3c2f 703e3c2f 74657874 3e>;
parent = "<OFMTask:0x7b5020 - daD_eAr21i9 '<text description>'>";
projectInfo = <null>;
rank = -2147413743;
rankPath = 67108864.69905;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7f2ef0 - jnD6LAerI43 '<text description>'>";
objectID = "<ODOObjectID: 0x7f2ee0>";
values = {
attachments = <null>;
blocked = 0;
blockedByFutureStartDate = 0;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x21fae30 ProjectInfo bRCx0WZWR4_>";
containsNextTask = 0;
context = "<OFMContext:0x7bd730 - mxpMb0OYIES '<text description>'>";
creationOrdinal = 0;
dateAdded = 2010-01-25 08:23:47 +0000;
dateCompleted = <null>;
dateDue = 2010-01-31 17:00:00 +0000;
dateModified = 2010-01-27 22:36:15 +0000;
dateToStart = <null>;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-01-31 17:00:00 +0000;
effectiveDateToStart = <null>;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7ebbf0 - bRCx0WZWR4_ '<text description>'>";
projectInfo = <null>;
rank = 1342177280;
rankPath = 83886080.3489660928;
repetitionString = <null>;
sequential = 0;
};
},
{
"__self__" = "<OFMTask:0x7ea790 - bDmCPeD1298 '<text description>'>";
objectID = "<ODOObjectID: 0x7ea9b0>";
values = {
attachments = <null>;
blocked = 1;
blockedByFutureStartDate = 1;
children = <null>;
childrenCount = 0;
childrenCountAvailable = 0;
childrenCountCompleted = 0;
completeWhenChildrenComplete = 0;
containingProjectContainsSingletons = 1;
containingProjectInfo = "<OFMProjectInfo:0x7b50d0 ProjectInfo daD_eAr21i9>";
containsNextTask = 0;
context = "<OFMContext:0x14a1ea00 - eW6W-jLeki_ '<text description>'>";
creationOrdinal = 0;
dateAdded = 2010-01-25 10:25:25 +0000;
dateCompleted = <null>;
dateDue = 2010-02-01 12:00:00 +0000;
dateModified = 2010-01-25 10:25:25 +0000;
dateToStart = 2010-02-01 00:00:00 +0000;
effectiveContainingProjectInfoActive = 1;
effectiveDateDue = 2010-02-01 12:00:00 +0000;
effectiveDateToStart = 2010-02-01 00:00:00 +0000;
effectiveFlagged = 0;
estimatedMinutes = <null>;
flagged = 0;
hasCompletedDescendant = 0;
hasFlaggedTaskInTree = 0;
hasUnestimatedLeafTaskInTree = 1;
hierarchicalName = "";
inInbox = 0;
isDueSoon = 0;
isOverdue = 0;
maximumEstimateInTree = <null>;
minimumEstimateInTree = <null>;
name = "<text description>
nextTaskOfProjectInfo = <null>;
noteXMLData = <null>;
parent = "<OFMTask:0x7b5020 - daD_eAr21i9 '<text description>'>";
projectInfo = <null>;
rank = -2147458890;
rankPath = 67108864.24758;
repetitionString = "@1w";
sequential = 0;
};
}
)}
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: next task date elapses in -148228.0 seconds
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> timer fired
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: Clearing timer
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> processing 10 tasks
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> processing {(
"<OFMTask:0x7e57f0 - mtfpmqljfkw '<text description>'>",
"<OFMTask:0x14b06a70 - lP8FdR59AQg '<text description>'>",
"<OFMTask:0x7f2ef0 - jnD6LAerI43 '<text description>'>",
"<OFMTask:0x7ea790 - bDmCPeD1298 '<text description>'>",
"<OFMTask:0x14b12d00 - jQbvycKeNEJ '<text description>'>",
"<OFMTask:0x14b0d3c0 - fyqbPO3yif0 '<text description>'>",
"<OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'>",
"<OFMTask:0x7eb460 - nqw2HGysauL '<text description>'>",
"<OFMTask:0x14b12050 - fZ8w1x9PlyB '<text description>'>",
"<OFMTask:0x7e8e10 - aCRpLVm4QX3 '<text description>'>"
)}
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x14b12050 - fZ8w1x9PlyB '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x14b0d3c0 - fyqbPO3yif0 '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x14b06a70 - lP8FdR59AQg '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7eb460 - nqw2HGysauL '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x14b12d00 - jQbvycKeNEJ '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7f2ef0 - jnD6LAerI43 '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7e57f0 - mtfpmqljfkw '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7ea790 - bDmCPeD1298 '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] Adding task <OFMTask:0x7e8e10 - aCRpLVm4QX3 '<text description>'> for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: No minimum date, using limit date 2010-02-02 12:10:27 +0000
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: next task date elapses in 180000.0 seconds
31/01/2010 10:10:27 OmniFocus[13018] Posting notification for com.omnigroup.omnifocus.live_fetch.tasks_by_elapsed_date.effectiveDateDue.isDueSoon with tasks (
"<OFMTask:0x7ef080 - fvB-eJU3zXC '<text description>'>",
"<OFMTask:0x14b12050 - fZ8w1x9PlyB '<text description>'>",
"<OFMTask:0x14b0d3c0 - fyqbPO3yif0 '<text description>'>",
"<OFMTask:0x14b06a70 - lP8FdR59AQg '<text description>'>",
"<OFMTask:0x7eb460 - nqw2HGysauL '<text description>'>",
"<OFMTask:0x14b12d00 - jQbvycKeNEJ '<text description>'>",
"<OFMTask:0x7f2ef0 - jnD6LAerI43 '<text description>'>",
"<OFMTask:0x7e57f0 - mtfpmqljfkw '<text description>'>",
"<OFMTask:0x7ea790 - bDmCPeD1298 '<text description>'>",
"<OFMTask:0x7e8e10 - aCRpLVm4QX3 '<text description>'>"
)
[/CODE]

Interesting. I wonder if there's a seconds/milliseconds error. 180000ms in the future, would by 3 minutes, a much more reasonable interval. MikeM, you should definitely email a link to your post to the ninjas. They might have missed the units problem in your logs.

Cheers,

Curt

Mike,

Were there any more log messages from OmniFocus around 29/01/2010 17:45:55, i.e. between these three entries?

[CODE]29/01/2010 08:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000>: next task date elapses in 180000.0 seconds
29/01/2010 17:45:55 OmniFocus[13018] tasks = {( ...
31/01/2010 10:10:27 OmniFocus[13018] <OFMTaskElapsedDateController:0x217f0d0 - isDueSoon/effectiveDateDue/172800.000000> timer fired
[/CODE]

I would expect there to be another message before the "tasks = " line saying "Found minimum date of...", and I would expect there to be some lines afterwards saying "next task date elapses in...".

<strike>However, maybe that's where the problem lies! There's a short-circuit in there which exits before that "next task date" calculation if that code is called from a background thread. But I can't claim that's definitely the issue, since there shouldn't be any way to get the "tasks = " message without the preceding "Found minimum date" message—so I thought I should double-check to see if there were other log messages that you didn't quote.</strike> Edit: Nevermind, I think we've found the problem (see next post)!

Thanks!

[QUOTE=curt.clifton;72532]I wonder if there's a seconds/milliseconds error. 180000ms in the future, would by 3 minutes, a much more reasonable interval.[/QUOTE]

Hmm… 180000 isn't a units problem, it does refer to seconds: that's 50 hours, which is 48 hours (the configured "due soon" interval) plus two hours (the maximum amount of time the scheduler is supposed to sleep between refreshing the schedule), so that's the limit date in its database query.

But wait a minute! That's it, isn't it? It looks like that log shows the scheduler incorrectly using that limit date as its wakeup time, so it goes to sleep for 50 hours rather than two.

I'll go check the code…

That was it. Fixed in 1.8.

…and I'm guessing the next question is "When's 1.8 coming?" As you probably know we're pretty focused on iPad development right now, but I'm hoping to find a few hours next week to fix a glaring issue with 1.8 so we can start sneaky peeks.

Great news that you found this finally -- I will be very happy to not get bitten by this every morning!

Looking forward to the sneaky peek (and the iPad version of course!!!)

Hallelujah!

Thanks for the update, Ken. Yup, I thought that 180000 seconds being the 'Due Soon' setting plus 2 hours might be the essence of the problem. So it now looks like the contention that this bug was related to having your Mac got to sleep was unfounded. I'm surprised that more people weren't hitting this one more often?

Looking forward to 1.8 ...

I think there were a lot of people like me that have the same problem - with just as much frustration - that had no important things to add to this discussion other than "me too." I submitted it as a bug and tried what I could to help, but I sat back and watched this discussion and left it to the people who know how to troubleshoot. And it worked! Thank you for doing some of the heavy lifting for the rest of us!