Re: [SyncEvolution] Why is there nothing in the cache for my calendar - E71 1.0beta3?
On Tue, 2010-05-11 at 22:05 +0100, Chris G wrote:
While I'm about it running syncevo-phone-config.py was rather
painful
because I had to accept hundreds of bluetooth connections to my phone
while syncevo-phone-config.py was running.
I know exactly what you mean. My Sony Ericsson K750i had a joystick that
was so worn out that I could no longer navigate to the "always accept"
option. Eventually I managed to reach that point by brute force.
Regarding running syncevo-phone-config.py: this is definitely not the
recommended way to create a config. I bet it arrived at the same
configuration that we already ship as template for S40 and S60 Nokia
phones, so you could have chosen one of those instead.
The new configuration seems *exactly* the same as all the previous
ones I have tried which were created by sync-ui. Addressbook, memos,
and todos are synchronised, calendar entries only go from E71 to
Evolution.
This is a bit surprising, because if the test tool found a config for
calendar, it must have been able to copy a simple event back and forth.
Perhaps it now only fails for the more complex events that you have in
real life?
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
[...]
So why is there *nothing* in the calendar? There's certainly
data in
both my Evolution calendar and in the E71 calendar.
First, the statistics in server mode are currently incomplete. That was
a known limitation of the Synthesis engine which has been solved in the
meantime for 1.0.
But I am indeed a bit puzzled that there is no second line with
information about calendar items in the local cache.
Please show the output of:
- syncevolution --print-config -q <name of config>
- syncevolution --run <name of 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.