android/windows sync issues

[Dwight Arthur]

Hi, all. I'm replying to the conversation about synching which was happening here: 

https://groups.google.com/forum/#!msg/mylifeorganized/6IPX0WSNwYA/TteMfhEUpA0J

I moved it because I didn't think "goodbye everyone" was a good title for what we are discussing.

I want to thank Lisa and ctenorman for thoughtful and constructive posts which attempted to promote better understanding of the issue or maybe move towards a solution. As requested I will attempt to lay out what I have observed, and will also review what I have attempted, so far, to do about it.

The first and biggest point is that I have made several attempts to create a small file with test cases where I could reproduce the problem in a simplified context, but I have been unsuccessful. Perhaps because a true test case would probably involve a different cloud sync file as well as a different set of task scheduler entries in Windows and I have never quite had the time it would take to get all of that set up correctly.

Before describing the symptoms, here is a little about my setup. The first folder in my outline is "routines" and contains seven repeating projects: daily tasks, weekly, monthly, quarterly and three annual projects: spring autumn and taxtime. Each project repeats as suggested by its name and contains a number of tasks. The tasks themselves are not repeating but are recreated when the project repeats. Advanced recurrence options are set to recur the project when all subtasks are complete and to reset all subtasks when the project recurrs. This means that when I complete the last task in today's daily project the project will reset for tomorrow, with all the tasks ready to go but none of them in "active tasks" until tomorrow. It also means that if tomorrow arrives and there are a couple of tasks I didn't get to, I can just click the project complete and the tasks are all reset to today. This is all functionality that MLO explicitly supports, and it matches quite well with the way that I think about my work. I would be totally happy with all of this were it not for the sync issues.

The core of the problem is that about two to three times a week, I will open the daily project in the morning and find that the due date is the day before yesterday. Very occasionally the date will be yesterday but usually its the day before. It's often the case that by the time I notice, I have already ticked off some of today's tasks, not realizing they were actually for the day before yesterday. There's a very high probability that when I get the parent date set correctly, the completed tasks will be reset to uncomplete. For the daily tasks, I usually can remember which ones I did and check them again but every once in a while I get it wrong. (If I was so good at remembering whether I did a task today or if it was yesterday, I would not need MLO as much as I do). 

I am completely sure of the accuracy of the above paragraph. This next thing I am less sure of, but in the interest of completeness I will mention it: I believe that when I add a new subtask to the daily project and later that day there's a sync problem, that sometimes the new task vanishes.

Once every month or two, I will be checking off tasks in the weekly project and discover that it is for two weeks ago. This is pretty similar to the daily problem except that I am much less likely to have an active memory of which monthly tasks I have already completed this month.

It happened to me once for a monthly project that was dated for two months prior.

If I pay total attention and check the dates of each task before completing it, I can avoid most but not all occurrences of this problem. But my purpose in using MLO is to use less of my brain thinking about the status of my tasks and more of my brain getting them done. The need for this kind of hypervigilance defeats my purpose. The worst thing is that I learned from GTD the value of having a trusted repository of things to do and then letting go of the energy I was spending holding on to my mental lists. In the current circumstance I have to maintain a mental shadow list of what MLO should look like, and continuously check MLO against expected. I experienced real productivity gains after I adopted MLO and learned to let go. I have lost that and I miss it.

Here's what I have done about it:

1. I implemented a scheduled task on Windows that launches a copy of MLO with a command-line parameter to force a cloud sync. I wrote this myself before it showed up in the forums, based on the user guide's documentation of command line parameters and my knowledge of the Windows task scheduler. I run this hourly. About once every week or two it fails. My belief is that failure entails a conflict between a foreground copy of MLO and the background copy launched by the scheduler. Symptoms involve windows error messages and reports by the foreground copy that it cannot access the profile file. The most likely time for me to see these symptoms would be first thing in the morning, at which there might be a couple of dozen windows error messages outstanding. It is possible to answer them all, as well as the five or so additional errors that pop up for each one when its closed, but it's usually easier to reboot. I have reported the error messages to MLO support and not heard anything back, which is okay by me because I do not believe MLO was or should be designed to accomodate multiple copies running off of a single profile. The reason I am describing these errors is, this is the reason I do not run the scheduled process more frequently. I believe that I could reduce my sync errors by increasing the scheduled sync to run, say, ten times per hour but I believe that this would lead to increased profile conflicts.

