http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #11 from pohly <[email protected]> 2010-11-22 03:29:56 PST --- (In reply to comment #10) > I think I've already posted all relevant HTML log files, including the one on > the PC after first sync (see > http://bugs.meego.com/show_bug.cgi?id=10265#attach_3580). > > The two client html files are from an earlier session, but the server html > file > is from the same session as the stdout of syncevo-dbus-server. > > If you need any additional log file, which would it be? The logs on the server side would be more interesting than the logs from the client side. 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. 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. 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? 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. -- 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
