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.
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:
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
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
VTIMEZONEs 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
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
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
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. a
VEVENT) 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
SELECT size,uri,calendardata FROM [PREFIX]calendarobjects WHERE calendarid = [ID] ORDER BY size DESC LIMIT 30;
How big are they (
size)? Examine field
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: