Re: [SyncEvolution] N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: syncevo-dbus-server dies - SIGPIPE)
11:28 p.m.
-----Ursprüngliche Nachricht-----
Von: "Patrick Ohly" <patrick.ohly(a)intel.com>
Gesendet: 02.11.2011 17:45:28
An: "Frederik Elwert" <frederik.elwert(a)web.de>
Betreff: Re: N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: [SyncEvolution]
syncevo-dbus-server dies - SIGPIPE)
On Wed, 2011-11-02 at 15:00 +0100, Frederik Elwert wrote:
> >On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
> >> There is just one issue that I could not yet identify: There is always
> >> a number of calendar entries in ERR state, which get re-submitted with
> >> the next sync, and then again be rejected. On the N9, at a first
> >> glance no recent entries seem to be missing, so I did not do too much
> >> to triage this issue. On the other hand, this probably makes each sync
> >> use more time than necessary. Any ideas where these errors might sttem
> >> from? I’ll send you a loglevel=4 log in private, maybe you can make
> >> more sense of it than I can.
> >
> >The failures are all for item delete requests. The N9 returns a very
> >uninformative 500, which is usually about an internal error. Because the
> >Synthesis engine doesn't know what to do about that, it keeps trying.
> >
> >Can you do a refresh sync? I assume your desktop has all your events, so
> >do a '--sync refresh-from-server' on the desktop (which is the server in
> >this case).
>
> I did a refresh-from-server for the calendar, and then a normal sync
> (no sync mode given). During that normal sync, syncevolution also did
> a slow sync for the calendar (while doing a two-way sync for the
> address book), which lead to various conflicts.
The slow sync was caused by doing the refresh-from-server with the
"calendar" source, while during a normal sync "calendar+todo" is
used.
The Synthesis engine cannot reuse the anchors from one real source
("calendar") in a sync with a virtual source ("calendar+todo").
Can you try again with "refresh-from-server" for "calendar+todo"?
I tried again with calendar+todo.
A subsequent normal sync again did a slow sync. I restored, and in a second attempt, I
tried an explicit --sync two-way calendar+todo. That worked for the calendar (two-way, no
conflicts/ERRs), but not for the todo (slow sync, all 15 items in conflict). After that, a
normal sync (no explict sources given, i.e. all configured sources synced) worked fine.
Since I am no longer really using todo sync (those 15 are old left-over entries), this is
okay for me. The important thing was the calendar sync.
I sent you the logs in private, so you could see in detail what I did.
I wonder why that worked. Has the "calendar" source any URI
configured?
It could be that it used the "calendar" source name as fallback. That
wasn't the intention when adding that fallback; the goal was to simplify
SyncEvolution<->SyncEvolution syncs.
No, the calendar source is disabled, and has no uri. Only calendar+todo and addressbook is
configured.
Regards
Frederik
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
12:57 a.m.
New subject: [SyncEvolution] N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: syncevo-dbus-server dies - SIGPIPE)
On Thu, 2011-11-03 at 13:28 +0100, Frederik Elwert wrote:
>On Wed, 2011-11-02 at 15:00 +0100, Frederik Elwert wrote:
>> >On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
>Can you try again with "refresh-from-server" for
"calendar+todo"?
I tried again with calendar+todo.
A subsequent normal sync again did a slow sync.
That shouldn't have happened. The refresh-from-server sync completed
without errors, at least as far as the server can tell. But then in the
next sync, the N9 sends the old, obsolete anchor as if the
refresh-from-server sync had failed.
I tried with a Noki N97, which worked fine.
As far as I can tell, the N9 Bluetooth SyncML is not working properly
when it comes to calendar data. Another reason not to use it is the
limitation to vCalendar 1.0. That will be problematic in combination
with different time zones and detached recurrences.
A better solution is probably to set up SyncEvolution as HTTP SyncML
server and use SyncEvolution also on the N9.
I restored, and in a second attempt, I tried an explicit --sync
two-way calendar+todo. That worked for the calendar (two-way, no
conflicts/ERRs), but not for the todo (slow sync, all 15 items in
conflict). After that, a normal sync (no explict sources given, i.e.
all configured sources synced) worked fine.
There are still "NON-OK STATUS 500" errors in that last log file.
>I wonder why that worked. Has the "calendar" source any
URI configured?
>It could be that it used the "calendar" source name as fallback. That
>wasn't the intention when adding that fallback; the goal was to simplify
>SyncEvolution<->SyncEvolution syncs.
No, the calendar source is disabled, and has no uri. Only calendar
+todo and addressbook is configured.
As I thought, "calendar" is used as fallback for the "calendar"
source
and that happens to be accepted by the N9.
One way to avoid this pitfall is to set an invalid URI for the calendar
and todo sources. The resulting error is not particularly obvious, but
it is better than doing a real sync:
[INFO] Server sending SAN
[ERROR] OBEX Request 3 got a failed response Forbidden
[INFO] Server sending SAN
[ERROR] OBEX Request 2 got a failed response Forbidden
[ERROR] ObexTransprotAgent: Underlying transport error
...
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu Nov 3 14:51:39 2011, duration 0:06min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: OBEX Request 3 got a failed response Forbidden
I'll add that to the Nokia device templates.
--
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.
9:04 a.m.
New subject: [SyncEvolution] N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: syncevo-dbus-server dies - SIGPIPE)
Am Donnerstag, den 03.11.2011, 14:57 +0100 schrieb Patrick Ohly:
On Thu, 2011-11-03 at 13:28 +0100, Frederik Elwert wrote:
> >On Wed, 2011-11-02 at 15:00 +0100, Frederik Elwert wrote:
> >> >On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
> >Can you try again with "refresh-from-server" for
"calendar+todo"?
>
> I tried again with calendar+todo.
>
> A subsequent normal sync again did a slow sync.
That shouldn't have happened. The refresh-from-server sync completed
without errors, at least as far as the server can tell. But then in the
next sync, the N9 sends the old, obsolete anchor as if the
refresh-from-server sync had failed.
I tried with a Noki N97, which worked fine.
As far as I can tell, the N9 Bluetooth SyncML is not working properly
when it comes to calendar data. Another reason not to use it is the
limitation to vCalendar 1.0. That will be problematic in combination
with different time zones and detached recurrences.
A better solution is probably to set up SyncEvolution as HTTP SyncML
server and use SyncEvolution also on the N9.
Okay, sad enough. I was more than happy that direct sync seemed to work
without the need to install additional software. And AFAIK,
syncevolution on the N9 currently only provides a command line
interface. I understand that it still is the technically superior
solution, but I think I will stay with end user solution for now,
despite its limitations.
However, thank you very much for the help!
3972
days inactive
3972
days old
syncevolution@synevolution.org
2 comments
2 participants
participants (2)
-
Frederik Elwert -
Patrick Ohly