Regression from 1.11 to 1.11.2: not syncing new calendar events to/from ownCloud server

---

(edit: merged multiple postings to one thread)

Hi,

I have a One Plus 5, with DAVDroid syncing Contacts, Calendar and Tasks to/from an ownCloud 10 server I control. I have just gone through a long troubleshooting session where new calendar entries created on the phone were not sent to the server, and new calendar entries created on the server were not retrieved to the phone.

Authentication etc were all fine. I saw PROPFIND for /remote.php/dav/calendars/<myuser>/defaultcalendar/ in server logs which received an HTTP 207 response, followed by a REPORT which received a larger 207 response. Same for other calendars and for the contacts. But no new entries would show.

I tried deactivating the calendar in the DAVDroid account settings, syncing, then enabling it and syncing again. This caused me a world of hurt, as I found out that 1.11.2 is very strict about timezone problems, even rejecting files it created itself in previous versions (https://forums.bitfire.at/topic/1727/nullpointerexception-attempt-to-invoke-virtual-method-void-java-util-calendar-settimezone-java-util-timezone-on-a-null-object-reference/12). Synchronization failed on entries from 3 years ago, and I did not see anything on my phone’s calendar. I solved the timezone errors by doing some UPDATEs on the ownCloud DB, coupled with editing some entries in Thunderbird’s calendar editor. DAVDroid still rejected an ICS which had been just saved by Thunderbird.

I deleted the account in DAVDroid and added it again. This time, no errors, which was strange. Except, no calendar entries either.

Again I saw PROPFIND and REPORT:

[14/May/2018:00:32:14 +0200] "PROPFIND /remote.php/dav/calendars/<myuser>/contact_birthdays/ HTTP/1.1" 207 5786 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:15 +0200] "REPORT /remote.php/dav/calendars/<myuser>/contact_birthdays/ HTTP/1.1" 207 12394 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:16 +0200] "PROPFIND /remote.php/dav/calendars/<myuser>/defaultcalendar/ HTTP/1.1" 207 5796 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:17 +0200] "REPORT /remote.php/dav/calendars/<myuser>/defaultcalendar/ HTTP/1.1" 207 224304 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:22 +0200] "PROPFIND /remote.php/dav/files/<myuser>/ HTTP/1.1" 207 1175 "-" "Mozilla/5.0 (Linux) mirall/2.3.4"
[14/May/2018:00:32:23 +0200] "REPORT /remote.php/dav/calendars/<myuser>/defaultcalendar/ HTTP/1.1" 207 61630 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:24 +0200] "PROPFIND /remote.php/dav/calendars/<myuser>/<a-readonly-holiday-calendar>/ HTTP/1.1" 207 5799 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"
[14/May/2018:00:32:24 +0200] "REPORT /remote.php/dav/calendars/<myuser>/<a-readonly-holiday-calendar>/ HTTP/1.1" 207 20450 "-" "DAVdroid/1.11.2-ose (2018/05/05; dav4android; okhttp/3.10.0) Android/8.0.0"

I did not check if Contacts were synced properly. But DAVDroid took a noticeable while to sync the contacts, so I assumed those were working. But no calendar entries for the default calendar.

This went on for multiple troubleshooting steps with no effort. Only when I uninstalled the software and installed version 1.11, did everything suddenly magically start working. The calendar synced, no errors, everything was fine. I believe I had also uninstalled and reinstalled version 1.11.2 before this, with no success, but I am not 100% certain.

I noticed that version 1.11.2 has a new feature for collection synchronization. Could the software somehow have decided that the entries on the server were stale and not worthy of being downloaded?

In any case, I am now scared of upgrading, after a couple of hours lost to troubleshooting and following red herrings. I fear I will get the silent sync failures and/or the verbose timezone errors again.

I ran an SQL query to replace all the Atlantic/Madeira TZs in my ownCLoud, but now the problem is happening on another ICS file. This one was created by DAVDroid itself, back at version 1.2.3.

0_1526248257936_147217108840redacted.ics

It seems to me like DAVDroid has somehow become less tolerant of timezone settings, rejecting anything it doesn’t understand and dying horribly in the process. With the consequence of a broken sync. At least from an empty calendar one gets the error notification, but with a full calendar I had silent failure.

DAVDroid 1.11.2 even rejected this ICS, which has been opened and saved with Thunderbird to make sure there is no invalidness:

0_1526252437591_3e925d1c-58f2-4472-9fae-a0979297bb38.ics

Hello,

Thanks for your report. Can you please provide steps to reproduce, DAVdroid debug info (I don’t ask for this because I want to give you a hard time, but because this contains for instance the Android version, which I believe to be very important tho this problem, as it seems only to be happening on 8.0.0) and verbose DAVdroid logs etc as described in [READ BEFORE POSTING] What’s required to diagnose a problem?

Without these logs, it’s not really possible to have a look at your problem.

Did you update your Android version recently?

In any case, I am now scared of upgrading, after a couple of hours lost to troubleshooting and following red herrings. I fear I will get the silent sync failures and/or the verbose timezone errors again.

Guess how many hours I have already spent for this and other problems I could never reproduce… that’s IT

Please note that Thunderbird is not an iCalendar validator. However, I don’t see any problem with this iCalendar event here, it looks like this on my Android 8.1 emulator (25 Nov 2016 10:30 +00 = 25 Nov 2016 11:30 CET, which is used in the calendar view):

Also, which past time event limit have you set in the account? This information is also contained in the debug info, so please provide the debug info as described in [READ BEFORE POSTING] What’s required to diagnose a problem.