On Mo, 2011-04-18 at 11:35 +0100, Hevï Guy wrote:
Ah ha! The large contact photo size was indeed the culprit!
Yes other contacts with photos had been successfully synced. I've not
looked at the size of those files but now that I edited the missing
contacts to show no image, I assume that the former contact files had
images of an acceptable size.
Do you have an opinion on how SynEvolution should handle existing
contacts with large photos? See below.
On Mon, 2011-04-18 at 10:14 +0200, Patrick Ohly wrote:
> * On Fr, 2011-04-15 at 06:59 +0100, Hevï Guy wrote:
> > Once I finally set-up Syncevolution 1.1.1-2 so that I could at least
> > do a one-way refresh of "Contacts" to my Nokia N86 8MP, I found
> > certain contacts would not sync; The resulting comment in the GUI was:
> > "There were 22 remote rejections". Has anybody else experienced
> > More importantly, has anybody found a solution?
> Hevï sent me his log files. There were two problems:
> 1. Some contacts had photos that were so large that the contact
> exceeded the maximum contact size supported by the phone (for
> example, 206653 bytes where only 102400 = 100KB allowed).
> 2. Other contacts with photo are sent, but the phone reports an
> error (415 status).
> Hevï, were other contacts with photos transferred? The log only contains
> the problematic contacts, so I cannot tell.
> Do you see a relevant difference between a contact that was transferred
> with photo and one which wasn't? Photo size or encoding (PNG vs. JPG,
> for example)? If unsure, please send me the saved vCard of a contact
> which was transferred okay.
> The underlying question is this:
> * Should PHOTO data be transcoded as part of syncing? This is
> necessary at least for case 1 above and might also help with
> case 2.
> It could be added, but that leads to further questions:
> * How does SyncEvolution decide which kind of PHOTO data will be
> accepted by the peer? Resolution, format, ...
> * If a photo was transcoded, how will SyncEvolution deal with an
> updated photo sent by the peer?
> A. Overwrite photo locally: allows updating photos on the
> peer, but implies that a potentially higher resolution
> version of the same photo gets overwritten when only
> some other properties were modified.
> B. Always preserve local photo data: adding a photo on the
> peer would be possible, but not updating it.
> Possible answers:
> * Only transcode if it is detected during a sync that photos had
> * Hard-code certain profiles, match them to DevInf reported by
> device (based on max item size, for example).
> * Preserve local photo data if transcoding was necessary.