Hi,
I am using the nextcloud calendar app with Five different calendars. Four of them work just fine but one of them âstudiesâ creates trouble:
- In the nextcloud itself, when I change the month, this specific calendar takes like 10 seconds to load the events.
- When I want to âDownloadâ the calendar âstudiesâ, it brings me to:
This page isnât working - blabla.net is currently unable to handle this request. HTTP ERROR 500
- I use Thunderbird/Lightning through CalDav to have my calendars on my computer. This synchronizes all other calendars but for this one calendar I get an explanation mark and donât see any events. The Thunderbird Debug Log states:
CalDAV: Error doing webdav sync: 500
Lightning:âThere has been an error reading data for calendar: studies. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_REPORT_ERROR. Description: There has been an error reading data for calendar: https://blabla.net/nextcloud/remote.php/dav/calendars/blabla/studies/. It has been disabled until it is safe to use it.â
Lightning:There has been an error reading data for calendar: studies. However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description:
Lightning:[calCachedCalendar] replay action failed: null, uri=https://blabla.net/nextcloud/remote.php/dav/calendars/blabla/studies/, result=2147500037, operation=[xpconnect wrapped calIOperation]
From what I found in other threads I could speculate that in this calendar some entry might have an invalid entry and that messes up the whole calendar. But I wouldnât know which entry that is or how to find it.
Other reasons I donât know.
Any ideas are highly appreciated.
Thanks,
ian
â
Running Nextcloud 16.0.5
Calendar App 1.7.1
On Linux Mint 19.2, Kernel 4.15.0-65
You could export the calendar with calcardbackup and then validate the *.ics file with sabreDav or another validator
calcardbackup itself doesnât check the calendar-Events for errors - it just exports what is in the database. But what also might work, is imporing the *.ics file to another calendar application and hope that the app will correct the errors.
Thanks Bernie for that suggestion. Could have remembered your tool. Sadly calcardbackup seems to have trouble with the same calendar.
On exporting it with standard options, it just gets stuck forever on
+ Saving calendar studies.ics (from db)...
while exporting the other calendars works fine. UPDATE: It is not forever. After 1 h it finishes. Will see what that .ics looks like now.
Using the https function ( ./calcardbackup /var/www/nextcloud -g -u /etc/calcardbackupusers -s -i
) exports all the calendars quickly but the calendar âstudies.icsâ is just an empty file.
Any other means to export the files or can I create a verbose output with calcarddav (Iâll check out your git now)?
So it turned out that the questionable calendar had a size of 400+ MB. Of which approximately 400+ MB were:
BEGIN:DAYLIGHT
DTSTART:20180325T020000
RDATE:20180325T020000
RDATE:20190331T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20181028T030000
RDATE:20181028T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
I donât know what caused this. But removing these (and adding back the last line âEND:VCALENDARâ) fixed the calendar. Now back to reasonable size.
If you have any idea what could cause these million lines of DAYLIGHT and STANDARD, maybe you can still shed some light on this.
Phew - no wonder calcardbackup took so long to export it!
The entry is a definition of daylight saving time which should actually reside within a VTIMEZONE
component. Did you import the fixed file already? Because you probably should have also inserted a END:VTIMEZONE
Just before END:VCALENDAR
. But possibly importing the *.ics-file to a client made the client fix that.
I would suppose, that a client caused these entries.
What could be the problem now is, that there might be an event with a TZID
which doesnât match a TZID
within any of the remaining VTIMEZONE
-components. Maybe you want to check that in the fixed file. If there is no VTIMEZONE
-component with the TZID
of the event within the file, you very likely may find an according VTIMEZONE
-component in another *.ics-file from the ones calcardbackup exported. Just add this complete VTIMEZONE
-component to the end of the file right before END:VCALENDAR
.
If you want to dig deeper, have a look at the section about VTIMEZONE-component in RFC 5545
Anyway - I am glad to hear that my script helped to solve the problem
Ouf - this turns out trickier than I thought.
So first it seems that my calendars do define the VTIMEZONEs
before the events. Hence there should not be a END:VTIMEZONE
at the end of the file.
On the other hand they did have some weird crappy VTIMEZONE
s which luckily did not get used more than once, I just fixed everything to Europe/Berlin
where appropriate.
Apart from that it seems that some of my clients do really mess up my files. Quite some errors in the file. Especially VALARM
seem not to be compatible between lightning and my smartphone calendar.
Additionally it seems my blown-up calendar (the one causing trouble) lost all the recent events (since April). So maybe those events were further down in the file and I removed those as well. Need to check. Not that easy to work in 400-MB-files with text editors.
Thank you very much for your help and your effort with calcardbackup
Honestly, the documentation of the whole ikalendar standards is not very helpful if you want to fix your files. I would rather like to see some examples on their website(s).
That is also possible and no mistake. The VTIMEZONEs
could even be in the middle of the file and not next to each other. The DAYLIGHT
and STANDARD
sections need to be within a VTIMEZONE
-component though. Nextcloud exports *.ics files with VTIMEZONEs
at the beginning of the file, while calcardbackup first exports all other components and adds the VTIMEZONEs
at the end of the file. That is why I assumed the section you posted was at the end of the file and why I wrote to add the closing tag END:VTIMEZONE
at the end of the file just before END:VCALENDAR
.
If your VTIMEZONEs
are at the beginning of an with calcardbackup exported *.ics-file, there is possibly a component with wrong syntax (defining a VTIMEZONE
within e.g. aVEVENT
) in your database.
A syntactically wrong event may also be the reason for the loss of events from April, because calcardbackup is not able to âseeâ them. It is hard to tell though what exactly the problem is, because faulty iCalendar components in the database might lead to any kind of problem with calcardbackup since it doesnât include a check for correct syntax of the single components in the database.
What you could do, is to examine the biggest components (column calendardata
) in the calendar. The following command will list the 30 biggest ones (replace [ID] with the id of the studies-calendar from table calendars
):
SELECT size,uri,calendardata FROM [PREFIX]calendarobjects WHERE calendarid = [ID] ORDER BY size DESC LIMIT 30;
How big are they (size
)? Examine field calendardata
Another thing: the 500 errors reported by your browser or thunderbird are most likely php-timeouts.
P.S.: maybe RFC 5545 is to detailed. Those two might be a better starting point: