On Mon, 2010-06-07 at 11:51 +0100, Anssi Saari wrote:
Patrick Ohly <patrick.ohly(a)intel.com> writes:
> Anssi, can start from scratch by wiping out .server.ini, then doing a
> "refresh-from-server" with the phone? Then keep all logs (maxlogdirs=0)
> at loglevel=3 for the phone, because it is a bit uncertain when the root
> cause of the problem strikes.
I seem to have forgotten to wipe my old .server.ini, just did the
refresh-from-server with the phone. The results was that some contacts
and memos got re-added a few times.
That's really weird. It sounds almost like the "refresh-from-server" was
turned into a "slow" sync.
I wish I had a Nokia phone to test with. "refresh-from-server" works for
me here with a Sony Ericsson =>
So I removed my calendar .server.ini and did the refresh-from-server
again. And then, since I had those duplicate contacts I spent some
time deleting them on the laptop and syncing to the phone.
Unfortunately the slow syncing happened, as before. It also means I
got my duplicated contacts back so I'm up to almost 1000 contacts now
instead of the normal 250 or so. Oh well.
Remember, you can use the "--restore" functionality to fall back to a
know good status on the laptop, like for example before this ill-fated
"refresh-from-server" sync with the phone. Then doing a normal two-way
sync should also delete the duplicates from the phone.
But here are the logs from today packed up. I hope they shed some
light on the problem.
I've checked the initial five and all were either normal two-way syncs
or resumed two-way syncs. It really looks like "refresh-from-server"
doesn't work. Bummer. Anyway, after removing the .server.ini and a slow
sync, everything should be sane now (okay, ignoring the duplicates). If
you notice unexpected slow syncs again, please let me know. Please
include information about the problems observed (or not observed) for
each sync session, otherwise the logs are bit overwhelming.
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.