On Mon, 2012-08-13 at 13:44 -0400, Ross Vandegrift wrote:
Yesterday I used syncevolution to push my my address book out to Google
Contacts via SyncML. In a subsequent run, some contacts had photos
auto-added by Google.
This has partially broken sync with my S40 phone. It imposes a max
message size of 3k, and the images push those contacts over the limit.
Syncevolution notices this:
WARNING: outgoing item is larger (5334) than MaxObjSize (3000) of remote
-> suppress now/mark for resend
A small message size would lead to splitting of items. But the phone
also imposes that size for every single item, and therefore larger items
can never be sent.
The sync mostly works, but takes around 15 minutes to finish. The
first time, my phone's progress indicator stuck at 95% complete. On
subsequent syncs, the phone finishes quickly but syncevo still waits
for 15 minutes. Oddly, the times in the log do not reflect this.
Could this be because of dumping data? When you run SyncEvolution
1.2.99.x on the command line, you should see some output indicating that
it is busy doing these data dumps (usually enabled for the automatic
I don't care about having the photos associated with the
they be stripped out before contacts are sent to the phone? The only
config option on the phone side is to require a username/password.
Sorry, there is no option readily available for this. I can think of a
very convoluted way of doing it without recompiling (override DevInf of
the phone with a DevInf which doesn't list PHOTO as supported), but
probably that's overkill.
Actually, there is probably an easier way. Can you look at a
syncevolution-log.html and send me the model and manufacturer string of
I'm going to try updating the script files so that for this phone, PHOTO
data is stripped before encoding the data as vCard. Further work will be
needed to ensure that receiving an update from the phone the photo is
not removed on the host.
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.