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 that certain contacts would not sync; The resulting comment in the GUI was: "There were 22 remote rejections". Has anybody else experienced this? More importantly, has anybody found a solution?

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.

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 that > > certain contacts would not sync; The resulting comment in the GUI was: > > "There were 22 remote rejections". Has anybody else experienced this? > > 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 > problems. > * 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. > >

Possible answers: * Only transcode if it is detected during a sync that photos had problems. * 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.