• developer

    @42gd42 F-Droid doesn’t work that way. You can’t upload anything there, they fetch the source whenever a new version is detected (in DAVdroid’s case, by a version tag in the git repository) and then compile it automatically. And 0.5.6-alpha is the current version there: https://f-droid.org/repository/browse/?fdfilter=davdroid&fdid=at.bitfire.davdroid

  • developer

    Any news on this issue?

  • Not for now. The data usage is much lower now. It seems like the update to 0.5.6 and the new account solved the problem. Thank you!

    rfc2822 notifications@github.com schrieb:

    Any news on this issue?

    Reply to this email directly or view it on GitHub:

  • developer

    @42gd42 Is it OK for you too?

  • @rfc2822 Unfortunately no. I updated for 0.5.6 deleted and created new account but the use of data is the same. I will try to provide logs following your explanations.

  • @rfc2822 I think the synchronization process of DAVdroid is not really efficient. I’ve got an owncloud instance with 10 calendars. Each has events of multiple years.
    When syncing (no force sync) DAVdroid does the following for <b>every</b> calendar:


    22:24:52: DAVdroid/0.5.6-alpha - bastei, PROPFIND - 117 - /owncloud/remote.php/caldav/calendars/bastei/cal_1/
    <propfind xmlns="DAV:">
          <CS:getctag xmlns:CS="http://calendarserver.org/ns/"/>

    Now owncloud responses with the ctag of the calender and <b>“404 Not Found” for every event</b> of the calendar, because they don’t have ctags.

    Next request:

    22:24:53: DAVdroid/0.5.6-alpha - bastei, PROPFIND - 134 - /owncloud/remote.php/caldav/calendars/bastei/cal_1/
    <propfind xmlns="DAV:">
          <CS:getctag xmlns:CS="http://calendarserver.org/ns/"/>

    The response of owncloud <b>contains the same as the previous</b>, but now contains the etags for every event.

    As I said, this is done for every calendar. All in all one synchronization is about 1 MB download, if nothing changed. Most of it redundant and unnecessary information.


    Here comes my suggestion:

    1. Get the ctags of the calendars from the “root”:<br/><code>PROPFIND - /owncloud/remote.php/caldav</code><br/>So you only get the ctags for the calendars, not the events (10 entries for me vs. 1000+).
    2. For every changed ctag, get the etags (second request)
    3. Make use of REPORT with <b>time-range</b> (https://github.com/rfc2822/davdroid/issues/76) for 2.! Here is an example:
    REPORT - /owncloud/remote.php/caldav/calendars/bastei/cal_1/
    <c:calendar-query xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">
            <d:getetag />
        	<c:comp-filter name="VCALENDAR">
        		<c:comp-filter name="VEVENT">
        			<c:time-range start="20131019T000000Z"/>
  • developer

    So you only get the ctags for the calendars, not the events (10 entries for me vs. 1000+).

    This is the way how DAVdroid is intented to do and how it does here. If it does not, it’s a bug. I will have a look at it as soon as I find time.

  • Ok, it is a bug then. Would be nice if you could fix it!

  • @rfc2822 You can find a log file here (duration: ~1 hour):
    obtained with <code> adb logcat | egrep ‘^(E/)|(./davdroid)’ </code>

  • admin

    Thanks, I downloaded it and will forward it to the main developer.

Similar topics