On Sa, 2010-11-13 at 23:14 +0000, sean hunt wrote:
I am having a hellish time sorting this out... not too technically
competent.. problem, I thought (maybe still think) originated from
attempt to sync two nokia phones, my new N95 and old 6234. Since then I
have deactivated the 6234 and cleaned out the contacts file in evolution
and also on Nokia N95 a number of times but it keeps happening.
I want to erase thge 6234 but don't see a way to do it easily. I
stopped giving it permission to synce via bluetooth but still get these
double entries.
To track down the source of the double entries, please enable extended
logging (loglevel=4) and temporarily (until we have the necessary
information) keep all logs (maxlogdirs=0).
We need to find out two things:
* if and why there is a slow sync (the usually reason for duplicates)
* why pairing of the existing data in that slow sync fails for some
contacts
I'm afraid I'll have to see the logs to help with this issue; I promise
to keep your private data confidential.
Strange message comes up in configuration of sync....
I get a strange message... "Current configuration is more complex than
what can be shown here. Changes to sync mode or synced data types will
overwrite that configuration!... What does this mean? It is all related
to the old nokia 6234 settings that I can't erase.
Typically it means that something was configured in the config files
which cannot be represented like that in the sync UI. For example,
different direction of sync for different sources is possible in
SyncEvolution via the command line, but cannot be selected in the UI.
What is your configuration? Please use "syncevolution --print-config -q
<config name>".
You can delete it with "syncevolution --remove <config name>". There
should be a corresponding button in the UI, but I keep forgetting which
one it is (there are two, one for removing, one for resetting a
config) ;-}
--
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.