[CatOne]

Originally Posted by b-dr

I agree with CatOne: the need for the user to intervene is annoying.

And here's the problem: I just opened my Mac and went to eat some dinner. I came back, 30 minutes later and still no sync.

In other words, I have to manually force the sync, which triggers the pop-up "Your Internet connection...", hit "Retry", and then, finally, everything is in sync. All the time. And the timeframe doesn't matter: it just won't sync automatically after waking up.

I agree that the remedy is simple, but it's not painless. (Sort of.) There's no reason for it to require user input.

Ayup. And this is a case where support is not helpful. They're quick to acknowledge the issue, but after 3 years of it being acknowledged there's no fix yet.

[whpalmer4]

Originally Posted by CatOne

Well, right. One try and fail seems pretty cruddy, especially if the try is before the network stack is up (which, again, is up in less than 10 seconds).

The network stack being up doesn't necessarily mean you can do anything useful with it. Your laptop wakes, brings up the network stack, sends a network configuration changed event to any and all processes listening for one and they promptly try to do something. Too bad you've got a DSL connection that went idle while your laptop was asleep, and now the router has to bring that up (which can be pretty pokey, relatively speaking) before it can answer the DNS queries for the address of sync.omnigroup.com. Your initial sync attempt may well time out during that process.

It's an annoying remedy, though, _especially_ since when you force the sync you get a modal dialog box as well. The whole sync behavior of OmniFocus is a bit "in your face" in the dialog box, as well as the blocking dialog box on the iOS clients. Other more modern sync systems seem to do it in the background without blocking the whole application.

Hmm, what other modern sync systems sync OmniFocus databases? What seems to be a more efficient sync system may just be one that has a simpler problem to solve!

I agree that the modal dialog box popping up when you manually sync after a sync failure is unnecessary. So does Omni, apparently, because the iPad app doesn't do it. I don't see any reason why clicking on the button shouldn't just do a sync (even if there was a previous failure), and if there is a need to know why a previous sync failed, the (i) button that appears in the Sync preferences gives it.

Originally Posted by b-dr

I agree with CatOne: the need for the user to intervene is annoying.

And here's the problem: I just opened my Mac and went to eat some dinner. I came back, 30 minutes later and still no sync.

In other words, I have to manually force the sync, which triggers the pop-up "Your Internet connection...", hit "Retry", and then, finally, everything is in sync. All the time. And the timeframe doesn't matter: it just won't sync automatically after waking up.

That's not true, in my experience, and I just did the test. The problem is that with the default settings, and no changes made to the database by you in the mean time, the next attempt won't be for 60 minutes after the failed attempt.

Arguably, a failure that looks like it might be due to the network being offline (failing to look up the address of the sync host, for example) ought to cause another sync attempt to be scheduled shortly thereafter, perhaps using the TimeFromFirstEditToSync setting (which controls how long it is between you making a change and OmniFocus attempting to sync it to the server, default value being 60 seconds). Because a network configuration change notice doesn't tell you that you've got end-to-end connectivity to the sync server, just that you're now connected to some network and can start bleating packets out into the ether, this is a desirable change IMO even if OmniFocus starts using network configuration change notifications.

I agree that the remedy is simple, but it's not painless. (Sort of.) There's no reason for it to require user input.

Agreed, though it is helpful to be able to retrieve the reason for the last failure. I believe my proposal addresses this satisfactorily without adding any friction in the cases where it is not needed.

Originally Posted by CatOne

Ayup. And this is a case where support is not helpful. They're quick to acknowledge the issue, but after 3 years of it being acknowledged there's no fix yet.

Support can't do anything for you except offer workarounds if engineering management declines to address the issue.

If you want to dial the time between sync attempts down, quit OmniFocus, open the Terminal app, and enter the following:

defaults write com.omnigroup.OmniFocus MaximumTimeBetweenSync 60

then restart OmniFocus. This will have OmniFocus initiate a sync every 60 seconds, which should clear any error condition without you having to dismiss any modal dialogs. That's an aggressive value for that setting, but I've used it for extended periods of time when stress-testing syncing without incident. Your mileage may vary. To go back to the default setting, use:

defaults delete com.omnigroup.OmniFocus MaximumTimeBetweenSync

[CatOne]

Originally Posted by whpalmer4

The network stack being up doesn't necessarily mean you can do anything useful with it. Your laptop wakes, brings up the network stack, sends a network configuration changed event to any and all processes listening for one and they promptly try to do something. Too bad you've got a DSL connection that went idle while your laptop was asleep, and now the router has to bring that up (which can be pretty pokey, relatively speaking) before it can answer the DNS queries for the address of sync.omnigroup.com. Your initial sync attempt may well time out during that process.

No, my Internet connection is up. I have more than one device accessing it. Seriously, if I wake my laptop, go through the screen saver, by the time I can get OmniFocus displayed on the screen, it has already failed. The time is less than 10 seconds. No other applications on my machine that I've observed give up and go into a "failed" state this quickly.

Hmm, what other modern sync systems sync OmniFocus databases? What seems to be a more efficient sync system may just be one that has a simpler problem to solve!

They don't sync my OmniFocus database, but the Things "cloud" sync and The Hit Lists's sync both have no problems with network wake state, under the exact same state of conditions.

Arguably, a failure that looks like it might be due to the network being offline (failing to look up the address of the sync host, for example) ought to cause another sync attempt to be scheduled shortly thereafter, perhaps using the TimeFromFirstEditToSync setting (which controls how long it is between you making a change and OmniFocus attempting to sync it to the server, default value being 60 seconds). Because a network configuration change notice doesn't tell you that you've got end-to-end connectivity to the sync server, just that you're now connected to some network and can start bleating packets out into the ether, this is a desirable change IMO even if OmniFocus starts using network configuration change notifications.

Sure. Try when you get the 'network state changed' notification. If that fails, try again at 5, 10, 30, and 60 seconds (or whatever your "back off" algorithm is) and then fail.

Support can't do anything for you except offer workarounds if engineering management declines to address the issue.

Sure, but this largely semantics. Saying "I understand" and then having engineering de-prioritize the issue so it's not fixed in 3+ years is poor support (not on the part of the support staff, but really on the part of the company to "support" its products by fixing frustrating bugs). Any workarounds to change sync times stink, unless I want to change the interval from 60 minutes to 1 minute to address this (which would cause unnecessary server load… if every customer of the Omni Sync Server did this, it would be a nice DDos and probably require them to build out 20 times the current server infrastructure.

[whpalmer4]

Originally Posted by CatOne

No, my Internet connection is up. I have more than one device accessing it. Seriously, if I wake my laptop, go through the screen saver, by the time I can get OmniFocus displayed on the screen, it has already failed. The time is less than 10 seconds. No other applications on my machine that I've observed give up and go into a "failed" state this quickly.

I'm trying to go through the range of possible failures, and how they might be handled. They don't all necessarily apply to CatOne.

They don't sync my OmniFocus database, but the Things "cloud" sync and The Hit Lists's sync both have no problems with network wake state, under the exact same state of conditions.

I'll try to be more clear next time; I was referring to your gripe about the updating with synced data dialog on the iOS apps.

Sure, but this largely semantics. Saying "I understand" and then having engineering de-prioritize the issue so it's not fixed in 3+ years is poor support (not on the part of the support staff, but really on the part of the company to "support" its products by fixing frustrating bugs).

So, do you have some evidence that the support folks are "having engineering de-prioritize the issue"? It's hard to fathom why the support group would encourage not fixing this unless they thought they could get rid of more customer issues by fixing other bugs. It's not like their jobs will be redundant once they don't have to field your bug reports on this particular issue :-)

Any workarounds to change sync times stink, unless I want to change the interval from 60 minutes to 1 minute to address this (which would cause unnecessary server load… if every customer of the Omni Sync Server did this, it would be a nice DDos and probably require them to build out 20 times the current server infrastructure.

More likely that they'd address the bug, don't you think? In any case, it's pretty darn unlikely that many people are going to fire up the Terminal to change their Mac OmniFocus behavior. Posting a "me too" complaint on the forum is pretty easy, and yet I don't even see much of that.

Frankly, I'm surprised the bug wasn't addressed years ago as a matter of pride of workmanship, even if the only ticket came from an Omni employee. Would you want to have your name on a piece of software that misbehaved in such an obvious fashion, even if the customers weren't complaining in large numbers?

[Brian]

The situation here is similar to the one I posted about in another thread recently.

This problem, based on the number of emails we get about it, doesn't seem to affect a large number of folks. It's true that this issue was reported quite a while ago - the first report we have on file is from 2008, and we've gotten 12 emails about it since then.

We also have items in the database that were filed more recently (in 2010) and have - no exaggeration - more than 10 times as many customer requests attached. We don't enjoy making tradeoffs between different chunks of work, but it's necessary. Our preference is aligned with yours - we want to fix everything. We like making customers happy.

Apologies to the folks that are affected by this - I'll make sure that the rest of the team knows that the population of folks having this problem encounter it frequently. I know how irritating that can be.

[Brian]

Originally Posted by whpalmer4

Would you want to have your name on a piece of software that misbehaved in such an obvious fashion, even if the customers weren't complaining in large numbers?

I think we would all prefer to fix the things that we find embarrassing. That said, our own vanity isn't a good enough reason to set aside or ignore the stuff that lots of customers are telling us they want and need.

[b-dr]

Thanks for the replies and insights guys, really appreciate it.

(And, oh irony, OF just performed a perfect sync after waking up! Truly puzzled now... First time ever, too. Omni HQ must have some pretty special powers.)

Anyway, I just wanted to say I really like Omni and I really appreciate the effort. In no way do I consider this flaw a sign of poor craftsmanship, especially given its apparently limited occurrence. I think you guys are an exemplary company that listens to users and actually cares. Which is becoming a rarity.

That being said, I really, really look forward to a fix.

[Andrew Scott]

I'd just like to add my experiences to this thread, which is to say that I've experienced this problem routinely on my laptop and desktop machines, connected at home and at my university's campus (solid connection!). I became very sick of it and lodged a support ticket some years back.

It's only ceased to become a source of irritation for me since I stopped using OmniFocus. It wasn't the reason for stopping (it's mainly sync speed and a few other things) but it didn't help.

[DerekAsirvadem]

Originally Posted by Brian

I think we would all prefer to fix the things that we find embarrassing. That said, our own vanity isn't a good enough reason to set aside or ignore the stuff that lots of customers are telling us they want and need.

Vanity ?

No, that's not vanity, look up any dictionary.

In personal terms, that is taking pride in your work, or in commercial terms, a QA issue. When I was a codeline engineer, we did not worry about management approval for bug fixes, we simply fixed all known bugs in the next codeline. That was an imperative, and a matter of personal pride, especially if we had written the original code (that contained the bug). Several (much larger) s/w companies that I deal with still operate the same way.

The issue of having to make decisions about what to fix or enhance, is a separate commercial matter. You've made a decision to prioritise all work (bug fixes as well as enhancements) based on votes; that's fine, and it has these consequences. Such as mountains of issues with customers, who quite reasonably expect something else. As evidenced in this forum.

Other companies use a more traditional model, where bugs are fixed, period, and only enhancements are prioritised based on votes, and therefore that it what customers expect. That model has different consequences. Such as long term growth, and mountains less time re explanations on the forum.

Omni is so small, that evidently, the support (or QA) engineers are one and the same as the development engineers, and managed by the same administrators. Other companies have the two groups separated. There are good reasons for that.

Separately, if Omni management have been diminishing the professional pride of your engineers, and labelling it "vanity", then shame on them, and I pray that (a) you are free of such disgusting Godless creatures, and (b) herewith empower the engineers to reject relabelling as a dishonest and manipulative.

Cheers
Derek