Gents,
I was able to track this down to some bad content in the Note field for
a contact.(modified and attached with the bad character for the curious)
Perhaps an OSync 0.4 user can test and forward upstream if this is still
and unhandled use case.
My approach in trying to identify the bad record based on console output
for records going to my Berry was flawed. I started to think about why
removing the last record shown on console output only resulted in the
sync freezing one record sooner, and it dawned on me that it must be the
*next* record, even though there is no such indication in the
OSYNC_TRACE that suggests that writing of the next record had even
begun.
Using the OSYNC_TRACE from the initial load from evolution (earlier in a
different thread log), I identified what should be the next record to
sync to my BBerry (modified and attached for the curious) and observed
that it contains a non-UTF-8 character near the end of the record. I
suspect conversion between one of the various old clients (Outlook
97/98/2000/Evolution) software (HotSync/ToGo/PocketMirror/GnomePilot/BB
Desktop/Barry) and devices (Palm III/V/Samsung/BBerries) I have used
resulted in some unhandled conversion between character sets. The
interesting thing is that it does not cause any output similar to
"xmlEscapeEntities : char out of range" which I would have expected.
This would be consistent with Nicholas' comment I just read,
> But, I suspect that some data from Evolution can't be read by
> OpenSync.
>
> So my advice is :
> - purge all data into Evolution (address book, calendar, memo and
> tasks)
> - sync data (all data should be transfert to evolution)
> - sync a new times (none modification)
> - make some tests.
In my case, Evolution is the source, where I has just completed (and
will continue to) a merge of older backed-up address books. So syncing
data from the BBerry back to Evolution would be successful (since it was
populated by opensync in the first place) but would result in many hours
of lost data merging.
I know realize that this bad character issue is what plagued early
attempted syncs using 0.14 from my existing contact base. I suspect
other 'hung' people may be seeing issues with OpenSync handling data,
rather than conflict resolution which seems to be the go-to issue. A
long conflict resolution, stalled late in the process by a bad character
might be hard to identify root cause _ I think this is what I was seeing
in my early 0.14 trials where overnight a sync process would just
consume all my memory and leave my CPU spinning hot 16 hours later,
seemingly hung.
On Sun, 2009-11-29 at 18:52 +0000,
barry-devel-requ...@lists.sourceforge.net wrote:
> In my tests, I've so far only been able to reproduce a semi-long wait
> by
> erasing the Address Book on the BlackBerry, but leaving the Calendar
> intact on both the BlackBerry and Evolution. This causes opensync
> to go into conflict resolution mode for the Calendar, which of course
> takes a long time. I don't know if it is the same delay you're
> seeing.
>
> If you can do both Address Book and Calendar at the same time, with a
> one-way sync from Evolution to Barry, this might work better.
> Maybe you're already doing this? I only see an erase command for
> the Address Book above.
Additionally, I have learned/confirmed that purging the Calendar is
required also, as even after a reconfig, following a slow-sync warning
and abort. I will get duplicate calendar records otherwise. Also
confirmed is that --conflict 1/2/i, etc. is no help in preventing
duplicates following a reconfig, so purging both AddressBook and
Calendar on BBerry prior to a post-re-config sync is how I deal with
this now.
Feature Note: It would be nice if we could auto abort slow sync, rather
than relying on CTRL-C (or recover backup when missed); Sort of the
opposite of msynctool --slow-sync option. Its too easy for my 18 month
old to pull my cable unexpectedly mid-sync resulting in lost time as I
re-execute the entire process.
>
> Perhaps you missed my reply to my own email... you can also do this
> to erase a database:
>
> btool -a "Address Book" -P password
Thanks, I did catch this and used it for clearing my BBerry calendar
too.
>
> You can edit the default config directly
> under /usr/share/opensync/defaults.
> Then the default will pop up with the data you already need.
>
> It's a hack, but sure speeds things up. :-)
Great, I'll give this a try. This will shortcut the unexpected sync
interruption recovery, that IMHO is opensync's largest shortcoming in
the v0.2 train.
Thanks for the help,
cheers,
Ian
--
Ian B. MacDonald <ian.macdon...@n8id.com>
Director of Product Management
N8 Identity Inc.
W:(416)800-2209
M:(416)988-0856
BEGIN:VCARD
VERSION:3.0
CATEGORIES:Leads
REV:2009-08-22T03:36:24Z
UID:pas-id-4B0D6816000000D3
X-EVOLUTION-FILE-AS:Smith\, John
PRODID:-//OpenSync//NONSGML Barry Contact Record//EN
FN:John Smith
N:Smith;John;;;
LABEL;TYPE=work:USA\n
ADR;TYPE=work:;;;;;;USA
TEL;TYPE=voice,work:x12345
EMAIL;TYPE=internet,pref:john.sm...@email.com
TITLE:CTO
X-KADDRESSBOOK-X-Profession:CTO
ORG:Company\, Inc.
NOTE:Rep for named Account - Widgets \n\n05 mar. 2004 - Sent intro email
re biz oppty.\n09 Mar. - left vm\n10 Mar. - left vm.\n�\n
END:VCARD
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
