[Syncevolution-issues] [Bug 86335] abnormally high network traffic when synchronizing calendar in CalDAV

https://bugs.freedesktop.org/show_bug.cgi?id=86335 --- Comment #5 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- (In reply to Sébastien Villemot from comment #4) I forgot to comment on that. That happens on the server side. There was a recent change in libical that causes it to include the entire history of a time zone in each item. For example, most data logged for the first item in your log file is just the VTIMEZONE: <getetag>"c6dd224d03da4ef8a74750b9dc73d40c"</getetag> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:/freeassociation.sourceforge.net/Tzfile/America/Montreal X-LIC-LOCATION:America/Montreal BEGIN:STANDARD TZNAME:EST DTSTART:19691026T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 X-RADICALE-NAME:/freeassociation.sourceforge.net/Tzfile/America/Montreal END:STANDARD BEGIN:DAYLIGHT TZNAME:EDT DTSTART:19700426T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 X-RADICALE-NAME:/freeassociation.sourceforge.net/Tzfile/America/Montreal END:DAYLIGHT ... Worse, the *same* item also contains other VTIMEZONEs. I don't know why that happens. Radicale should only send the VTIMEZONE definitions actually referenced in an item. Check your .ics file - perhaps a client stored the item as it later gets send out by the server? But then the .ics file itself should already be much larger. For libical, see http://sourceforge.net/p/freeassociation/bugs/95/ http://lists.infradead.org/pipermail/libical-devel/2014-October/000627.html -- You are receiving this mail because: You are on the CC list for the bug.