2:21 a.m.
Hi all, I'm trying to use syncevolution 1.0beta2 to sync my N900 with
evolution over bluetooth. I've followed the instruction at
http://syncevolution.org/development/sync-phone, but I now only get a
failure saying:
ObexTransprotAgent: Underlying transport error
On the other hand, I knokw Obex is working because I use it to browse
(still via bluetooth) my N900 files from GNOME/Nautilus.
If it is well known and expected for a dev release, don't worry, that's
life. If otherwise it is unexpected I'd be happy to help out with
testing, I attach the failure log.
Many thanks for syncevolution!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
12:12 p.m.
Stefano Zacchiroli wrote:
Hi all, I'm trying to use syncevolution 1.0beta2 to sync my N900
with
evolution over bluetooth. I've followed the instruction at
http://syncevolution.org/development/sync-phone, but I now only get a
failure saying:
ObexTransprotAgent: Underlying transport error
There was some discussion about N900 and it worked in my last try. [1]
One important item you might missing is you need to set the "URI" field for your
addressbook as "Contacts" and calendar as "Calendar".
The following command is an example:
syncevolution --configure \
--source-property type=addressbook:text/x-vcard \
--source-property uri=Contacts
MyPhone contacts
Please let me know if that works. I updated the sync-phone guide to remind this and in
a later update we might add a N900 template.
[1] http://lists.syncevolution.org/pipermail/syncevolution/2009-December/0008...
Best Regards,
Congwu
8:48 p.m.
On Tue, Mar 09, 2010 at 09:12:39AM +0800, Chen, Congwu wrote:
Please let me know if that works. I updated the sync-phone guide to
remind this and in a later update we might add a N900 template.
Thanks for your feedback!
I'm now attaching a script which takes care of setting up my initial
syncevolution configuration. After having run it, I can synchronize
using "syncevolution n900". It works for the calendar, but it does not
work for the contacts, I guess there is still some naming issue to be
fleshed out somewhere, any idea?
I'm not sure if the "super" stuff mentioned at
http://syncevolution.org/development/sync-phone applies to the N900;
I've tried to played a bit with it, but without any noticeable
difference.
Unfortunately, with the calendar sync, I get quite a lot of duplicates
events in evolution, is that expected?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
12:36 a.m.
I am pretty disappointed after the last update to v.1.0beta on my N900. :-(
The update definately broke the apps functionality on my device.
Now the system which synchronized without a problem with my
my.funambol.com account freezes when I push the "Synchrinize!" button
the the GUI menu of the N900 Syncevolution widget. No synchronizing, no
log entries to post here, no error message. It freezes independent if I
use 3G or Wifi connection. I have to shut down the program manually in
this freeze state after waiting p to 20 minutes for a proper reaction. I
deleted the service and reentered it, but it's the same defective situation.
Please advice how to downgrade the application again to the working last
version.
Regards, Kyros
12:49 a.m.
I can confirm this behaviour on my N900, syncing with goosync. (Which
always misses the alarms, but that's a different story).
Currently on the road, so I can't do a proper investigation and bug report
TimT.
On Wed, Mar 10, 2010 at 14:36, Kyros Hariri <kyros(a)hariri.at> wrote:
I am pretty disappointed after the last update to v.1.0beta on my
N900. :-(
The update definately broke the apps functionality on my device.
Now the system which synchronized without a problem with my
my.funambol.com account freezes when I push the "Synchrinize!" button
the the GUI menu of the N900 Syncevolution widget. No synchronizing, no
log entries to post here, no error message. It freezes independent if I
use 3G or Wifi connection. I have to shut down the program manually in
this freeze state after waiting p to 20 minutes for a proper reaction. I
deleted the service and reentered it, but it's the same defective situation.
Please advice how to downgrade the application again to the working last
version.
Regards, Kyros
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
2:11 a.m.
On Mi, 2010-03-10 at 13:49 +0000, Tim T. wrote:
I can confirm this behaviour on my N900, syncing with goosync.
(Which
always misses the alarms, but that's a different story).
Currently on the road, so I can't do a proper investigation and bug report
Someone has already filed a bug:
http://bugzilla.moblin.org/show_bug.cgi?id=10122
--
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.
4:36 a.m.
On Wed Mar 10 2010 16:11:51 GMT+0100 (CET) Patrick Ohly wrote:
http://bugzilla.moblin.org/show_bug.cgi?id=10122
Someone has already filed a bug:
So meanwhile until it's fixed please advice as
a workaround how to
downgrade to the old working version again.
Thanx and Regards, Kyros
6:46 a.m.
Kyros Hariri skrev:
On Wed Mar 10 2010 16:11:51 GMT+0100 (CET) Patrick Ohly wrote:
> http://bugzilla.moblin.org/show_bug.cgi?id=10122
> Someone has already filed a bug:
So meanwhile until it's fixed please advice as a workaround how to
downgrade to the old working version again.
As root, you could apt-get install syncevolution-frontend=0.3 (after
making sure Extras-testing is enabled, since that's presumably where apt
would have to get 0.3 from right now)
And while testing is always good, for your own sake, consider heeding
the big warning at the top of http://wiki.maemo.org/Extras-devel, and
disable Extras-devel if you aren't sure how to recover from using
unstable and insufficiently tested software from there. The failing
version (0.4) was never moved into extras-testing, in part because it
wasn't known to actually work yet.
That said, I think syncevolution-frontend 0.5 fixes the problem, if you
prefer to continue to use extras-devel.
11:01 a.m.
On Wed Mar 10 2010 20:46:26 GMT+0100 (CET) Ove Kaaven wrote:
Kyros Hariri skrev:
> So meanwhile until it's fixed please advice as a workaround how to
> downgrade to the old working version again.
>
As root, you could apt-get install syncevolution-frontend=0.3 (after
making sure Extras-testing is enabled, since that's presumably where apt
would have to get 0.3 from right now)
And while testing is always good, for your own sake, consider heeding
the big warning at the top of http://wiki.maemo.org/Extras-devel, and
disable Extras-devel if you aren't sure how to recover from using
unstable and insufficiently tested software from there. The failing
version (0.4) was never moved into extras-testing, in part because it
wasn't known to actually work yet.
That said, I think syncevolution-frontend 0.5 fixes the problem, if you
prefer to continue to use extras-devel
Thank you very much - after:
sudo gainroot
apt-get install syncevolution-frontend=0.5
everything is working as good as before again.
Regards, Kyros
3:40 p.m.
I'm now attaching a script which takes care of setting up my
initial
syncevolution configuration. After having run it, I can synchronize
using "syncevolution n900". It works for the calendar, but it does not
work for the contacts, I guess there is still some naming issue to be
fleshed out somewhere, any idea?
That's strange.
Could you try with syncevolution n900 addressbook, if that still fails, could
you send me the log file for me to investigate?
I'm not sure if the "super" stuff mentioned at
http://syncevolution.org/development/sync-phone applies to the N900;
I've tried to played a bit with it, but without any noticeable
difference.
I am not sure either.. Anyway if your calendar syncs well with no
warnings like
"rejected items", I think you don't need the 'super' (or combined
calendar and todo)
stuff.
Unfortunately, with the calendar sync, I get quite a lot of
duplicates
events in evolution, is that expected?
No, do you already have the same events on
your N900? A first time sync between
two parties has to be "slow sync" and if items was already in both party, it is
possible
you end up with a lot of duplicates.
Best Regards,
Congwu
8:41 p.m.
On Thu, Mar 11, 2010 at 12:40:15PM +0800, Chen, Congwu wrote:
Could you try with syncevolution n900 addressbook, if that still
fails, could you send me the log file for me to investigate?
So, to add some more context, here is a sample summary of a "regular"
execution of "syncevolution n900":
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| item(s) in database backup: 1490 before sync, 1490 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu Mar 11 10:33:52 2010, duration 1:34min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
If I try, as you suggested, "syncevolution n900 addressbook" I re-got a
"Underlying transport error":
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu Mar 11 10:37:42 2010, duration 0:00min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: ObexTransprotAgent: Underlying transport error
I get the same replacing on the command line "Contacts" for
"addressbook". I'll follow-up in private mail the error log.
I am not sure either.. Anyway if your calendar syncs well with no
warnings like "rejected items", I think you don't need the 'super'
(or
combined calendar and todo) stuff.
OK, thanks, I indeed get no "rejected items".
No, do you already have the same events on your N900? A first time
sync between two parties has to be "slow sync" and if items was
already in both party, it is possible you end up with a lot of
duplicates.
I had indeed some events on the N900 calendar---arrived there via the
migration from my old phone to this one---but the one that actually got
duplicated were not on the N900 calendar. I've obtained duplicates of
new events that were only on evolution, with no evident pattern to me.
How can I do a new "slow sync" to re-bootstrap the process? Ideally I
can just delete all events on the N900 and re-sync, but I obviously fear
that the sync will consequently delete all events from my evolution,
which wouldn't be nice :-) Ideally I want to re-start from scratch with
an evolution -> N900 sync, but I don't know how to (safely) achieve
that.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
12:55 p.m.
How can I do a new "slow sync" to re-bootstrap the process?
Ideally I
can just delete all events on the N900 and re-sync, but I obviously fear
that the sync will consequently delete all events from my evolution,
which wouldn't be nice :-) Ideally I want to re-start from scratch with
an evolution -> N900 sync, but I don't know how to (safely) achieve
that.
You can delete all events on the N900 and start a slow sync from SyncEvolution,
Syncevolution --sync=slow n900
From SyncML view, the most appropriate mode you want to use might be
refresh-from-server (meaning overwrite the client data by server's database),
but
I am not sure whether N900 implements this correctly.
Finally, SyncEvolution is careful about your data, it automatically backups your data
before syncing and you can always restore your previous data if something goes wrong,
see syncevolution --restore
Best Regards,
Congwu
8:52 p.m.
On Fri, 2010-03-12 at 09:55 +0800, Chen, Congwu wrote:
>How can I do a new "slow sync" to re-bootstrap the
process? Ideally I
>can just delete all events on the N900 and re-sync, but I obviously fear
>that the sync will consequently delete all events from my evolution,
>which wouldn't be nice :-) Ideally I want to re-start from scratch with
>an evolution -> N900 sync, but I don't know how to (safely) achieve
>that.
>
You can delete all events on the N900 and start a slow sync from SyncEvolution,
Syncevolution --sync=slow n900
ERROR: --sync=slow unknown parameter
Xav
1:25 a.m.
On Fr, 2010-03-12 at 09:52 +0000, Xavier Bestel wrote:
On Fri, 2010-03-12 at 09:55 +0800, Chen, Congwu wrote:
> >How can I do a new "slow sync" to re-bootstrap the process? Ideally I
> >can just delete all events on the N900 and re-sync, but I obviously fear
> >that the sync will consequently delete all events from my evolution,
> >which wouldn't be nice :-) Ideally I want to re-start from scratch with
> >an evolution -> N900 sync, but I don't know how to (safely) achieve
> >that.
> >
> You can delete all events on the N900 and start a slow sync from SyncEvolution,
> Syncevolution --sync=slow n900
ERROR: --sync=slow unknown parameter
It's either "--sync slow" or "--source-property sync=slow". The
former
is the old form that was used before introducing properties; it's kept
as a short-hand and for backwards compatibility.
--
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.
3:30 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
On Tue, Mar 09, 2010 at 10:48:09AM +0100, Stefano Zacchiroli wrote:
Unfortunately, with the calendar sync, I get quite a lot of
duplicates
events in evolution, is that expected?
So, I can easily reproduce the duplicate problem now, here are my steps:
- empty the calendar on the N900
- due a slow sync
effect: everything is copied to the N900, fine
- due a standard sync (note: without changing any event on either side)
effect: about 100 events out of 1500 total events get duplicated on
the evolution side on my Linux box.
There doesn't seem to be a pattern, sometime they are duplicated in
the very same calendar, other times to different calendars.
Hope this helps,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
4:32 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
[Replying instead of Congwu because it is outside of his working hours.]
On Fr, 2010-03-12 at 16:30 +0000, Stefano Zacchiroli wrote:
So, I can easily reproduce the duplicate problem now, here are my
steps:
- empty the calendar on the N900
- due a slow sync
effect: everything is copied to the N900, fine
- due a standard sync (note: without changing any event on either side)
effect: about 100 events out of 1500 total events get duplicated on
the evolution side on my Linux box.
That looks like the device is sending the Linux side items as "new" and
requests them to be added. Look at the command-line ouput for
"--print-sessions n900" (assuming that n900 is your config name), locate
the session for the standard sync. The statistics shown for
--print-session are always zero, a known limitation of the SyncML engine
when running as server. Therefore it is necessecary to check the logs.
So open the syncevolution-log.html inside that directory. Search for
"Add" or something like it. If unsure, send the log to
syncevolution(a)lists.intel.com.
This is only to verify what the root cause is. If the device sends us
incorrect items, we cannot work around that. It would have to be fixed
on the device.
There doesn't seem to be a pattern, sometime they are
duplicated in
the very same calendar, other times to different calendars
This confuses me a bit. When you say different calendars, do you mean
different calendars in Evolution? How many do you have and how did you
configure the Evolution side? It should always only read/write from one
calendar in normal operation.
--
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.
1:10 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
On Fri, Mar 12, 2010 at 09:32:21AM -0800, Patrick Ohly wrote:
Therefore it is necessecary to check the logs.
So open the syncevolution-log.html inside that directory. Search for
"Add" or something like it. If unsure, send the log to
syncevolution(a)lists.intel.com.
Will do.
> There doesn't seem to be a pattern, sometime they are
duplicated in
> the very same calendar, other times to different calendars
This confuses me a bit. When you say different calendars, do you mean
different calendars in Evolution? How many do you have and how did you
configure the Evolution side? It should always only read/write from one
calendar in normal operation.
I do mean different calendars in Evolution, I've various of them, both
google/webcals (which AFAIU are neither supported nor considered by both
syncevolution and the N900 calendar app), and local ones. For the local
one I've just done "create new calendar" in evolution, I don't know
whether Evolution uses a single .ics file with some sort of "category"
or if it actually uses several .ics files.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
3:03 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
On Di, 2010-03-16 at 14:10 +0000, Stefano Zacchiroli wrote:
On Fri, Mar 12, 2010 at 09:32:21AM -0800, Patrick Ohly wrote:
> Therefore it is necessecary to check the logs.
>
> So open the syncevolution-log.html inside that directory. Search for
> "Add" or something like it. If unsure, send the log to
> syncevolution(a)lists.intel.com.
Will do.
Thanks.
Regarding your tweet:
I blush: the #intel #syncevolution devs seem lost w/o my #n900
logs,can't they just knock the #nokia door and get a n900?
#meego, anyone?
Congwu has access to a N900, but as he wasn't able to reproduce the
problem, we need your logs. It might also be specific to your data. And
no, Nokia is not sending around hardware just because some developer
asks for it.
> > There doesn't seem to be a pattern, sometime they are
duplicated in
> > the very same calendar, other times to different calendars
>
> This confuses me a bit. When you say different calendars, do you mean
> different calendars in Evolution? How many do you have and how did you
> configure the Evolution side? It should always only read/write from one
> calendar in normal operation.
I do mean different calendars in Evolution, I've various of them, both
google/webcals (which AFAIU are neither supported nor considered by both
syncevolution and the N900 calendar app), and local ones. For the local
one I've just done "create new calendar" in evolution, I don't know
whether Evolution uses a single .ics file with some sort of "category"
or if it actually uses several .ics files.
It uses a single .ics file per calendar. In your mail with the log you
mentioned that events were only duplicated inside that calendar, so I'll
ignore that part of the problem unless it happens again.
The log confirms that the SyncML client in the N900 is confused, as I
suspected. It explicitly adds all of these duplicates to the host in a
normal two-way sync. Probably the change tracking on the device is
broken, perhaps because of the amount of calendar items that you have.
Congwu, can you reproduce the problem when running client-test's
testManyItems when increasing the item count via CLIENT_TEST_NUM_ITEMS?
Stefano, I might be able to discuss this with the implementors of the
SyncML client in the N900 soon. But as you bought the device and
presumably Nokia offers support for it, perhaps you can also file a bug
report somewhere?
--
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.
3:34 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
On Tue, Mar 16, 2010 at 05:03:40PM +0100, Patrick Ohly wrote:
Congwu has access to a N900, but as he wasn't able to reproduce
the
problem, we need your logs. It might also be specific to your
data. And no, Nokia is not sending around hardware just because some
developer asks for it.
Well, I got one N900 as a distro dev, that made me believe Nokia was
interested in handing out phones to people doing development on the
device. FWIW, in the thread(s) I got the impression that none of the
devs actually had a N900 and/or tried to reproduce the issue. Given that
it is not the case (i.e. the problem is not trivially reproducible) I'm
more than happy to help out.
On the same vein, I don't have any particularly sensitive date in my
calendar. If you can guarantee that it won't go public for download, I
can and hover the data to syncevolution devs too. Would having the data
enable some more in-depth debugging?
It uses a single .ics file per calendar. In your mail with the log
you
mentioned that events were only duplicated inside that calendar, so I'll
ignore that part of the problem unless it happens again.
In fact, I reported that some events got duplicated in the same calendar
(i.e. two entries corresponding to the same event in the same calendar)
and some others in different calendars (i.e. two entries corresponding
to the same event in two different calendars).
The log confirms that the SyncML client in the N900 is confused, as
I
suspected. It explicitly adds all of these duplicates to the host in a
normal two-way sync. Probably the change tracking on the device is
broken, perhaps because of the amount of calendar items that you have.
OK, thanks for this investigation. What is the "normal" amount of events
and/or time period which encompasses all the events? I don't delete past
event just out of laziness, I don't particularly mind deleting old
entries. Before doing so however, it might be useful to have some
figures to check at which point the problem starts to appear.
Stefano, I might be able to discuss this with the implementors of
the
SyncML client in the N900 soon. But as you bought the device and
presumably Nokia offers support for it, perhaps you can also file a bug
report somewhere?
I didn't get any support as I got the N900 as a gift from Nokia (for
Debian packaging however, not for low-level hacking on the closed Nokia
stuff). I can of course submit a bug report as a regular Maemo user, but
before this mail I confess I didn't have enough information/knowledge to
do so.
Thanks for your feedback!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
4:17 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
On Di, 2010-03-16 at 16:34 +0000, Stefano Zacchiroli wrote:
On Tue, Mar 16, 2010 at 05:03:40PM +0100, Patrick Ohly wrote:
> Congwu has access to a N900, but as he wasn't able to reproduce the
> problem, we need your logs. It might also be specific to your
> data. And no, Nokia is not sending around hardware just because some
> developer asks for it.
Well, I got one N900 as a distro dev, that made me believe Nokia was
interested in handing out phones to people doing development on the
device.
I got a 770 and N810 the same way, but that was when I worked on this in
my spare time. I didn't ask to get included in the N900 program and so
far Nokia has not offered free devices again, at least as far as I know.
FWIW, in the thread(s) I got the impression that none of the
devs actually had a N900 and/or tried to reproduce the issue.
You are right, that Congwu has one was probably only mentioned in one of
the earlier threads about the N900.
On the same vein, I don't have any particularly sensitive date in
my
calendar. If you can guarantee that it won't go public for download, I
can and hover the data to syncevolution devs too. Would having the data
enable some more in-depth debugging?
Not at our end. If it turns out to be related to the specific *and* we
can get a Nokia developer to investigate this, then we might come back
to your offer.
> It uses a single .ics file per calendar. In your mail with the
log you
> mentioned that events were only duplicated inside that calendar, so I'll
> ignore that part of the problem unless it happens again.
In fact, I reported that some events got duplicated in the same calendar
(i.e. two entries corresponding to the same event in the same calendar)
That I understand. We send events from calendar A to the device, get
some of the same events back when syncing A again, so we duplicate them
in A.
and some others in different calendars (i.e. two entries
corresponding
to the same event in two different calendars).
That's what I don't understand. When configured to use calendar A,
SyncEvolution should never touch a different calendar B.
> The log confirms that the SyncML client in the N900 is confused,
as I
> suspected. It explicitly adds all of these duplicates to the host in a
> normal two-way sync. Probably the change tracking on the device is
> broken, perhaps because of the amount of calendar items that you have.
OK, thanks for this investigation. What is the "normal" amount of events
and/or time period which encompasses all the events? I don't delete past
event just out of laziness, I don't particularly mind deleting old
entries. Before doing so however, it might be useful to have some
figures to check at which point the problem starts to appear.
Congwu might be able to test this with our test tool so that you don't
have to test this manually. A few thousand events is a bit at the high
end, but I would expect it to work.
--
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.
4:31 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicates
Patrick Ohly skrev:
> and some others in different calendars (i.e. two entries
corresponding
> to the same event in two different calendars).
That's what I don't understand. When configured to use calendar A,
SyncEvolution should never touch a different calendar B.
The N900 stores information from all calendars in the same SQLite
database, with one field telling which calendar any entry belongs to. If
the N900's SyncML client manages to handle this field wrong somehow,
perhaps that explains why the N900 would send some entries from the
wrong calendar.
5:18 p.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
So I got the N900 at hand again and did some testing.
The first problem is about the configuration, Ove only works with Calendar
but my test works for addressbook, calendar+todo and notes, see the
attached script. Ove, please try with this configuration and tell me whether
it works for you.
Another problem is the duplicated items, yes my test confirmed Ove's finding.
N900 keeps sending all items again and again. A closer look at the N900 side
lightened me, each session we issued was thought as a completely new device/
configuration by N900, so it switched to slow-sync (but silently without notifying us!).
I resolved this after: 1) setting 'remote Identifier' to PC Suite 2)do not send
respuri to
the phone. The former is done in the configuration, the latter however need a hack in the
configuration file 'syncevolution.xml', please apply the attached patch over this
file (I believe
it it located at $prefix/share/syncevolution/xml/syncevolution.xml). With these changes,
sync
from SyncEvolution is completely pretended like PC Suite from N900's view.
Ove, thanks for your report, please try if this solves your problem.
Open question: I found N900 suddenly stopped sending device info to us at some point (I
believe
it sent it last time I tested and I can confirm the same behavior from Ove's logs),
however I have
no idea what exactly caused this. Any hint? Set SyncMLVersion to '1.1' however
workarounds this.
Best Regards,
Congwu
_____________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
6:19 p.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
On Wed, 2010-03-17 at 06:18 +0000, Chen, Congwu wrote:
I resolved this after: 1) setting 'remote Identifier' to PC
Suite 2)do not send respuri to
the phone.
"RespURI" is not needed when talking over Bluetooth. Can you add code
which detects the transport and disables RespURI for Bluetooth? Also,
please file a bug about this. We should fix these issues and add a
proper template for the N900. This would be worthwhile to have in the
next update (this week?). Even if we haven't done enough testing to
declare it supported (whatever that means for devices), having an almost
right configuration is better than none.
Open question: I found N900 suddenly stopped sending device info to
us at some point (I believe
it sent it last time I tested and I can confirm the same behavior from Ove's logs),
however I have
no idea what exactly caused this. Any hint? Set SyncMLVersion to '1.1' however
workarounds this.
No idea about this one.
--
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.
2:56 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
Chen, Congwu skrev:
Ove, thanks for your report, please try if this solves your problem.
What? I never reported such a problem. so far I haven't even used
syncevolution 1.0 yet, let alone its phone sync feature. I was just
trying to provide some relevant information, in case it helped someone
fix the OP's problem...
4:24 a.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
On Wed, Mar 17, 2010 at 04:56:22PM +0100, ovek(a)arcticnet.no wrote:
Chen, Congwu skrev:
> Ove, thanks for your report, please try if this solves your problem.
What? I never reported such a problem. so far I haven't even used
syncevolution 1.0 yet, let alone its phone sync feature. I was just
trying to provide some relevant information, in case it helped someone
fix the OP's problem...
Yep, indeed, I believe the bug reporter in question was me, rather then
Ove. I haven't yet had the time to test drive the proposed fix, I'll get
back as soon as I do.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
11:18 p.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
On Wed, 2010-03-17 at 17:24 +0000, Stefano Zacchiroli wrote:
Yep, indeed, I believe the bug reporter in question was me, rather
then
Ove. I haven't yet had the time to test drive the proposed fix, I'll get
back as soon as I do.
The snapshot 0.9.2+1.0beta2a+20100319+SE+15d4589+SYSYNC+0e94c06 in
http://downloads.syncevolution.org/tmp/ contains the fix and a N900
template.
--
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.
11:34 p.m.
New subject: [SyncEvolution] syncevolution 1.0beta2, n900, and duplicate-- Partially resolved
On Fri, Mar 19, 2010 at 01:18:20PM +0100, Patrick Ohly wrote:
The snapshot 0.9.2+1.0beta2a+20100319+SE+15d4589+SYSYNC+0e94c06 in
http://downloads.syncevolution.org/tmp/ contains the fix and a N900
template.
WOA \o/, amazing news.
Thanks a lot (still pending feedback, sorry about that).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack(a){upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
4566
days inactive
4577
days old
syncevolution@synevolution.org
26 comments
8 participants
participants (8)
-
Chen, Congwu -
Kyros Hariri -
Ove Kaaven -
ovek＠arcticnet.no
-
Patrick Ohly -
Stefano Zacchiroli -
Tim T. -
Xavier Bestel