2. For "both sides changed" on Android I set to take the server version. Either answer to this question leads to errors but the errors from accepting server version are easier to fix than the errors from accepting local version.

3. "Autosync on close" is enabled on Android.

4. Sync via wifi only is enabled. I have a 200mb data plan (to save on fees) and another 10-20 mb/month would make a real difference.

5. I do not enable synching on profile switch, because I never switch profiles.

6. "check cloud periodically" is enabled every 5 minutes.

7. I hit the synch icon on Android as often as I can remember to do so.

The symptoms I described above are what I get *after* having put these seven steps in place months ago.

Here's what I think is happening:

A. I think that sometimes, every task in a project has been completed, and some of them are completed on Android awaiting sync to Windows while others are completed on Windows awaiting sync to Android. When the sync is completed in both directions I would like to see everyone agree that all tasks are completed and that therefore the project is completed for this cycle and needs to be rolled to the next cycle. I do not think that happens, at least I do not think it always happens. The results may vary depending on whether the Windows side or the Android side was the first to see the project with all tasks in completed state.

B. I think that at least sometimes, completing a task causes the parent to sync. If I change the parent on Android and a minute later (before any sync) change a subtask on Windows in a way that causes the parent to sync, the (unchanged) windows parent will overwrite the changed Android parent and the change from the Android side will be lost.

C. In these circumstances it can be devilishly hard to ensure that items (especially project/parent items) are changed only on one side. If they get changed on both sides and the version you want to keep is on Android, the "both sides changed" setting to server guarantees that the desired change on Android will be lost. (note, changing "both sides changed" to use the local copy makes the problems worse, believe me).

D. Lisa noted that in the event of a sync conflict, on the Windows side you always get notified and can choose which version to keep. I think most users with an opinion would agree, but it's not always true. Start with the case described in (C) above. When Sync overwrites the good version on Android with a bad version from Windows, the next sync sends the bad update back to Windows. Since the update exactly matches the Windows version no conflict is detected and the bad version is retained, with no notice or choice on the Windows side.

E. Along the lines suggested by ctenorman I believe that frequent background syncs on both Windows and Android would reduce (but not eliminate) the window in which an error could occur. Ideally, either side would sync whenever a change is saved to the profile, or whenever unsynched cloud changes are detected. I had asked for this in one of these forums long ago and was challenged by other readers who felt that the storage and processing costs would be exorbitant, and that windows/android performance would suffer. Meanwhile there have been several successful implementations, such as Google Drive and Evernote. I understand that Google can afford unlimited storage and processing for a product with little if any revenue, but Evernote needs revenue the same way MLO does and yet Evernote gets this right.

F. I think that maybe a very helpful step would be if I could hit the sync icon right before putting the phone down for the night. Unfortunately I don't often know when that is - I will be working on something, there's an interruption which gets interrupted by something else and I don't get back to it till morning. More often than not, MLO was the active program at the time of the interruption, which means that "MLO Close" never happens and the changes sit there unsynched for hours. Maybe MLO/Android should include an option that if MLO has been the foreground program continuously for more than X minutes, with the "needs sync" icon lit for the whole time and no activity at all, run a sync.

G. So long as there is a window greater than zero, sync conflicts may continue to arise. I would like to see either a "pick which version" dialog on Android or have both versions preserved and presented to the user on Windows MLO for a choice, the next time there's a Windows sync.

H. I was considering going to Wifi sync - my hope was that whenever there was a sync, both Windows and Android clients would be present and Windows conflict processing could occur. But I see that in Wifi setup there, a setting for always keeping the server version versus always keeping the local version. Whichever option you chose will be correct sometimes and wrong sometimes and when its wrong there will be a problem. So Wifi won't help me.

I. It's worth noting that several people recently have posted complaints that wifi sync is one-directional, windows to mobile. In MLO/Windows File>Synchronization>Edit>Advanced there's a dropdown for selecting one versus two directional sync but it does not appear that this would affect wifi. I don't see anything in wifi options for directionality. It would probably be a good thing if we could identify how to control directionality in wifi sync so we could respond to the next person who raises this issue.

[Lisa Stroyan]

Thanks for the detailed explanation. I'm going to jump to the issues as you've gone above and beyond in your setup to get it the best it can be...no issues there. I'll put my replies inline:

On Tue, Jul 24, 2012 at 1:57 PM, Dwight Arthur <m...@grantsmiths.org> wrote:

