Bug 52704 - transcode PHOTO data (contact rejections by phones, photo not shown by Google)
Summary: transcode PHOTO data (contact rejections by phones, photo not shown by Google)
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: SyncEvolution Community
QA Contact:
Depends on:
Reported: 2011-05-10 14:06 UTC by Patrick Ohly
Modified: 2018-10-13 12:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Patrick Ohly 2012-07-29 18:36:00 UTC

---- Reported by patrick.ohly@intel.com 2011-05-10 14:06:55 +0000 ----

From: 	Patrick Ohly <patrick.ohly@intel.com>
Cc: 	syncevolution@syncevolution.org <syncevolution@syncevolution.org>
Subject: 	Re: [SyncEvolution] Contacts rejected by peer - PHOTO size and encoding
Date: 	Mon, 18 Apr 2011 09:14:49 +0100 (18.04.2011 10:14:49)

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
      * 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.

---- Additional Comments From patrick.ohly@intel.com 2011-08-08 08:03:46 +0000 ----

From https://bugs.meego.com/show_bug.cgi?id=19661:
Google Contacts does not show the photo if it is too large (976K in that test). Probably need to scale down.

--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 17345 at https://bugs.meego.com/show_bug.cgi?id=17345
Comment 1 GitLab Migration User 2018-10-13 12:42:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/84.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.