On Mo, 2010-11-01 at 20:02 +0000, [email protected] wrote: > Hi Patrick, > > On Mon, 1 Nov 2010, Patrick Ohly wrote: > > That means "not found" - whatever wasn't found might be visible in the > > logs. Can you share a log with the settings that at least triggered > > synchronization on the phone? > > I already sent an email containing log and settings, but without success, > the message is too big and needs approval by the list moderator.
Sorry, public holiday here today, so I'm not reading all of my email. Normally I would have noticed and approved it. > So, I've put the files on http://ravenea.m-otion.at/~knipp That shows that the phone is sending an incorrect Alert command: [2010-11-01 14:04:56.664] - Processing Alert Item (code=201), Source='Contacts', Target='' Note the empty "Target" value. That's supposed be our URI, sent to the phone earlier in the SAN message (not logged). For comparison, a Nokia phone correctly sends us that: [2010-11-01 13:56:00.470] - Processing Alert Item (code=200), Source='/telecom/pb.vcf', Target='Contacts' > I already tried „Contact“ as given by the template, „Contacts“ as seen as > SourceRef in the response from the phone and „card3“ as read in the wiki > for another Sony phone. I even tried to set the uri property to an empty > string. Just to be sure, is that "empty string" test perhaps where the empty value came from in the log above? If the phone always sends an empty string, then I can think of a reasonably easy (?) workaround: fall back to the Source value when the Target is empty. > Interestingly I cannot find the value of the uri property somewhere in the > syncevolution-log.html nor in the XML files. If you log with an even higher log level (say 10), then you'll see the Synthesis XML config which contains <datastore> entries with these URIs as aliases. The SAN message in SyncML 1.2 also contains it, but it is not logged. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