A. I think that sometimes, every task in a project has been completed, and some of them are completed on Android awaiting sync to Windows while others are completed on Windows awaiting sync to Android. When the sync is completed in both directions I would like to see everyone agree that all tasks are completed and that therefore the project is completed for this cycle and needs to be rolled to the next cycle. I do not think that happens, at least I do not think it always happens. The results may vary depending on whether the Windows side or the Android side was the first to see the project with all tasks in completed state.

I have found at least one fully reproducible defect here which I submitted to the beta forum [I just saw your reply]. You are correct, not only does completing part of the tasks on one and part on another  FAIL to cause a recurrence in the parent, it's even worse because completing yesterday's tasks on Android can cause today's versions of the tasks to be completed erroneously on the PC.

B. I think that at least sometimes, completing a task causes the parent to sync. If I change the parent on Android and a minute later (before any sync) change a subtask on Windows in a way that causes the parent to sync, the (unchanged) windows parent will overwrite the changed Android parent and the change from the Android side will be lost.

By "sync" do you mean "marked as modified"? 

If a single subtask is changed, I don't get the parent marked as modified. But if I change the note of "Testparent" on Android, then complete and auto-recur Testparent on the PC, sync PC, and sync Android, the changed note will be lost on Android. Is that what you mean?  But you see it sometimes *without* the recurrence happening?

C. In these circumstances it can be devilishly hard to ensure that items (especially project/parent items) are changed only on one side. If they get changed on both sides and the version you want to keep is on Android, the "both sides changed" setting to server guarantees that the desired change on Android will be lost. (note, changing "both sides changed" to use the local copy makes the problems worse, believe me).

What I do in this case is I always sync Android first. It seems to me that if there is a case where syncing Android first does not give a request for a sync conflict resolution, there is an obvious/reportable bug -- if we can find it. 

But if you are syncing "wi-fi only" then you can't always sync android first, and automatic desktop sync complicates it even more.

D. Lisa noted that in the event of a sync conflict, on the Windows side you always get notified and can choose which version to keep. I think most users with an opinion would agree, but it's not always true. Start with the case described in (C) above. When Sync overwrites the good version on Android with a bad version from Windows, the next sync sends the bad update back to Windows. Since the update exactly matches the Windows version no conflict is detected and the bad version is retained, with no notice or choice on the Windows side.

Yes, I have replicated this just now. It happens when Android is not synced. The reason I don't see this is that for me Android syncs as soon as I go do something else on my phone, pretty much always since I'm almost always on a network, and if I'm not, my PC is at home and I'm not changing anything.

In my test case that I reported a defect, I was also not asked, if I did the steps in the order I listed.

 

E. Along the lines suggested by ctenorman I believe that frequent background syncs on both Windows and Android would reduce (but not eliminate) the window in which an error could occur.

But if Android is always synced first, and the obvious bugs fixed, is this true? Of course Android cannot always be synced first, if the scheduler happens to slip in right at that moment. 

Ideally, either side would sync whenever a change is saved to the profile, or whenever unsynched cloud changes are detected. I had asked for this in one of these forums long ago and was challenged by other readers who felt that the storage and processing costs would be exorbitant, and that windows/android performance would suffer.

But wait...aren't you being inconsistent here?  If you only sync when on Wi-fi, you wouldn't use the "sync on every change" anyway, and you would still see this issue, correct?

 

Meanwhile there have been several successful implementations, such as Google Drive and Evernote. I understand that Google can afford unlimited storage and processing for a product with little if any revenue, but Evernote needs revenue the same way MLO does and yet Evernote gets this right. 

Not always. I've had data loss with Evernote too though I have not tracked it down.

 

I have to run!

--
Lisa

---

Lisa Stroyan, mailto: lstr...@gmail.com

[m...@grantsmiths.org]

X

X

 

 

Thanks for your comments, see my replies inline

On Wed, Jul 25, 2012 at 10:30 AM, Lisa Stroyan wrote:

Thanks for the detailed explanation. I'm going to jump to the issues as you've gone above and beyond in your setup to get it the best it can be...no issues there. I'll put my replies inline:

On Tue, Jul 24, 2012 at 1:57 PM, Dwight Arthur <m...@grantsmiths.org> wrote:

