Hello Thomas! Some tests related to sending an updated event or task to the server which fail (testUpdate, testAddUpdate). What I see is that client A sends an updated to the server. Then client B syncs in two-way and should be sent that update, but doesn't get it: Overview: http://runtests.syncevolution.org/2011-02-05-04-52/head-evolution-testing... Add item log: http://runtests.syncevolution.org/2011-02-05-04-52/head-evolution-testing... Send update log: http://runtests.syncevolution.org/2011-02-05-04-52/head-evolution-testing... Receive update log (without the update): http://runtests.syncevolution.org/2011-02-05-04-52/head-evolution-testing... A different test (testAddUpdate) which adds the item from client A and then updates it from A before sending to B implies that the item doesn't seem to be updated on the server (client B gets the old data) - I haven't verified that in the web interface, though. Any idea?

On Do, 2011-02-10 at 13:01 +0000, Thomas Pequet wrote: > It is strange because normally it works. Normally there is no cache data > so the event is sent to client B > Can you try again, and wait 1 minute before sync the client B? I tried that, but it still fails. This is a bit weird because I cannot reproduce the failure outside of the test machine. It fails reliably there, though. Is there a way how you can check in the server logs what fails? If you need to increase the log level temporarily, then we can arrange for a time and I'll run the test while you watch.

Hello Patrick Sorry for the delay ... The problem come may be from the user agent that have no "SyncEvolution" value ...

I have added an other test to determine if is SyncEvolution with "syncevolution-" in "LocURI".

On Fr, 2011-02-25 at 17:19 +0000, Thomas Pequet wrote: > The problem come may be from the user agent that have no > "SyncEvolution" value ... I have added an other test to determine if > is SyncEvolution with "syncevolution-" in "LocURI". Should that be active already? It's still failing as recently as today: http://runtests.syncevolution.org/2011-02-28-21-30/head-evolution-hardy-2...

On Di, 2011-03-01 at 08:08 +0000, Thomas Pequet wrote: > Yes it is active... > What is the error in the file ? Which line ? NICKNAME is still lost, because it is not listed in the DevInf: http://runtests.syncevolution.org/2011-02-28-21-30/head-evolution-hardy-2... The client identified itself as <SourceRef>syncevolution-492118bd-9db9-44a2-b57b-1b10886650b8</SourceRef>

On Di, 2011-03-01 at 15:54 +0000, Thomas Pequet wrote: > In fact, it is normal, besause the "Rx-Pref" and "Tx-Pref" are > "text/v-card" 2.1 and not "text/vcard" 3.0. > So Memotoo send only: > > <CTCap> > <CTType>text/x-vcard</CTType> > <VerCT>2.1</VerCT> > > If you set the pref Rx and Tx to 3.0, Memotoo will send the field > Nickname. I thought we had arrived at a solution where vCard 3.0 is used automatically when SyncEvolution is detected, but you are right. Making vCard 3.0 the preferred format will require all SyncEvolution to update their configs... unless I change the default. Let me try that and see whether it breaks some other server.

On Mi, 2011-03-02 at 10:28 +0000, Patrick Ohly wrote: > On Di, 2011-03-01 at 16:19 +0000, Patrick Ohly wrote: >> On Di, 2011-03-01 at 15:54 +0000, Thomas Pequet wrote: >>> In fact, it is normal, besause the "Rx-Pref" and "Tx-Pref" are >>> "text/v-card" 2.1 and not "text/vcard" 3.0. >>> So Memotoo send only: >>> >>> <CTCap> >>> <CTType>text/x-vcard</CTType> >>> <VerCT>2.1</VerCT> >>> >>> If you set the pref Rx and Tx to 3.0, Memotoo will send the field >>> Nickname. >> I thought we had arrived at a solution where vCard 3.0 is used >> automatically when SyncEvolution is detected, but you are right. Making >> vCard 3.0 the preferred format will require all SyncEvolution to update >> their configs... unless I change the default. Let me try that and see >> whether it breaks some other server. > It does (for example, Mobical). Therefore I have reverted to vCard 2.1 > as the default sync format and implemented a different approach for > MemoToo: [...] That fixed the issue with vCards. But the original problem mentioned in this thread, updates of iCalendar items, still exists. Any suggestion how to debug this? I already tried with longer delays between syncs, without luck. See the "testUpdate" and "testAddUpdate" tests in: http://runtests.syncevolution.org/2011-03-02-21-30/head-evolution-testing...

On Sa, 2011-03-05 at 11:02 +0000, Thomas Pequet wrote: > Patrick, > > Can you send me exactly the links where you have done the tests, > because I do not where to see ... > And explain me again the problem ? Here's the problem description with updated links: Some tests related to sending an updated event or task to the server which fail (testUpdate, testAddUpdate). What I see is that client A sends an updated to the server. Then client B syncs in two-way and should be sent that update, but doesn't get it: Overview: http://runtests.syncevolution.org/2011-03-02-21-30/head-evolution-testing... Add item log: http://runtests.syncevolution.org/2011-03-02-21-30/head-evolution-testing... [2011-02-05 11:14:29.750] RECEIVED STATUS 201 for for command 'Add' (outgoing MsgID=2, CmdID=5) Send update log: http://runtests.syncevolution.org/2011-03-02-21-30/head-evolution-testing... [2011-02-05 11:15:08.678] RECEIVED STATUS 200 for for command 'Replace' (outgoing MsgID=2, CmdID=5) ... [2011-02-05 11:15:12.237] Successful end of session -> calling engFinishDataStoreSync() for datastores now Receive update log (without the update): http://runtests.syncevolution.org/2011-03-02-21-30/head-evolution-testing... [2011-02-05 11:15:22.313] ---- System time in UTC : 2011-02-05 11:15:22.313 A different test (testAddUpdate) which adds the item from client A and then updates it from A before sending to B implies that the item doesn't seem to be updated on the server (client B gets the old data) - I haven't verified that in the web interface, though. The time stamps on the client show that the last session with client B starts 10 seconds after the end of the previous session with client A, and roughly 14 seconds after the item was updated on the server.

