On Mon, 2012-08-13 at 19:09 -0400, Ross Vandegrift wrote:
On Mon, 2012-08-13 at 21:02 +0200, Patrick Ohly wrote:
> On Mon, 2012-08-13 at 13:44 -0400, Ross Vandegrift wrote:
> > 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.
In that circumstance, if one oversized item is too large, are all
changes to the contact reverted?
No. The local side no longer knows what those changes are. All it has is
an item which is too large to fit into the current recipient, and
therefore sending that item to that recipient is blocked in perpetuity.
I updated two contacts, one with
photo and one without. I added an email to both. Google and Evo show
the updated data correctly, but after syncing with the phone, only the
photo-less contact has been updated.
That contact was able to get through.
Yea - terminal says that, and disabling dumpData and printChanges
the delay. It seems weird that the backup is taking so long - prior to
the photos being added, backups took no more than 5 or 10 seconds.
What's your local storage? Adding photo data as inlined data (the only
option in EDS older than 3.4) increases the D-Bus traffic by several
orders of magnitude. It's a bit better with recent EDS, where contact
data is stored as plain files.
> I'm going to try updating the script files so that for this
> 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.
That sounds good to me - I'm happy to test anything you need. I gave
it a shot, and think I have the right idea, but can't figure out how to
put the pieces together.
I have it marked as a todo, but I am not sure whether I'll be able to
get to it this week.
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.