Exceptions to recurring events wrong

  • developer

    Does that mean that I’ll see the entries correctly on the smartphone, but if I edit any of the entries all of the exclusions will be gone?

    Yes, I guess so. To generate the new .ics file for the upload, DAVdroid needs to fetch the “main event” (including RRULE, RDATE, EXRULE, EXDATE) + all exceptions (= VEVENTs with RECURRENCE-ID).

    So DAVdroid queries the Android calendar provider for the event, but the calendar provider returns EXDATE=null even if the EXDATE was set by DAVdroid.

    This means that the uploaded event won’t have EXDATEs.

    Please keep in mind that various calendar apps or the calendar provider might also truncate events and generate some others. This is out of the scope of DAVdroid which only syncs the content of the calendar provider with the CalDAV server, see also https://twitter.com/davdroidapp/status/527057795980754945.

  • Hmmm, please forgive me for asking …

    Perhaps DAVDroid could store the change, and when there’s connectivity again it could fetch the original data, apply the change, and use that information instead of the one coming out of Android?

    Or it might just store the original entry in its sqlite… I’ve got quite a few calendar entries, but the ICS file is still only half a megabyte, so the additional size shouldn’t really matter that much.

  • Or just storing the EXDATEs might be sufficient, too…

  • I’m about to try the new version … I guess just installing isn’t enough, is there a way to re-fetch the items from the server?

    I’d like to avoid removing and re-adding the account, typing the URL and the password isn’t that funny.

  • Unfortunately, no. You need to add the account again. We will add this feature shortly before we’re reaching Version 1.0 of DAVdroid.

  • Hmmm, why not add it sooner, eg. now? 😉

    Thanks for the answer, though. I guess that changing the modification timestamp on the recurring events should be enough, too, right?

  • developer

    Hmmm, why not add it sooner, eg. now? 😉

    High-quality pull requests are always welcome.

    Thanks for the answer, though. I guess that changing the modification timestamp on the recurring events should be enough, too, right?

    Yes, any change that causes the ETag to change is enough.

  • Hmmm, I now tested that by installing current git HEAD, changing the time of the above event, and rebooting concurrently.

    After getting the update the smartphone showed Dec. 1st and Dec. 8th - but Dec. 15th was gone, so something’s still wrong here.

    Trying with a fresh full-day event gives the expected result, though; giving that one then a start- and end-time shows it on all three days again…

    Here’s its data:


  • developer

    Seems like multiple EXDATEs in multiple lines are not handled… Can you confirm that


    works for you, too?

  • developer

  • Current git HEAD seems to work for me. Will tell if there’s anything unexpected.

    Thank you!

Log in to reply

Similar topics