Error message Invalid VObject. Document ended prematurely.

[Kjukju]

While using the owncloud calendar I get this error message after entering a new date to a calender:

Invalid VObject. Document ended prematurely.

It does not matter if I enter the new date within the owncloud web interface or with a calender app on iPhone using caldav sync.

The entry is made in the DB table oc_calendar_objects correctly. If I add a new date to a different calender there will be no problems. The date is added correctly. I cannot solve the problem by creating a new calender and add a date to this new calender.

Owncloud version: 4.5.7
DB: MySQL on Linux Apache
PHP version: 5.3.3

[fvdm]

I have this same issue for all actions from iCal (OSX 10.8). Adding, changing, deleting events or agendas in the webapp works fine and correctly sync to iCal, but upstream from iCal to webapp results in the following errors.

owncloud.log:

{"app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":1372693568}
{"app":"PHP","message":"Call to a member function serialize() on a non-object at \/var\/www\/owncloud\/apps\/calendar\/lib\/sabre\/backend.php#272","level":4,"time":1372693568}

iCal error:

Server response 500
For action CalDAVAccountRefreshQueueableOperation

01-07-13 17:48:24,964 CalendarAgent[334]: [com.apple.calendar.store.log.caldav.queue] [Account refresh failed with error: Error Domain=CoreDAVHTTPStatusErrorDomain Code=500 "De bewerking kan niet worden voltooid. (CoreDAVHTTPStatusErrorDomain fout 500.)" UserInfo=0x7fe7a30889a0 {AccountName=ownCloud, CalDAVErrFromRefresh=YES, CoreDAVHTTPHeaders=<CFBasicHash 0x7fe7a7b09bf0 [0x7fff7a090110]>{type = immutable dict, count = 12,
entries =>
    0 : Case Insensitive Key: Content-Type = <CFString 0x7fe7a7b95430 [0x7fff7a090110]>{contents = "text/html; charset=utf-8"}
    2 : Case Insensitive Key: Pragma = <CFString 0x7fe7a7bc25c0 [0x7fff7a090110]>{contents = "no-cache"}
    5 : Case Insensitive Key: Set-Cookie = <CFString 0x7fe7a7b0fc70 [0x7fff7a090110]>{contents = "...; path=/; secure; HttpOnly, ...; path=/; secure; HttpOnly"}
    6 : Case Insensitive Key: Server = <CFString 0x7fe7a7b8f4c0 [0x7fff7a090110]>{contents = "Apache"}
    7 : Case Insensitive Key: Content-Encoding = <CFString 0x7fe7a7b66730 [0x7fff7a090110]>{contents = "gzip"}
    8 : Case Insensitive Key: Expires = <CFString 0x7fe7a7bceac0 [0x7fff7a090110]>{contents = "Thu, 19 Nov 1981 08:52:00 GMT"}
    12 : Case Insensitive Key: Cache-Control = <CFString 0x7fe7a7b5e770 [0x7fff7a090110]>{contents = "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"}
    13 : Case Insensitive Key: Date = <CFString 0x7fe7a7b7b870 [0x7fff7a090110]>{contents = "Mon, 01 Jul 2013 15:48:24 GMT"}
    15 : Case Insensitive Key: Strict-Transport-Security = <CFString 0x7fe7a7bcefa0 [0x7fff7a090110]>{contents = "max-age=31536000"}
    16 : Case Insensitive Key: Content-Length = <CFString 0x7fff7a06a9e0 [0x7fff7a090110]>{contents = "20"}
    17 : Case Insensitive Key: Connection = <CFString 0x7fe7a7b62a90 [0x7fff7a090110]>{contents = "close"}
    21 : Case Insensitive Key: Vary = <CFString 0x7fe7a7b090f0 [0x7fff7a090110]>{contents = "Accept-Encoding"}

My specs:
ownCloud v5.0.7
Apache 2.2 with SSL

iCal v6.0
Mac OSX 10.8.4

[rimeraz]

I'm afraid I experience the same error message here:

{"app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":1374492780}

ownCloud 5.0.9
Apache 2.2.3 with SSL
PHP 5.3

I guess this is the reason for my syncing problems between Android (via CalDavSync) and ownCloud for one particular calendar. From http logs I can see the following:

1.2.3.4 - myuser [23/Jul/2013:07:52:52 +0200] "REPORT /oc/remote.php/caldav/calendars/myuser/calendarname/ HTTP/1.1" 500 285 "CalDAV-Sync (Android) (like iOS/5.0.1 (9A405) dataaccessd/1.0) gzip"

This appeared the first time on 2013-07-22 01:51. ownCloud 5.0.9 has been installed two days before and between 2013-07-20 and 2013-07-22 I had no problems.

[georgehrke]

Can you verify this patch?

https://gist.github.com/georgehrke/5999629

[rimeraz]

I tried your patch but I still get the sync errors and the HTTP 500 in my apache log. But I don't get the serialized error message in ${owncloud_data}/owncloud.log every time.

But - and that's good news - I solved my issue. It was caused by an invalid calendar entry in oc_clndr_objects. The entry was (sql-exported format):

INSERT INTO `oc_clndr_objects` (`id`, `calendarid`, `objecttype`, `startdate`, `enddate`, `repeating`, `summary`, `calendardata`, `uri`, `lastmodified`) VALUES
(759, 3, 'VEVENT', '2013-08-11 05:16:00', '2013-08-11 10:34:00', 0, 'D', 'BEGIN:VCALENDAR\nVERSION:2.0\nPRODID:ownCloud Calendar 0.6.3\nBEGIN:VEVENT\r\nUID:bahn20130811071600\r\nCLASS:PUBLIC\r\nSUMMARY:D', 'owncloud-d74e72cb9709fc5a662304635e9fced9.ics', 1374437727);

I wondered about that summary "D". But then I remembered that it should have been created by an .ICS-file provided by Deutsche Bahn which I uploaded to my ownCloud and tried to import it from there:

BEGIN:VCALENDAR
X-LOTUS-CHARSET:ISO-8859-1
VERSION:2.0
PRODID:http://www.bahn.de
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:bahn20130811071600
CLASS:PUBLIC
SUMMARY:Düsseldorf-Benrath -> Ilsenburg
DTSTART;TZID=Europe/Berlin:20130811T071600
DTEND;TZID=Europe/Berlin:20130811T123400
DTSTAMP:20130721T215400Z
DESCRIPTION:Reise: Düsseldorf-Benrath nach Ilsenburg\nDatum: 11.08.2013\n\nab Düsseldorf-Benrath 07:16\nan Ilsenburg 12:34\n\nAlle Angaben ohne Gewähr. Fahrplanänderungen vorbehalten. Bitte prüfen Sie kurz vor der Reise den aktuellen Fahrplan unter: www.bahn.de
END:VEVENT
END:VCALENDAR

Because the summary ends after the initial D, I suspected the umlauts to be responsible for the incomplete import. I replaced the umlauts with vowels:

BEGIN:VCALENDAR
X-LOTUS-CHARSET:ISO-8859-1
VERSION:2.0
PRODID:http://www.bahn.de
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:bahn20130811071600
CLASS:PUBLIC
SUMMARY:Duesseldorf-Benrath -> Ilsenburg
DTSTART;TZID=Europe/Berlin:20130811T071600
DTEND;TZID=Europe/Berlin:20130811T123400
DTSTAMP:20130721T215400Z
DESCRIPTION:Reise: Duesseldorf-Benrath nach Ilsenburg\nDatum: 11.08.2013\n\nab Duesseldorf-Benrath 07:16\nan Ilsenburg 12:34\n\nAlle Angaben ohne Gewaehr. Fahrplanaenderungen vorbehalten. Bitte pruefen Sie kurz vor der Reise den aktuellen Fahrplan unter: www.bahn.de
END:VEVENT
END:VCALENDAR

The corrected version uploads and imports flawlessly and syncing works afterwards as apache log shows:

1.2.3.4 - myuser [23/Jul/2013:19:38:59 +0200] "REPORT /oc/remote.php/caldav/calendars/myuser/mycalendar/ HTTP/1.1" 207 2164 "CalDAV-Sync (Android) (like iOS/5.0.1 (9A405) dataaccessd/1.0) gzip"

I don't know if umlauts have to be encoded within .ICS-files but my problem obviously shows two issues with ownCloud:

1. ownCloud does not handle malformed / mis-encoded .ICS-files properly. I just verified that the original .ICS with the umlauts imported with "1 events has been saved in your calendar" which reads at least to me like a success message.
2. ownCloud (or whatever component will be relied on for CalDAV-sync) will be broken by malformed calendar entries.

[georgehrke]

the first issue is something that has to be fixed.
the second issue should actually be fixed with the patch I mentioned earlier. Have you tried to increase the ctag of the corresponding calendar in the oc_calendar_calendar / oc_clndr_calendar table?

[rimeraz]

I know about Linux, Apache, MySQL and PHP so I can run my own ownCloud instance but I have no clue about the internals of ownCloud.

If I can contribute that way, I'll be happy to verify the issue with increasing the ctag but please give me at least a hint what it will be used for (just for curiosity as I could not find the proper ownCloud documentation) and what value to choose.

Should I just increase by 1 or increase ctag to be the highest value? In my case the calendar with the second highest ctag value was affected. I have a feeling that the ctag value might be related to the number of events stored in that calendar but this is only a wild guess.

[georgehrke]

You have to increase it by one. This shows the client that something changed and that it has to update

[rimeraz]

nope, doesn't help with increase ctag

[maurice1]

Hi, I'm having the same problem using ownCloud 5.0.10. I hope this will be fixed soon, as the whole calendar can't be loaded with Thunderbird's Lightning as soon as there's at least one Calendar Item with the UTF-8/encoding problem (which is the same problem with the Deutsche Bahn .ics files, I think). As far as I'm able to, I'll investigate further on this and will report updates here.

[Gomez]

Got the same error. A workaround was export the calendar and reimport the ics.

[georgehrke]

cc @evert

[evert]

If there's a vobject bug, please open a ticket at https://github.com/fruux/sabre-vobject with a simple script to reproduce this issue and which version this problem occurred.

[georgehrke]

https://github.com/fruux/sabre-vobject/issues/59

[jancborchardt]

I’m closing this issue because it has been inactive for a few months. This probably means that the issue is not reproducible or it has been fixed in a newer version.

Please reopen if you still encounter this issue with the latest stable version and the ownCloud 6 beta. Then please use the issue template and note the Calendar issue tracker moved to http://github.com/owncloud/calendar/issues.

You can also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[JimLoose]

@jancborchardt It's not fixed!!!

I have ownCloud 7.0.4 (stable) + a lot of entries with:
Invalid VObject. Document ended prematurely.

My problem is, that the Calendar sync seems to work flawless with OSX Yosemite and iOS 8.
But i miss a lot of calendar entries in my iOS 8 Calendar :(

I have no clue how to reproduce, which of my thousands entries is the problem.
Anyway i have to drop OwnCloud anyway, because i need a reliable system! :(

[jancborchardt]

@JimLoose first, sorry for the problems. Can you open a new issue in the Calendar issue tracker and use the issue template to supply the needed info? Thanks!

[JimLoose]

@jancborchardt
i unfortunately have no time to dive into the bug that deep! I already dropped OwnCloud Calendar! Sorry!
I can't export my calendar to the public as well :(

[joefidler]

Yes I agree this error occured for us last Friday and is not fixed. I am still trying to gather information on the error but its probably a corruption in a calendar database - which resulted in the database being not syncable from CalDav clients (web access was OK) - giving the document premature end message - very bad. I was running on a shared host so have only found a HTTP log file so far which does not show the error. Wish there were more diagnostic tools within Owncloud itself, and tools to "clean up" or repair a broken database. We have since switched away from OwnCloud until I can figure out what happened, and hopefully open a bug report. Too bad after a month of trialing OwnCloud, we liked it.

[georgehrke]

@joefidler This error means that the calendar-data itself is broken. If you enable the debug mode you'll get more information including the id of the object so you can check what's broken with the calendar-data

EDIT: * calendar-data of a certain object

[joefidler]

Thanks @georgehrke for the reponse. Unfortunately I deleted the OwnCloud instance and created a new one trying to get things working again. The only thing I have left of the failed OwnCloud is the MySQL database itself. I tried poking around in that with phpMyAdmin but really have no idea how to look at data with that tool.

The only hard information I have was that the most effected data was a Tasks calendar database - using the third-party tasks app (https://apps.owncloud.com/content/show.php/Tasks?content=164356). This database was accessed from the Android CalDav Tasks app (https://play.google.com/store/apps/details?id=org.dmfs.tasks&hl=en). When this tasks data was lost it also effected CalDav access to the calendar associated with it, but I was still able to access this (and download it) via the web.

I have no other logs etc to analyse, the tasks calendar database was completely lost. Its possible that this error was caused by the Tasks app + CalDav Sync on Android - and its their bug - or there was some data loss over the network connection. But for me the bottom line is that a corruption in data should not cause a crashed, unusable, lost database on the OwnCloud server side. That seems like its not only a reliabity issue but maybe even a potential security issue.

[georgehrke]

But for me the bottom line is that a corruption in data should not cause a crashed, unusable, lost database on the OwnCloud server side.

The whole database is not lost. It's an error message, that's supposed to tell you that certain events are broken. The calendar is (/ should) still be accessible, even though it contains broken data.

[joefidler]

Agreed the data is still in the database, but after we saw the Invalid Object message we could no longer access that Tasks data by any method. The tasks data from that calendar no longer displayed on the web client and gave errors to the CavDav clients. Other calenders and tasks lists were still accesible. I also could not export the data - to recreate a new calendar, so for us that portion (agreed not the whole) of the database was lost.

[georgehrke]

The tasks data from that calendar no longer displayed on the web client

That's a bug in task app and not directly related to the calendar, please report a bug there.

gave errors to the CavDav clients.

That seems to be a bug in the calendar. please report a new bug in the calendar repo using the issue template jan mentioned above
If the data is not too sensitive, please attach an example for broken data.

[joefidler]

Agreed there is probably a bug in the task app which caused the problem which I will try to followup there. Will also to try and find the broken data in the calendar data and post and an issue report for that.

[JimLoose]

i bet we have attachments or geolocation or comments in the original imported mac os calendar (which supports all that)

[georgehrke]

i bet we have attachments or geolocation or comments in the original imported mac os calendar (which supports all that)

we also support all that.
Error message Invalid VObject. Document ended prematurely. means that the calendar-data is broken and ended unexpectedly. If that's the case OS X calendar should also not be able to parse it.

[JimLoose]

OS X + iCloud works flawless

[georgehrke]

There might still be an issue with 4-byte unicode chars, although I was sure a fix was merged in core ...

[joefidler]

For what its worth we use (used) a mix of Android (4.4.4) with CalDAV, and Linux (OpenSUSE) with Thunderbird and SoGo connector for clients. No OS X.

[JimLoose]

could somebody please reopen this bug, until we have a better bugreport?
(It's definitly an issue + this one is quite difficult to hunt)

[joefidler]

To test things I uploaded an exported copy of the "broken" calendar to a fresh OwnCloud database. No calendar data including tasks was lost, and I could not find any funny chars or corrupted data etc. The fact that I was able to restore all the data from the tasks list was surprising - the failed database was functional enough to export an intact ics file.

[disy-mk]

Same issue here; maybe the problem of not being unable to share my calendar has is to be credited back to this issue.

[georgehrke]

please try to gather as many information about the broken calendar-data as possible. Just saying that you have the same issue doesn't really help if you don't provide example data.

[disy-mk]

Well of course I will; I just need someone to point out how to find out which vobject id causes the problem (c.f. the reference above my post)

[georgehrke]

enable the debug mode and use the calendar. Some debug notices with information about the id should be logged

[disy-mk]

I did (set log level to 0). This is the log:

{"reqId":"54c0de4e42cf7","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:26:06+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de4e42cf7","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:26:06+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de5a52573","app":"webdav","message":"Sabre\\DAV\\Exception\\NotAuthenticated: No basic authentication headers were found","level":0,"time":"2015-01-22T11:26:18+00:00","method":"PROPFIND","url":"\/remote.php\/webdav"}
{"reqId":"54c0de6a74f6d","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:26:34+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de6a74f6d","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:26:34+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de6b9b982","app":"webdav","message":"Sabre\\DAV\\Exception\\NotAuthenticated: No basic authentication headers were found","level":0,"time":"2015-01-22T11:26:35+00:00","method":"PROPFIND","url":"\/remote.php\/webdav"}
{"reqId":"54c0de775451d","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:26:47+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de775451d","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:26:47+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de827f83e","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:26:58+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de827f83e","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:26:58+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de8cb897b","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:27:08+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de8cb897b","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:27:08+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de97d2755","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:27:19+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0de97d2755","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:27:19+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0dea2babb6","app":"vobject","message":"Invalid VObject. Document ended prematurely.","level":3,"time":"2015-01-22T11:27:30+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0dea2babb6","app":"PHP","message":"Call to a member function getAsString() on a non-object at \/srv\/www\/cloud.DOMAIN.com\/htdocs\/apps\/calendar\/lib\/object.php#542","level":3,"time":"2015-01-22T11:27:30+00:00","method":"PROPFIND","url":"\/remote.php\/caldav\/calendars\/app\/EMPLOYEENAME(COMPANYNAME)_shared_by_mg\/"}
{"reqId":"54c0df0104804","app":"webdav","message":"Sabre\\DAV\\Exception\\NotAuthenticated: No basic authentication headers were found","level":0,"time":"2015-01-22T11:29:05+00:00","method":"PROPFIND","url":"\/remote.php\/webdav"}

[JimLoose]

Could somebody please reopen this issue?

[georgehrke]

@JimLoose no, this is the wrong repo and @disy-mk already created a new issue in the calendar repo.

Edit: to be precise: this one

[cquike]

I am also having a similar issue with Owncloud 8.1. @georgehrke: your link to the new issue is broken, could you please post the correct one?

[georgehrke]

Well, you asked, here it is: https://github.com/owncloudarchive/calendar/issues/680

But it won't be of much help, because every version of the calendar app prior to ownCloud 9 is unsupported and there won't be any bugfix releases.

[Quantentunnel]

Working with owncloud 8.2, I had the same issue. The error appears with one of my 5 calendars. The calendar still works with the owncloud web-interface. So I looked on the table in the mysql database. I found only one event which were created on the day before. So I deleted it with phpmyadmin and after that, it worked again. The event was created with miCal on iOS 10. The event is in September 2018 and now we have February 2017.
Maybe these information helps you to fix the error.

[PVince81]

@Quantentunnel did that event have a syntax error in it ?

From what I heard, future versions of OC (and Sabre library) will be more robust in regards to syntax errors.

[Quantentunnel]

@PVince81
I don´t know. There was signal why I choosed this event. It was only the last inserted event in owncloud calendar.

But now 24 hours later the same error occurs again. Now I am trying to upgrade from 8.2 to 9.0. I don´t know why but nearly every owncloud update and upgrade crashed. My only plugin is the calendar. So I guess this will happen again and I need some time until I give you more feedback and tell you if the upgrade was/is the solution.

[Quantentunnel]

The upgrade from 8.2 over 9.0 to 9.1 works quicker than I expected. Only one error after the upgrade: owncloud/calendar#771
And no fatal error after upgrading. That is a new record!

Currently it is working. Let´s see what will happen in 24 hours. I keep you informed.

[Quantentunnel]

Nearly 24 hours later, the calendar still works!

The solution seems to be:

1. Upgrade to owncloud 9.1 (if you use 8.2 please upgrade first of all to 9.0 and then to 9.1!!)
2. Activate the "Share Files" plugin
3. Follow the instruction to update the "Share Files" plugin
4. Check if the "Share Files" plugin is really actived.