5:43 a.m.
Hello!
Sorry, late reply again. I expect to be more responsive going forward.
On Mi, 2010-11-24 at 09:05 +0000, knipp(a)m-otion.com wrote:
Good morning!
On Tue, 23 Nov 2010, Patrick Ohly wrote:
> Let's compare notes... is sysync::TLocalEngineDS::isDatastore called? Is
> it the same call stack as in my email?
Yes, it is. I must have been disoriented in the code during the last
(nightly) debugging session.
I've attached a cleaner patch.
I hope it doesn't look like nit-picking, but I reworked the patch
slightly to avoid a run of findLocalDataStoreByURI() with an empty URI
and the copying of the target URI into a std::string. Revised patch
attached and in "master" branch of libsynthesis on git.meego.com.
The synchronisation of my address book seems to work, currently only
as
slow-sync and with repeated duplication of some (not all) entries.
syncevolution still reports an error
[ERROR] OBEX Request 1 got a failed response Internal server error
[ERROR] ObexTransprotAgent: Underlying transport error
That is at the very end. I could imagine that the phone no longer
expects a reply at that point and when it gets one, gets confused about
whether the session has ended successfully. Or it parses the reply, but
then doesn't quite grok the content.
Either way, the log shows that the phone sends a presumably invalid
anchor with value '0':
| Saved Last Remote Client Anchor='1226', received <last> Remote Client
Anchor='0' (must match for normal sync)
This does not match, so we end up with a slow sync.
I'll send you the syncevolution-log.html by private mail
(loglevel=2,
7MB).
Calendar synchronisation shows similar symptoms.
BTW: loglevel = 4 in conjunction with over 700 contacts and slow sync
generates a really huge log file :) Maybe too large for Firefox ;)
Oops ;-}
Perhaps you can configure the local Evolution side to synchronize
against an empty address book resp. calendar? For that create new
database in Evolution, set "evolutionsource" to its name, then sync with
"refresh-from-server" (to get rid of the large numbers of items on the
phone, at least temporarily; I assume that they can be restored there
later with another "refresh-from-server" with the real data).
loglevel=4 is necessary to a) debug the content of the last reply to the
phone (the one which triggers the OBEX "Internal server error") and b)
debug the duplication/mangling of items during slow syncs and other data
conversion issues.
For a) please send an archive which includes the *.xml message dumps.
For b), try to replicate each individual problem and send the
syncevolution-log.html in which it occurs.
However, I recently noticed that the slow sync resolution policy was a
bit conservative and favored item duplication over merging of item data
(which comes with the risk of data loss). People complain more about
duplicate items than data loss (at least right now; I hope none will
complain about that change once it reaches them ;-), so I changed that
in the development versions and the syncevolution-1-1-branch:
http://meego.gitorious.org/meego-middleware/syncevolution/commit/24cb098d...
Does that make a difference in your duplication cases?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.