http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #12 from alainlux <[email protected]> 2010-11-22 04:11:50 PST --- (In reply to comment #11) > The logs on the server side would be more interesting than the logs from the > client side. Yes, that's what I figured... > But before we go there, let's try to simplify the testing by focusing on the > core aspect which fails here: change detection on the server side. This can be > tested on the server side with "syncevolution --status <client config name> > calendar", without running a sync. Indeed, this simplifies a lot. Indeed, the first run after change says: > syncevolution --status n900 calendar [INFO] addressbook: inactive [INFO] todo: inactive [INFO] memo: inactive [INFO] Local item changes: +---------------------------------------------|-----------------------+ | Source | NEW | MOD | DEL |TOTAL| +---------------------------------------------+-----+-----+-----+-----+ | calendar | 0 | 0 | 0 | 159 | +---------------------------------------------+-----+-----+-----+-----+ | start Mon Nov 22 12:45:18 2010, duration 0:00min | +---------------------------------------------+-----+-----+-----+-----+ Local data changes to be applied remotely during synchronization: *** calendar *** no changes ... and the next one says: [INFO] addressbook: inactive [INFO] todo: inactive [INFO] memo: inactive [INFO] Local item changes: +---------------------------------------------|-----------------------+ | Source | NEW | MOD | DEL |TOTAL| +---------------------------------------------+-----+-----+-----+-----+ | calendar | 1 | 0 | 0 | 160 | +---------------------------------------------+-----+-----+-----+-----+ | start Mon Nov 22 12:45:27 2010, duration 0:00min | +---------------------------------------------+-----+-----+-----+-----+ Local data changes to be applied remotely during synchronization: *** calendar *** after last sync | current data removed since last sync < > added since last sync ------------------------------------------------------------------------------- > BEGIN:VCALENDAR > VERSION:2.0 > BEGIN:VEVENT > SUMMARY:zozo > DTEND;TZID=Europe/Paris:20101123T14 > 0000 > DTSTART;TZID=Europe/Paris:20101123T > 130000 > UID:e0d466e6-b1ec-49fc-bea9-7d94ab6 > ae71e > X-EVOLUTION-CALDAV-ETAG:"347697bf1a > f83454521ed8f27c82f0a3" > X-EVOLUTION-CALDAV-HREF:/caldav/cal > dav.php/alain/home/e0d466e6-b1ec-49 > fc-bea9-7d94ab6ae71e.ics > END:VEVENT > BEGIN:VTIMEZONE > TZID:Europe/Paris > X-LIC-LOCATION:Europe/Paris > BEGIN:DAYLIGHT > DTSTART:19700328T020000 > RRULE:BYDAY=-1SU;BYMONTH=3;FREQ=Y > EARLY > TZNAME:CEST > TZOFFSETFROM:+0100 > TZOFFSETTO:+0200 > END:DAYLIGHT > BEGIN:STANDARD > DTSTART:19701031T030000 > RRULE:BYDAY=-1SU;BYMONTH=10;FREQ= > YEARLY > TZNAME:CET > TZOFFSETFROM:+0200 > TZOFFSETTO:+0100 > END:STANDARD > END:VTIMEZONE > END:VCALENDAR ------------------------------------------------------------------------------- > > As soon as you add a new event in CalDAV, the command should show a) one item > added in the statistics table and b) the new item data in the diff. Only happens after I run syncevolution --status the second time after the change. > I have a theory: adding the event does not show up immediately via libecal, > which is what SyncEvolution is using. Sometime later, EDS notices and the > event > appears. In the example logs, that happened to be between starting and > completing the first sync run. > > Does that sound plausible? Hmmm, not really... It doesn't seem to be timing dependant... even waiting several minutes before the first syncevolution still keeps the same behavior... > > If that is the explanation, then I see only one solution: write a native > CalDAV > backend instead of relying on the EDS bridge. There is no call which tells > libecal to refresh the data immediately, so there will always be this delay. Indeed, this is what seems to be happening: syncevolution connects to Evolution Data Server, which only seems to poll caldav _after_ the connection (or at least _after_ feeding its state to syncevolution). So, a workaround would be to run syncevolution --status first (on PC), and only then run the syncevolution client from the mobile. Syncevolution seems to communicate with EDS using DBUS. Maybe there is one DBUS command which causes EDS to "refresh" itself from caldav which is being sent too late? Is there a "tcpdump"-like tool for DBUS, so that I could find out what happens? -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
