@rfc2822 said in Calendar sync stopping midway:
@zstephen said in Calendar sync stopping midway:
@rfc2822 How is there less than 10 bytes being transmitted if the sync is running? Wouldn’t the sync data itself contribute to the data being counted and keep the counter well over 10 bytes until the sync is complete?
Indeed. This is how it should work, and why I don’t understand the problem. As said before, I have never experienced or heard of the problem before, so it seems to be quite special.
do you want me to run another locgat and include a grep filter for SyncManager as well?
Maybe it could provide additional information. Every new hint could be helpful.
I’ve started another logcat recording session, I’ll allow it to run overnight and I won’t press manual sync. I have noticed that another batch of the balance of unsynced events is only being attempted if I create an event in zimbra. When I create an event, the phone will sync another batch when the next 15 minute interval passes around.
Another question, why would creating a new event in the calendar(from the zimbra side) cause the balance of items to start syncing again?
Are you sure that the automatic sync does not continue to download events?
Definately, I can’t understand what is causing the download to stop, but davdroid shows an event in the lead up to it stopping the download batch. When I email you the log file tomorrow, have a look around this time stamp, it’s an example where it stops after around 60 events, this batch of 60 only happens after I’ve created a new event in zimbra.
11-03 22:27:36.239 984 1014 W SyncManager: Detected sync making no progress for startTime 38438403, mTimeoutStartTime 38438403, mHistoryRowId 655, syncOperation JobId: 107076, email@example.com u0 (bitfire.at.davdroid), com.android.calendar, PERIODIC, reason: Periodic, period: 900000, flexMillis: 36000. cancelling.
Maybe I should broaden the scope of logcat to something else?
In addition to a new event created in zimbra causing the sync batch to resume for a while, at 22:45 I modified an existing event. There is some sync activity when the next 15 minute window passes around, but it doesn’t seem the same as if a new event is created and it’s more than the “stalled sync” behaviour
If you add an event on the server, the CTag changes. DAVdroid checks the CTag at the beginning of the sync, and synchronizes only when the CTag has changed. However, the CTag is remembered at the end of a successful sync, so DAVdroid should re-try after incomplete synchronization.
I’m not completely sure what CTag is. It sounds like in the context you used it, it denotes whether a sync needs to run on an event because it’s not been done yet or the event has been modified? Is there any more testing you want me to do on this area?