A. I think that sometimes, every task in a project has been completed, and some of them are completed on Android awaiting sync to Windows while others are completed on Windows awaiting sync to Android. When the sync is completed in both directions I would like to see everyone agree that all tasks are completed and that therefore the project is completed for this cycle and needs to be rolled to the next cycle. I do not think that happens, at least I do not think it always happens. The results may vary depending on whether the Windows side or the Android side was the first to see the project with all tasks in completed state.

 

I have found at least one fully reproducible defect here which I submitted to the beta forum [I just saw your reply]. You are correct, not only does completing part of the tasks on one and part on another  FAIL to cause a recurrence in the parent, it's even worse because completing yesterday's tasks on Android can cause today's versions of the tasks to be completed erroneously on the PC.

 

I agree that you have defined and reproduced this, that it’s a defect and that it plays a role in my issue.

 

B. I think that at least sometimes, completing a task causes the parent to sync. If I change the parent on Android and a minute later (before any sync) change a subtask on Windows in a way that causes the parent to sync, the (unchanged) windows parent will overwrite the changed Android parent and the change from the Android side will be lost.

 

By "sync" do you mean "marked as modified"? 

 

If a single subtask is changed, I don't get the parent marked as modified. But if I change the note of "Testparent" on Android, then complete and auto-recur Testparent on the PC, sync PC, and sync Android, the changed note will be lost on Android. Is that what you mean?  But you see it sometimes *without* the recurrence happening?

I have not been paying attention to date/time of modification. Are you certain that a task is subject to synch if AND ONLY IF date/time of modification is sufficiently recent? Without thinking too much about it I had assumed that date/time of modification was a sufficient but not necessary condition, and that other factors could also trigger a task to be candidate for sync.

 

I have not been able to reproduce this and am not 100% certain that it happens as I describe it, but I have a sense that completing a subtask of a recurring task that recurs based on subtask completion, would cause the parent to sync even if its modification date was unchanged.

 

Here’s a scenario that DOES NOT work to illustrate my point, but I think it’s close to the situation I’m chasing:

-define a repeating task that recurs when all subtasks are completed. Set daily repeat with start and due date = today.

-fully synch between windows and android

-complete one task on windows and sync to cloud. Sync cloud to phone

-complete second task on phone and set the phone aside overnight without synching. Leave MLO running as foreground program. Phone will not synch overnight while Windows will synch hourly.

-In the morning, Windows phone and cloud all show the repeating task set for yesterday. Windows and cloud show one subtask complete, phone shows two subtasks complete.

-On the phone, complete the repeating task. It will reset to today with all subtasks incomplete. Do not sync.

-On windows, manually complete the second task, the same one that was marked complete on the phone yesterday.

-Sync windows to phone to cloud.

I believe but cannot reproduce that sometimes the phone will show the repeating task uncompleted with yesterday’s date, matching what’s currently on Windows, with the second task completed and the first and third uncompleted.

My conclusion is that marking the second task complete on Windows caused the parent status (incomplete, due yesterday) to be updated to Cloud.

 

 

 

C. In these circumstances it can be devilishly hard to ensure that items (especially project/parent items) are changed only on one side. If they get changed on both sides and the version you want to keep is on Android, the "both sides changed" setting to server guarantees that the desired change on Android will be lost. (note, changing "both sides changed" to use the local copy makes the problems worse, believe me).

 

What I do in this case is I always sync Android first. It seems to me that if there is a case where syncing Android first does not give a request for a sync conflict resolution, there is an obvious/reportable bug -- if we can find it. 

 

But if you are syncing "wi-fi only" then you can't always sync android first, and automatic desktop sync complicates it even more.

I agree that if it were possible to force Android to always sync first the problem would be corrected or at a minimum massively reduced in impact.

 

Scheduled sync on desktop, as you say, makes that difficult. The other thing that in my opinion makes it difficult is that changed tasks on Android can remain unsynched for hours, provided that MLO remains in the foreground on the phone for all of that time.

 

In my case I don’t think that wifi only is significant because I almost never use my computer outside of wifi range and my phone is generally there with me, so if my fingers are on the computer the phone has almost certainly been in wifi range for a few minutes.

 

 

 

D. Lisa noted that in the event of a sync conflict, on the Windows side you always get notified and can choose which version to keep. I think most users with an opinion would agree, but it's not always true. Start with the case described in (C) above. When Sync overwrites the good version on Android with a bad version from Windows, the next sync sends the bad update back to Windows. Since the update exactly matches the Windows version no conflict is detected and the bad version is retained, with no notice or choice on the Windows side.

 

