Re: [Evolution-hackers] Need help debugging owncloud caldav problem
- From: James Bottomley <James Bottomley HansenPartnership com>
- To: Milan Crha <mcrha redhat com>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Need help debugging owncloud caldav problem
- Date: Tue, 24 Nov 2015 15:17:29 +0300
On Wed, 2015-11-18 at 10:03 -0800, James Bottomley wrote:
On Wed, 2015-11-18 at 07:53 +0100, Milan Crha wrote:
On Tue, 2015-11-17 at 09:42 -0800, James Bottomley wrote:
Shows they're all present, including the ones evolution is not
displaying. I suspect there's some issue somewhere in the ical file
that's causing a parse problem ... so my question, how do I debug
this? Is there a magic debug option to show parsing of ical events?
Hi,
there is no magic option to debug parsing of the iCalendar object, the
only CalDAV related debugging option you already found and used
properly.
Sigh, that's what I suspected from reading the code; thanks for
confirming.
I would double-check that you do not have any filters set in the
Evolution's UI, then pick one of those missing events and enter a
similar one into the CalDAV calendar. Then compare the two objects in
the local cache and see the differences. Compare also UID and
RECURRENCE-ID properties of the components, the later is there for
recurring events only.
Right, no filters. Actually I've been copying events into a local
calendar (as in creating an ical file from the events in the local
caldav cache) ... what do you know, not only do they appear, but the
missing equivalent in the caldav calendar also appears. So I'm thinking
this is either some sort of iterator problem in the data server itself,
or in the actual evolution front end.
It would be also interesting if you could share one of the missing
events, with sanitized values like the Summary, Description and any
e-mail addresses and such - anything you consider private.
I will if I can find one which genuinely fails ... as in it won't appear
even when placed into a separate ical file.
OK, I think I've identified one reason. It seems to be a misparsing of
DTEND in the caldav cache. An event that's not appearing is triggering
this warning:
(evolution:19872): calendar-gui-CRITICAL **: e_day_view_add_event:
assertion 'start <= end' failed
And, on checking the calendar.ics cache, this appears for the times:
DTSTART;TZID=America/Los_Angeles:20131024T180000
DTEND;TZID="America/Los_Angeles;VALUE=":20131024T200000
Removing the quotes and the spurious ;VALUE= for the DTEND TZID causes
the event to become visible when evolution is restarted. So, it looks
like something in the caldav connector is adding bogus data to the TZID
information.
James
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]