10:44 a.m.
Hello,
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
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.
I don't care about having the photos associated with the contacts. Can
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.
Thanks,
Ross
12:02 p.m.
On Mon, 2012-08-13 at 13:44 -0400, Ross Vandegrift wrote:
Hello,
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
backup feature).
I don't care about having the photos associated with the
contacts. Can
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
your phone?
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.
4:09 p.m.
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? 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.
> 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
backup feature).
Yea - terminal says that, and disabling dumpData and printChanges fixes
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.
[snip]
Actually, there is probably an easier way. Can you look at a
syncevolution-log.html and send me the model and manufacturer string of
your phone?
Sure - the log records the reported model as "Nokia 3720c". In case the
software version matters, that is recorded as "V 10.16 07-12-09 RM-518
(c) N."
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.
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.
Thanks,
Ross
12:04 a.m.
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
fixes
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
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.
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.
10:11 a.m.
On Tue, 2012-08-14 at 09:04 +0200, Patrick Ohly wrote:
On Mon, 2012-08-13 at 19:09 -0400, Ross Vandegrift wrote:
> Yea - terminal says that, and disabling dumpData and printChanges fixes
> 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.
My EDS is 3.4.3. The sync logs confirm that photos are stored in the
filesystem, and are inlined on the way to the phone.
> > 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.
>
> 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.
Cool, thanks. If I find time, I might continue to play around. Do
changes to the XML scripts require a rebuild? I was able to effect
changes by editing the scripts, but not by adding new ones.
Ross
1:04 a.m.
On Mon, 2012-08-13 at 21:02 +0200, Patrick Ohly wrote:
> I don't care about having the photos associated with the
contacts.
Can
> 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
your phone?
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.
Sorry, I haven't found the time and won't for a while. I've created a
feature request for this so that I won't forget and added some
implementation hints:
https://bugs.freedesktop.org/show_bug.cgi?id=54998
--
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.
5:46 a.m.
On Mon, 2012-09-17 at 10:04 +0200, Patrick Ohly wrote:
> 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.
Sorry, I haven't found the time and won't for a while. I've created a
feature request for this so that I won't forget and added some
implementation hints:
https://bugs.freedesktop.org/show_bug.cgi?id=54998
No worries - I've somehow stumbled onto a fix.
I've changed my workflow to workaround bugs in Google calendar. I now
exclusively use Google calendar for keeping my schedule, sync to Evo,
and then one-way push to the phone.
At some point, syncs with the phone began working (I did
refresh-from-local, and I'd guess that was key) - the previously
problematic photos are even being pushed and used by the phone.
Wish I could explain it - probably points to a bug somewhere. Though,
it'd likely be another Google calendar or S40 bug. Since neither dev
team is 1/10th as responsive as you, and neither's SyncML is support is
1/10th as good as syncevo, I'm happy to have a reasonably convenient
hack.
Ross
3362
days inactive
3397
days old
syncevolution@synevolution.org
6 comments
2 participants
participants (2)
-
Patrick Ohly -
Ross Vandegrift