Yes, I have replicated this just now. It happens when Android is not synced. The reason I don't see this is that for me Android syncs as soon as I go do something else on my phone, pretty much always since I'm almost always on a network, and if I'm not, my PC is at home and I'm not changing anything.

 

In my test case that I reported a defect, I was also not asked, if I did the steps in the order I listed.

 

 

E. Along the lines suggested by ctenorman I believe that frequent background syncs on both Windows and Android would reduce (but not eliminate) the window in which an error could occur.

 

But if Android is always synced first, and the obvious bugs fixed, is this true? Of course Android cannot always be synced first, if the scheduler happens to slip in right at that moment. 

If Android always synched first, and the other obvious bugs were fixed, I would be pretty happy. I don’t know how either Windows or Android could know whether the other side has synched until it finds out by synching. I kind of feel like Heisenberg and Einstein discussing whether anything anywhere can ever be simultaneous, and how we could know.

 

I suppose that Windows could refuse to synch if the last Android synch was more than ___ minutes ago? But that would mean that if you lost your phone and then sent tasks to the MLO/cloud’s email address the new tasks would not show up on Windows until you find your phone.

 

 

Ideally, either side would sync whenever a change is saved to the profile, or whenever unsynched cloud changes are detected. I had asked for this in one of these forums long ago and was challenged by other readers who felt that the storage and processing costs would be exorbitant, and that windows/android performance would suffer.

 

But wait...aren't you being inconsistent here?  If you only sync when on Wi-fi, you wouldn't use the "sync on every change" anyway, and you would still see this issue, correct?

I would synch on every change. If a wifi connection were available I would expect the synch to occur within a minute or so of the completion of the change. If a wifi connection were unavailable I would expect the synch to occur within a minute or so of the re-establishment of a wifi connection. There would be no problem unless I am using my laptop with an Ethernet connection somewhere without wifi, or if I left my phone in the car (outside wifi range from my house) and went inside to immediately start managing my tasks. I could live with all of that.

 

 

Meanwhile there have been several successful implementations, such as Google Drive and Evernote. I understand that Google can afford unlimited storage and processing for a product with little if any revenue, but Evernote needs revenue the same way MLO does and yet Evernote gets this right. 

 

Not always. I've had data loss with Evernote too though I have not tracked it down.

I suppose that any architecture with data stores on synchronized but disconnected platforms will show data loss if pushed hard enough. My point was that Evernote synchs changes more-or-less as they occur without destroying the performance of either Windows or Android and without requiring such massive cloud servers as to bankrupt the Evernote developers.

 

 

I have to run!

Me too. Thanks. –Dwight.

 

 

 

 

--
Lisa

---

Lisa Stroyan, mailto: lstr...@gmail.com

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To post to this group, send email to mylifeo...@googlegroups.com.
To unsubscribe from this group, send email to mylifeorganiz...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.

[Lisa Stroyan]

Hi Dwight. I was gone all weekend but finally got a (brief) chance to read through your reply. 

In short, I really don't know how modification times effect things, other than I'm pretty sure both platforms use them for conflict resolution. I do believe that any time a task is marked as modified it will get synced, irrelevant of how old the time is. 

But I've not seen a case where a parent is marked as modified based on a child attribute change, unless the automatic sync is triggered -- but that doesn't mean it won't happen. 

You know, I've been thinking about how several of us have suggested a new feature for the desktop where different actions can be triggered based on different criteria.  I'm now thinking the sync architecture would have to be improved before this feature could be implemented, since it would really bring existing problems to the fore.

Lisa

On Thu, Jul 26, 2012 at 3:13 PM, <m...@grantsmiths.org> wrote:

If a single subtask is changed, I don't get the parent marked as modified. But if I change the note of "Testparent" on Android, then complete and auto-recur Testparent on the PC, sync PC, and sync Android, the changed note will be lost on Android. Is that what you mean?  But you see it sometimes *without* the recurrence happening?

I have not been paying attention to date/time of modification. Are you certain that a task is subject to synch if AND ONLY IF date/time of modification is sufficiently recent? Without thinking too much about it I had assumed that date/time of modification was a sufficient but not necessary condition, and that other factors could also trigger a task to be candidate for sync.

 

