I installed davdroid 1 week ago and used it flawlessly with posteo. Last night davdroid used >220MB of data until the battery was empty.
My magic crystal ball doesn’t tell me why, so please provide logs.
My magic crystal ball doesn’t tell me why
Have you considered getting a replacement? Yours seems to be broken.
Hi,
I encounter the same issue. DavDroid takes 142MB in 3 days only just to synchronize a small calendar (the ICS file size is 80kB).
Thanks
@42gd42: My magic crystall ball still doesn’t work.
I’m monitoring the logs over night and send them if there is again such a hue data usage.
Am 10.01.2014 16:53, schrieb rfc2822:
My magic crystal ball doesn’t tell me why, so please provide logs
https://github.com/rfc2822/davdroid/wiki/How-to-view-the-logs.—
Reply to this email directly or view it on GitHub https://github.com/rfc2822/davdroid/issues/147#issuecomment-32038698.
@spuelrich Thanks. Maybe you can also try to delete and add the account again. There’s a reason that may cause strange behaviour when upgrading from 0.5.4 to 0.5.6.
I upgraded from 0.5.4 to 0.5.6 and recreated the account. No problems so far. I will monitor this for some more days.
rfc2822 notifications@github.com schrieb:
@spuelrich Thanks. Maybe you can also try to delete and add the account
again. There’s a reason that may cause strange behaviour when upgrading
from 0.5.4 to 0.5.6.
Reply to this email directly or view it on GitHub:
https://github.com/rfc2822/davdroid/issues/147#issuecomment-32101029
Could you please post the new version (0.5.6) on the F-droid store?
Nevertheless, thanks for the corrections.
@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
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:
https://github.com/rfc2822/davdroid/issues/147#issuecomment-32449650
@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:
Request
22:24:52: DAVdroid/0.5.6-alpha - bastei, PROPFIND - 117 - /owncloud/remote.php/caldav/calendars/bastei/cal_1/
<propfind xmlns="DAV:">
<prop>
<CS:getctag xmlns:CS="http://calendarserver.org/ns/"/>
</prop>
</propfind>
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:">
<prop>
<CS:getctag xmlns:CS="http://calendarserver.org/ns/"/>
<getetag/>
</prop>
</propfind>
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.
<hr/>
Here comes my suggestion:
REPORT - /owncloud/remote.php/caldav/calendars/bastei/cal_1/
<c:calendar-query xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav">
<d:prop>
<d:getetag />
</d:prop>
<c:filter>
<c:comp-filter name="VCALENDAR">
<c:comp-filter name="VEVENT">
<c:time-range start="20131019T000000Z"/>
</c:comp-filter>
</c:comp-filter>
</c:filter>
</c:calendar-query>
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):
http://www.utc.fr/filex/get?k=ShLzV4ezUrlDJJNpp0t
obtained with <code> adb logcat | egrep ‘^(E/)|(./davdroid)’ </code>
Thanks, I downloaded it and will forward it to the main developer.
