Yes! Problem is solved for me, too.
Disabeling the CyanogenMod Privacy Guard was the solution.
Thank you all!
As you can see in the below referenced screenshots, tasks- specifically repeating ones, are failing to update on desktop  when marked complete on mobile .
I sync between Android & FastMail using DAVDroid, then from FastMail to Thunderbird/Lighting via the associated DAV account.
I’m on Linux Mint 18.3
Earlier this week when I was testing after first setting it up, it seemed to work fine. I don’t know what might have changed to make it fail today.
Received a reply from the developer, stating:
“This should be fixed with the upcoming 2.0 release.”
Will check back afterward with status.
FastMail support got back to me & they were able to isolate the problem I’m seeing to what the aCalendar devs are calling the ‘Sync Adapter’, which I’m assuming is DAVDroid.
The specific logs in question are as follows:
2018-11-15T03:36:25-05:00 imap3 sloti3d1t15/httpcaldav: frontend1.nyi.internal [10.202.2.160] as "firstname.lastname@example.org" with "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Lightning/18.104.22.168"; "PUT /dav/calendars/user/name%40domain.com/b160c0f1-0b45-44d3-967b-dcaf9e52d49d/e93e6404-85ef-4f4a-a4a5-084a3546267b.ics HTTP/1.0" (auth=Basic; if-match="9ff998eed5fd3af98ab2df305d97f98a8cd5593d") => "HTTP/1.0 204 No Content" [timing: cmd=0.024581 net=0.002257 total=0.026838] 2018-11-15T03:48:51-05:00 imap3 sloti3d1t15/httpcaldav: frontend2.nyi.internal [10.202.2.161] as email@example.com" with "DAVdroid/2.0.5-gplay (2018/11/04; dav4android; okhttp/3.11.0) Android/7.0"; "PUT /firstname.lastname@example.org/b160c0f1-0b45-44d3-967b-dcaf9e52d49d/e93e6404-85ef-4f4a-a4a5-084a3546267b.ics HTTP/1.0" (auth=Basic; if-match="9ff998eed5fd3af98ab2df305d97f98a8cd5593d") => "HTTP/1.0 412 Precondition Failed" [timing: cmd=0.002103 net=0.000003 total=0.002106]
The first is showing the modification of an existing task (with last seen etag “9ff998eed…”). The modification succeeds, and so the etag changes. Then, 12 minutes later, the client tries to modify the same task again, using the same etag as before. But that’s no longer valid for that task, so the request fails.
This behavior is by design, see here: https://www.davdroid.com/manual/synchronization/#c213 – when there is a conflict, DAVdroid lets the server always win.
If you know or suspect that a resource has been changed on another device since the last sync, I’d force sync before editing such a task.
Does that help?
This behavior is by design
Does that help?
Ok, thanks. Am grasping at straws here with no idea why mine won’t sync properly on a consistent basis.
I guess this means I’m at the whim of whenever this “upcoming 2.0 release” happens.
Version 2 was released yesterday & now recurring tasks marked complete on Android indeed sync properly to Desktop. However there are severe problems remaining.
Only recurring tasks created on Desktop will increment to their next due date properly after being marked complete. The recurring tasks created on Desktop can be marked complete either on Desktop or Android & be expected to increment properly.
Recurring tasks created on Android fail to increment properly when marked complete on either Android or Desktop. They’ll look like they’ve incremented to their next due date on Android, but on Desktop their ‘Due Date’ field remains set to the date the task was created rather than the next due date, & as such will show as overdue. The ‘Start’ date is what is visible as having been incremented when looking at the task on Desktop. The Android version calls this ‘Start’ field ‘Due’, & doesn’t differentiate between ‘Due’ & ‘Start’ date/times.
I’ve emailed the developer with MB’s of screenshots in hopes of finding a solution. Will post updates here.
Not only are the aforementioned issues persistent, there are also problems with tasks marked complete on Desktop not changing on mobile. No word from Tapir Apps. Giving up hope. Will have to just use ToDo list on mobile exclusively.