Re: [Opensync-users] Nokia E51: Received an Alert for the DS Server at Calendar

[Simon J. <si...@jo...>]

Michael Bell <mic...@cm...> writes:

>> Could the vformat problem explain why calendar syncing doesn't work,
>> when contact syncing works?
>
> Yes, I have myself heavy problems with OCS. Our vformat code creates
> several duplicates with the same UIDs internally. OCS detects this and
> returns errors while normal contact syncing works.

Would this result in 'ERROR' in trace logs?  I enabled tracing, but I
don't see any errors in those logs.  The problem seems to be on the
phone, which fails and disconnects.

>> Since the phone prints an error message, it seems likely that a phone
>> bug is involved.  But maybe libsyncml could behave like Nokia's own
>> software, to workaround this problem.  My message was partially to gauge
>> whether anyone else has seen this error, and if anyone compared traces
>> with Nokia's software.
>
> This is not necessarily a phone bug. If OpenSync duplicates entries
> but the new entry includes the same UID then the phone will detect
> that there are two objects with the same internal UID. This is an
> error and so the phone reports an error code.
>
> Again this is the vCard UID and not the UID of SyncML for this object.

I've searched for this problem a bit, and it seems to happen to a lot of
people, even with Nokia's own software.  And as far as I can tell, only
when syncing the calendar.  So I do suspect it is a phone bug after all.
I'll see if I can find a Windows machine and test syncing on it.

What worries me is that others have been able to work around this bug by
erasing their entire calendar and starting from scratch, but I can't
even get one simple calendar entry to sync properly.  Those people
typically end up with 'Sync Error' after a few sync's though, and have
to erase the calendar again.

>>>> However, syncing the calendar fails.  I've tried libsyncml 0.4.5 (in
>>>> Debian), and also libsyncml 0.4.6 (manual build), with same results.  I
>>>> just tried libsyncml from SVN, but that just fails with
>>>> 'sml_support.c:443:E:smlSafeFree: Assertion "*address" failed'.
>>> The assertion was newly introduced from me to detect wrong memory
>>> handling. Which subversion revision do you use?
>
> I fixed some of these smlSafeFree bugs today (plus some race
> conditions). I introduced smlSafeFree to detect unclean memory
> handling in the libsyncml code and the assertions are the consequence
> :(
>
> newest SVN rev 365 and 3128

It doesn't build:

/home/jas/src/libsyncml/tools/syncml-http-server.c: In function ‘main’:
/home/jas/src/libsyncml/tools/syncml-http-server.c:369: error: ‘SmlTransportHttpServerConfig’ has no member named ‘interface’

Thanks,
/Simon