DAVdroid can't handle events prior 1950



  • Hi rfc2822,

    thanks a lot for testing. I am aware of the 1902 restriction which is clearly an Android limitation; and truely annoying, too. Don’t really understand the intention of restricting a calendar to a particular epoch, like life hadn’t existed before 1902. But that’s another topic.

    I’ve never seen the structure of your data within the ics files on my CalDAV server. Am I guessing right, that this data is what DAVdroid sends to the CalDAV server and then the server actually creates the ics file? Anyhow, this doesn’t explain why DAVdroid can’t handle files of the structure I posted, whereas aCalDAV on Android and Thunderbird/Lightning on the PC can. If it were the calendar provider, the event would just never show up on Android. That’s why I think that there’s got to something to be fixed in DAVdroid.

    Best of regards

    Florian


  • developer

    @flosch said in DAVdroid can't handle events prior 1950:

    I’ve never seen the structure of your data within the ics files on my CalDAV server. Am I guessing right, that this data is what DAVdroid sends to the CalDAV server and then the server actually creates the ics file?

    No. What I have posted is the data as required by the Android Calendar Provider. DAVdroid parses the VEVENT from the ics file and converts it into data for Android calendar provider (see the image on https://davdroid.bitfire.at/faq/entry/system-integration/).

    Anyhow, this doesn’t explain why DAVdroid can’t handle files of the structure I posted, whereas aCalDAV on Android and Thunderbird/Lightning on the PC can. There’s got to be something to fix this in DAVdroid.

    It can handle it here. So I guess it’s a problem of your calendar provider. It’s indeed strange that aCalDAV works on your device, but of course I can’t give you any details because I can’t reproduce the problem here.



  • Thanks again for replying so quickly. As stated above, if aCalDAV and Thunderbird/Lightning can handle these events, I would assume that it’s not a problem with the calendar provider. That makes just no sense to me.

    I understand perfecly well that you can’t help on a problem which you can’t reproduce. Is there any additional information that could help? Anything I could try instead? Any idea where the problem could be?

    Edit: judging from your information on how the data is handled, I would then assume the problem is how DAVdroid converts the data for the Android calendar provider.


  • developer

    @flosch said in DAVdroid can't handle events prior 1950:

    I understand perfecly well that you can’t help on a problem which you can’t reproduce. Is there any additional information that could help? Anything I could try instead? Any idea where the problem could be?

    It would be necessary to reproduce the problem. Which device do you have? I suggest to post the debug info, as described in https://forums.bitfire.at/topic/749/read-before-posting-what-s-required-to-diagnose-a-problem/ It contains very important data like the device model and Android version, which is the reason why its should really be provided together with every problem report or question.

    Edit: judging from your information on how the data is handled, I would then assume the problem is how DAVdroid converts the data for the Android calendar provider.

    Why? I have posted the data which is generated by DAVdroid and it seems to be correct:

    • dtstart=-610761600000: UNIX time -610761600 is Fri Aug 25 00:00:00 1950 UTC ✓
    • duration=P1D seems to be OK for an all-day event ✓
    • rrule=FREQ=YEARLY;WKST=MO directly taken from the VEVENT ✓


  • @rfc2822 said in DAVdroid can't handle events prior 1950:

    Why? I have posted the data which is generated by DAVdroid and it seems to be correct:

    Sorry I was unclear about that. I didn’t doubt the validity of the data itself DAVdroid generates. Deducing from your information, the Android calendar provider handles events due to how either DAVdroid or aCalDAV or whatever DAV-sync-app provide the information. Since events processed by aCalDAV are handled correctly whereas the very same events handled by DAVdroid aren’t, that’s why I doubt the Android calendar provider to be the problem here. It could be, though, that both the calendar provider and aCalDAV stick to some non-standard protocol to transfer information whereas DAVdroid sticks to standard protocols the calender provider unfortunately doesn’t understand. But still, the events get rendered correctly between aCalDAV and the Android calendar provider which, by logic, exclude both from being the problem. Am I wrong? [mebeingconfused]

    I will provide the required debug information as soon as possible. Meanwhile: using Android 5.0.2, Calendar 4.40.17, DAVdroid 1.7.1-ose and aCalDAV 0.1.1.



  • Please find here the Debug info of DAVdroid. Just tried connecting to the CalDAV server via the internal LAN address instead of the internet which makes things even worse: now DAVdroid was unable to render the 1950 event as well. Randomly tried 1970 and it won’t show either. Only very recent events worked—very mysterious.


  • developer

    @flosch Then it seems quite clear to me: the server doesn’t send the event in the reply for the REPORT calendar-query of DAVdroid, which only requests event for 90 days into the past (+ forever in the future). The server has to calculate start and end date of recurring events and report them accordingly.

    It also explains why the events show up in aCalDAV and Thunderbird: those probably don’t use REPORT calendar-query, but other methods like a worse-performing general PROPFIND instead (where the server doesn’t do any filtering).

    To be sure please try to set the “Limit sync to X days in the past” setting in the DAVdroid account and leave the setting blank (default value: 90 days). Then sync again. If the event appears then, it’s clearly a server bug. By the way, which server do you use? This is a very important piece of information (as mentioned on https://forums.bitfire.at/topic/749/read-before-posting-what-s-required-to-diagnose-a-problem).



  • Colour me impressed! Leaving “Limit sync to X days in the past” blank really did the trick. To be honest, I doubted that solution because addressing the server via the internet (dyndns equivalent) instead of the home network, events past 1950 and not only the very recent showed up. And 1950 clearly is more than 90 days in the past! How come this is interpreted differently if either I address the server via the internet or via the internal LAN? The server is a Synology WebDAV, Version 2.3.3-0024, by the way. I wouldn’t expect much from filing a bug, however, since Synology is really slow, if caring at all.

    As yet I was just testing DAVdroid. Hence the free version. Now that everything seems to work, I will move to the non-free version to support development. Thanks again for your help, well done.

    Edit: is there a way to mark this solved?


  • developer

    @flosch I have set it to solved. Please report the bug to Synology nevertheless and provide the synology ticket ID for reference here, if possible, so we can mention it when someone encounters this problem in the future again.



  • I shall consider it. Two more questions off-topic:

    • do the free version 1.7.1-ose and the non-free version 1.7.1 of DAVdroid differ? If not, I will stick to the ose version and donate instead.
    • bying the app over amazon is EUR 3.19; how much do you (the DAVdroid developer(s)) get and what is Amazon’s share? Because the latter would be an additional reason for me to not buy the app but instead stick to the ose version and donate.


  • @flosch There is no difference in features (only a donation dialogue on startup)! The shops always take 30%. So in any case we prefer donations 🙂 Thanks in advance!



  • Thanks for the clarification. It’ll be a donation, then!



Similar topics