Is this "SyncEvolution -> Memotoo" setting the default for new devices?

On Sa, 2011-03-05 at 17:06 +0000, Thomas Pequet wrote: > Thanks Patrick > > I have seen that the device > "syncevolution-3b3d8d41-71db-477b-b91a-08600a31cd93" (the 2nd) sync > only "Evolution -> Memotoo" in Memotoo: > https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50113 Each test session starts with random device IDs, as if the user had started using MemoToo for the first time.

Does it mean that all users who want to download data from Memotoo need to reconfigure their account? Does it apply only to *updates* during a two-way sync? *New* items seem to get transferred (but that might be during a slow resp. refresh-from-server sync). I also noticed that only calendar items were affected. The test passed for contacts - shouldn't it also fail for those? I'll change the testing to use fixed device IDs now, and try again. Hmm, didn't work. I used the "syncevolution" account, device IDs sc-api-A and sc-pim-B. The test fails, but the web interface shows "both ways" for these two devices and calendar events. The synchronization history for "sc-api-A" shows: phone meeting SyncEvolution » Memotoo : Add 2011-03-06 - 16:35:42 (G.M.T. +1) There should also be a later entry for *updating* that item. To me it looks like the server ignores the Replace command from the first client (sc-api-A in this case): https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50476 The data on the server definitely is the older item, not the update.

On Mi, 2011-03-16 at 08:44 +0000, Thomas Pequet wrote: >> Is this "SyncEvolution -> Memotoo" setting the default for new devices? > The default setting is "both ways" > > "sc-pim-B" is actually "Evolution -> Memotoo" for calendar, I think it > comes during the diffrents test you do before this test... > https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50477 I don't understand. How is that setting related to the earlier tests? Perhaps I don't understand the meaning of this setting. My understanding so far was that it is a server-side setting which somehow overrides the sync mode requested by the client. Is that correct? If not, what does that setting really do? What you say above makes it sounds like the setting is taken from the client's sync mode. If so, why have that setting at all if the client can change it at any time? Anyway, the setting seems to be irrelevant. It seems I cannot get the server to apply an update to calendar data with a Replace command at all. How can we debug this? Bye, Patrick > Le 06/03/2011 16:52, Patrick Ohly a écrit : >> On Sa, 2011-03-05 at 17:06 +0000, Thomas Pequet wrote: >>> Thanks Patrick >>> >>> I have seen that the device >>> "syncevolution-3b3d8d41-71db-477b-b91a-08600a31cd93" (the 2nd) sync >>> only "Evolution -> Memotoo" in Memotoo: >>> https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50113 >> Each test session starts with random device IDs, as if the user had >> started using MemoToo for the first time. >> Does it mean that all users who want to download data from Memotoo need >> to reconfigure their account? >> >> Does it apply only to *updates* during a two-way sync? *New* items seem >> to get transferred (but that might be during a slow resp. >> refresh-from-server sync). >> >> I also noticed that only calendar items were affected. The test passed >> for contacts - shouldn't it also fail for those? >> >> I'll change the testing to use fixed device IDs now, and try again. Hmm, >> didn't work. I used the "syncevolution" account, device IDs sc-api-A and >> sc-pim-B. The test fails, but the web interface shows "both ways" for >> these two devices and calendar events. >> >> The synchronization history for "sc-api-A" shows: >> phone meeting SyncEvolution » Memotoo : Add 2011-03-06 - 16:35:42 (G.M.T. +1) >> >> There should also be a later entry for *updating* that item. To me it >> looks like the server ignores the Replace command from the first client >> (sc-api-A in this case): >> >> https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50476 >> >> The data on the server definitely is the older item, not the update. >> >>

On Mi, 2011-03-16 at 11:15 +0000, Thomas Pequet wrote: > You said "I also noticed that only calendar items were affected. The > test passed for contacts - shouldn't it also fail for those?". I think > it is an exception in Memotoo but to find it you must run again your > test. > > Can you try again your tests with "sc-api-A" and "sc-pim-B" ? I disabled the automated testing, which should make it easier to find the right logs on the server. Then I ran the calendar update test again. I had to restart it once more with slightly different settings, because I got an unexpected slow sync (the case where the server has no data - I thought we had resolved that, but perhaps I am mistaken). https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50476 (= sc-api-A of user syncevolution) now shows "phone meeting" added at 2011-03-16 - 12:30:41 (G.M.T. +1), but nothing about "meeting on site", which is the updated data sent later. If you want to debug this life, please ping me on IRC: pohly on irc.freenode.org or irc.gnome.org.