9:15 a.m.
Hi,
sorry to bother again, but I observed an issue performing following use
case:
1. Sync at home with my user profile A (it says normal sync)
2. Sync in the office with my user profile B
2.1 do refresh-from-remote
2.2 do a sync after some time (it says slow sync)
My question is why it does slow sync in 2.2? What could be the reason?
Thanks
9:34 a.m.
On Thu, 2016-11-10 at 09:15 +0100, deloptes wrote:
Hi,
sorry to bother again, but I observed an issue performing following use
case:
1. Sync at home with my user profile A (it says normal sync)
2. Sync in the office with my user profile B
2.1 do refresh-from-remote
2.2 do a sync after some time (it says slow sync)
Sync with what? Mobile phone?
My question is why it does slow sync in 2.2? What could be the
reason?
This should only happen if something went wrong. The latest
syncevolution-log.html should tell whether it was the local (=
SyncEvolution) or the remote (= phone) side which decided to do a slow
sync.
Then one has to check whether the previous sync completed normally.
There was a bug that affected some phones such that the sync itself
completed, but the OBEX connection was closed prematurely, causing some
phones to believe that an error occurred. But that should be fixed in
master.
--
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.
10:27 p.m.
Patrick Ohly wrote:
Sync with what? Mobile phone?
Yes! I use Nokia N9.
> My question is why it does slow sync in 2.2? What could be the
reason?
This should only happen if something went wrong. The latest
syncevolution-log.html should tell whether it was the local (=
SyncEvolution) or the remote (= phone) side which decided to do a slow
sync.
I was using syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa
Then one has to check whether the previous sync completed normally.
The previous sync (refresh-from-remote) finished without error. I will
retest tomorrow and inspect the log more carefully but I did not see any
sign of problem
There was a bug that affected some phones such that the sync itself
completed, but the OBEX connection was closed prematurely, causing some
phones to believe that an error occurred. But that should be fixed in
master.
Perhaps I use loglevel=10 ?
regards
11:09 p.m.
deloptes wrote:
Patrick Ohly wrote:
> Sync with what? Mobile phone?
>
Yes! I use Nokia N9.
> There was a bug that affected some phones such that the sync
itself
> completed, but the OBEX connection was closed prematurely, causing some
> phones to believe that an error occurred. But that should be fixed in
> master.
Perhaps I use loglevel=10 ?
regards
FYI: I tried now without refresh-from-remote. I synced last time in the
office and now first time at home. It went into slow sync immediately with
following result. The next sync was normal.
[INFO] addressbook: slow sync done successfully
[INFO] calendar: slow sync done successfully
[INFO] memo: slow sync done successfully
[INFO] todo: slow sync done successfully
Synchronization successful.
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 | 7 |
| slow, 0 KB sent by client, 403 KB received |
| 5 client item(s) discarded |
| 2 server item(s) discarded |
| 0 item(s) duplicated |
| 211 item(s) matched |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 3 |
| slow, 2 KB sent by client, 39 KB received |
| 1 client item(s) discarded |
| 2 server item(s) discarded |
| 0 item(s) duplicated |
| 40 item(s) matched |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 18 KB received |
| 88 item(s) matched |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
| slow, 0 KB sent by client, 0 KB received |
| 0 client item(s) discarded |
| 1 server item(s) discarded |
| 0 item(s) duplicated |
| 20 item(s) matched |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu 10 Nov 2016 10:30:56 PM CET, duration 0:37min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
[ERROR] GLib: Source ID 4 was not found when attempting to remove it
8:37 a.m.
On Thu, 2016-11-10 at 23:09 +0100, deloptes wrote:
deloptes wrote:
> Patrick Ohly wrote:
>
>> Sync with what? Mobile phone?
>>
>
> Yes! I use Nokia N9.
>
>> There was a bug that affected some phones such that the sync itself
>> completed, but the OBEX connection was closed prematurely, causing some
>> phones to believe that an error occurred. But that should be fixed in
>> master.
>
> Perhaps I use loglevel=10 ?
>
> regards
FYI: I tried now without refresh-from-remote. I synced last time in the
office and now first time at home. It went into slow sync immediately with
following result. The next sync was normal.
So switching between home and office triggers a slow sync? I wonder
whether the phone sees different deviceIds for the SyncEvolution side in
that case.
There are two settings in SyncEvolution for this. From a config for the
Nokia N97:
# the identifier sent to the remote peer for a server initiated sync.
# if not set, deviceId will be used instead
remoteIdentifier = PC Suite
# The SyncML server gets this string and will use it to keep track of
# changes that still need to be synchronized with this particular
# client; it must be set to something unique (like the pseudo-random
# string created automatically for new configurations) among all clients
# accessing the same server.
# myFUNAMBOL also requires that the string starts with sc-pim-
# deviceId =
We do server initiated syncs with phones, so "PC Suite" is sent to the
phone in the initial message. If I remember correctly, that had to be
that fixed string, at least with some Nokia phones.
Note that there's no unique deviceId here, which means that different
computers will all look alike to the phone, which then notices a
mismatch of sync anchors when moving between computers and thus forces a
slow sync.
Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this:
if (m_serverMode) {
// TODO: set the device ID for an OBEX server
} else {
substTag(xml, "fakedeviceid", getDevID());
}
I don't remember why that if() check is there, and why
SyncConfig::createPeerTemplate()'s
config->setDevID(string("syncevolution-") + UUID()) is not used to set a
unique deviceId when configuring phones.
Answering that would require some further code archeology and
experimenting; not sure when I will have time for that. Perhaps you can
check?
Here's an example of a sync with a SyncML server:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
<Source><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution(a)lists.intel.com</LocName></Source>
The server then replies with:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
<Target><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution(a)lists.intel.com</LocName></Target>
<Source><LocURI>http://www.plan44.ch/fsync_nightly</LocURI></Source>
Perhaps that's the reason for the if() check: a HTTP server might
require a different LocURI (?) than an OBEX server, and the code does
not immediately know what it is (depends on the transport).
--
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.
8:11 p.m.
Patrick Ohly wrote:
<Source><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution(a)lists.intel.com</LocName></Source >
> The server then replies with:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
<Target><LocURI>syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65</LocURI><LocName>syncevolution(a)lists.intel.com</LocName></Target >
<Source><LocURI>http://www.plan44.ch/fsync_nightly</LocURI></Source >
> Perhaps that's the reason for the if() check: a HTTP server might
> require a different LocURI (?) than an OBEX server, and the code does
> not immediately know what it is (depends on the transport).
I don't see it in the sync via bluetooth. I see in the html log
device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6
device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9
In the xml I see only the Nokia/Phone ID
<Source
<LocURI>IMEI:xxxxxxxxxxxxxxxx/LocURI
</Source ....
<Source
<LocURI>./devinf12</LocURI
</Source ....
<Source
<LocURI>./contacts</LocURI
</Source
I was also thinking that based on the device ID it might be deciding to
compare all items, which perhaps makes also sense. I'm not sure.
regards
So switching between home and office triggers a slow sync? I wonder
whether the phone sees different deviceIds for the SyncEvolution side in
that case.
There are two settings in SyncEvolution for this. From a config for the
Nokia N97:
# the identifier sent to the remote peer for a server initiated sync.
# if not set, deviceId will be used instead
remoteIdentifier = PC Suite
Yes this is true. I use actually the Nokia_N900 template
# The SyncML server gets this string and will use it to keep track
of
# changes that still need to be synchronized with this particular
# client; it must be set to something unique (like the pseudo-random
# string created automatically for new configurations) among all clients
# accessing the same server.
# myFUNAMBOL also requires that the string starts with sc-pim-
# deviceId =
We do server initiated syncs with phones, so "PC Suite" is sent to the
phone in the initial message. If I remember correctly, that had to be
that fixed string, at least with some Nokia phones.
Note that there's no unique deviceId here, which means that different
computers will all look alike to the phone, which then notices a
mismatch of sync anchors when moving between computers and thus forces a
slow sync.
Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this:
if (m_serverMode) {
// TODO: set the device ID for an OBEX server
} else {
substTag(xml, "fakedeviceid", getDevID());
}
I don't remember why that if() check is there, and why
SyncConfig::createPeerTemplate()'s
config->setDevID(string("syncevolution-") + UUID()) is not used to set a
unique deviceId when configuring phones.
Answering that would require some further code archeology and
experimenting; not sure when I will have time for that. Perhaps you can
check?
Here's an example of a sync with a SyncML server:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syn...
8:50 p.m.
On Fri, 2016-11-11 at 20:11 +0100, deloptes wrote:
Patrick Ohly wrote:
> Perhaps that's the reason for the if() check: a HTTP server might
> require a different LocURI (?) than an OBEX server, and the code does
> not immediately know what it is (depends on the transport).
I don't see it in the sync via bluetooth. I see in the html log
device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6
device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9
Where do you see that?
In the xml I see only the Nokia/Phone ID
<Source>
<LocURI>IMEI:xxxxxxxxxxxxxxxx/LocURI>
</Source>
....
<Source>
<LocURI>./devinf12</LocURI>
</Source>
....
<Source>
<LocURI>./contacts</LocURI>
</Source>
I was also thinking that based on the device ID it might be deciding to
compare all items, which perhaps makes also sense. I'm not sure.
The initial, so called SAN message, is not getting dumped. See
SyncContext::sendSAN() for the code which generates it. That there's no
LocURI for SyncEvolution confirms my theory that the phone can't
distinguish between the different computers.
However, after thinking some more about it I suspect that sending a
LocURI as part of the SyncML session wouldn't help: basically the phone
picks the configuration (and thus the sync anchors) based on the
information in the SAN message. At least that's how SyncEvolution does
it.
It's worth trying with remoteIdentifier set differently on the two
computers.
--
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.
1527
days inactive
1528
days old
syncevolution@synevolution.org
6 comments
2 participants
participants (2)
-
deloptes -
Patrick Ohly