Events are being duplicated

DAVDroid has recently begun to duplicated repeating events [annot: just checked: This does not only affect repeating but also one time events, not all of them, though] from two of my calendars, both of which are from Nextcloud 11. One of the calendars being readonly, the other one read-write. I see one event 8 times for the same date, another one 4 and another one 2 times. I have no issues with them on other clients.

I used to observe the same problem in the past, but at some point it went away. Now it is back, for some reason.
If you need logs, I can happily provide both DAVdroid and nextcloud server logs, but I am not sure what kind of logs are needed, please advise.

Not that I know of. The multiplication of events seems to happen at random

Does it only happen for recurring events?

I think that used to be the case some time ago, but now even single, non-repeating events appear multiple times in the calendar.

Some of these problems were fixed in newer calendar providers, so updating the Android version might help.

In fact I have not yet experienced the issue on a different device with newer Android version. Not sure about which Android version is my friend who is also experiencing this issue on, will get back to you on that one

@benjamin-kwiatek In our tests and for thousands of Nextcloud and iCloud users, this problem does not occur so we won’t remove them from our list. We also use DAVdroid for ourselves and have not seen this problem.

Again: Is there a way to reproduce the problem? For instance, a test account for which the same steps lead to duplicated events? Without ever having seen this problem, I really can’t look into it.

I know it’s a developer’s nightmare but Kuba stated correctly. IT HAPPENS RANDOMLY.

I’ve deleted my recent duplicates and recreated the event exactly as before.
But the duplication didn’t take place this time.

But the problem REALLY EXISTS and as Kuba confirms, it’s not just the fault of my sh**ty LG phone still waiting for Android 7…

Is there any way I can inspect the calendar storage since the problem seems to come from the way davdroid uses this layer? (Remember: I can make the problem go away be deleting all the calendar storage data and resyncing).

Is there any way I can inspect the calendar storage since the problem seems to come from the way davdroid uses this layer? (Remember: I can make the problem go away be deleting all the calendar storage data and resyncing).

The best approach I know is to have DAVdroid logs on all the time and wait for some duplication, and then graze through all the logs.

You can also query the calendar storage by various methods. If you have a rooted phone, you can fetch the whole DB. Or you can do adb shell and then query the provider like content query --uri content://com.android.calendar/calendars (requires USB debugging active). You can view

Until today I thought that the problem is related to the S-Planner app. But with the last update of DavDroid S-Planner crashes nearly on every operation, so I switched to DigiCal. But the duplicated entries remains.

The duplications in my case only appear on birthdays (which is 95% of my repeated events).
About 20% of the birthdays are not duplicated
About 50% of the birthdays are twice
About 30% of the birthdays are triple

Desktop applications (like Thunderbird Lightning or Apple Calendar) does not show this behaviour.

well, not an option for me
anyway - throwing the phone into a river does not alter the ics entries within the database - therefore I doubt that an invalid entry is the culprit. Probably it is related to caching of DavDroid?

@kuba-orlik Would be interesting which device you now have. As said above, we need much more information. Every information we can get, because we have too little information to find the cause of your problem.

I also guess that you didn’t switch server, so for me it sounds like that could be related to your server… especially when considering that most people (including myself, using DAVdroid every day) don’t have that problem. But who knows, without logs and reproducing we won’t find it out.