I have not been able to reproduce this and am not 100% certain that it happens as I describe it, but I have a sense that completing a subtask of a recurring task that recurs based on subtask completion, would cause the parent to sync even if its modification date was unchanged.

 

--

[m...@grantsmiths.org]

For what it’s worth, the discussion below mentioned so many times that there should be fewer problems if Android synched first, so I decided to try to force it. I have adopted the following routine: whenever I sit down at my computer after a while away from it, before touching the computer I take out my phone and synch MLO to cloud. Then I go on about my business. It’s annoying and time consuming but problems with my daily routine are way down. I still experienced one incident where I had started a new cycle of the monthly routine and clicked off a few tasks and the next morning I found computer and phone both back to a fresh cycle with nothing checked off. I may have missed once at synching the phone before touching the computer. But generally, this seems to be a workaround.

--

[Lisa Stroyan]

Do you get a lot of sync conflicts you have to resolve?

Lisa

[m...@grantsmiths.org]

While I have experienced sync conflicts in the past I have not seen any lately

[daniel sekera]

fwiw and I really don't want to add any confusion to this thread but I cannot make mine break

I have been playing with this since yesterday trying to replicate what is happening and I cannot.  All parts of this, parent, child, notes, re-occurence, times, everything sync flawlessly and without conflicts of any type and all notes are intact.  no matter which direction I start the sync or which direction I make changes.

very strange. wish I could help

[Lisa Stroyan]

Andrey has verified at least one of the defects(posted to another forum, the beta forum I think) as an unfortunate result of the architecture. The other I was able to get by adding a note to a parent on Android, then making that recur on PC by completing subtasks, then syncing in a particular order -- unless he special cased notes in the sync in recent versions, which would be VERY VERY COOL (Andrey?)  I don't mind losing the occasional instantiation of a task, especially if it just means I need to complete it again, but notes are real data and would be worth a special case or their own time stamp, or appending the two on Android in case of conflict.

Lisa

[daniel sekera]

that is how I started I think

i added a task (also called testparent) on android in my inbox.  i then added a note to it.  and sync'd.  then on my pc i changed the note and added children and re-occurance and then synced and everything was fine.  then i started completing sub tasks and making changes and letting them reoccur and so on and so forth and i think (but i may be wrong) that i tried every combination but it didn't break

do you have that specific order that caused yours to break? or point me to the thread that has the order? now i have doubts that my data is intact on all that was pre-existing

[m...@grantsmiths.org]

Daniel: here is the case that Lisa documented in the Beta forum:

 

Android sync should be set to "use server version".

 

Create a tree that looks like this (I created it from the PC)

Testparent

    test1

    test2

    test3

 

Set  [ start/due yesterday ] [ recur daily ] [ automatically recur when all subtasks are completed ] [ set all tasks to uncompleted ] on Testparent. 

 

Sync both ways, to Android and back to PC. (It helps to set view mode to full and turn off hiding of completed tasks in the Outline).

 

On Android, complete but do NOT sync (you are completing *yesterdays* occurrence - they are now due today) 

    test1

    test3

 

On PC complete  Testparent (catch up on yesterday)

On PC complete test2 (now it's done for today). 

Sync PC.

 

Sync Android.

 

Sync PC.

 

Result:

Parent is uncompleted, set to today, with all tasks completed -- a state that should never happen due to the automatic recurrence. Additionally, I NEVER COMPLETED test1 OR test3 *today*. They should be set to yesterday -- I consider this to be (mild) data loss because a task was marked complete for today without my knowledge.

In addition I know of another case involving the same testparent and three children, starting out dated for yesterday. On Android, complete the parent (regenerating the parent for today) and then complete a couple (but not all three) of the subtasks. Do not synch. On Windows, select the parent (still pointing to yesterday) and open the recurrence popup. Do not make any changes. Close it. Sync windows to cloud then phone to cloud then windows to cloud. The two tasks you completed for today on the phone are now shown as completed for yesterday.

-Dwight

[Lisa Stroyan]

It's likely your data is fine -- I've only lost data when I was really trying :)

The difference I think is that you are syncing after you make your changes. I was not. The other example was something like, create a task that auto completes and regenerates when subtasks are completed. Sync everything, so that you have it all the same. Then, without any more syncing, change the note on android and complete all the subtasks on the PC.  Sync PC first, then Android, the note change gets lost. (going from memory)

Lisa