Terminerinnerung: Dieser Termin wurde auf dem Server geändert

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

• Thunderbird-Version (konkrete Versionsnummer 78.4.3
• Lightning-Version: n/a
• Betriebssystem + Version: n/a
• Google-Kalender mit "Provider for Google-Calendar" (ja/nein): nein
• Google- oder sonstiger Kalender mit WebDAV / CalDAV (ja/nein/was genau): CalDAV auf Nextcloud u.a. .
• Eingesetzte Antivirensoftware: -
• Firewall (Betriebssystem-intern/Externe Software): -

Das Problem, dass Terminerinnerungen bei CalDAV-Kalendern manchmal hartnäckig sind und sich nicht einfach schließen lassen, ist in diesem Forum bereits mehrfach gemeldet worden. Eine dauerhafte Lösung dazu ist mir nicht bekannt. Ich bin es bisher dadurch umgangen, dass ich das Offline-Bereithalten deaktiviert habe.

Nun bin ich vor ein paar Jahren von einem Radicale-Server zur NextcloudPi gewechselt. Da der RasPi nicht gerade ein Performance-Monster ist, würde ich eigentlich gern den Offline-Cache nutzen.

Leider tritt dieser Fehler aber immer noch auf. Ich habe mir deshalb heute die Zeit genommen, mir das einmal genauer anzuschauen. Ich habe mich gefragt, weshalb manchmal die Meldung erscheint, der Termin sei auf dem Server geändert worden, obwohl er inhaltlich gar nicht verändert wurde.

Ich nehme an, dass für das Anzeigen und Bestätigen einer Erinnerung keine Änderung des Termin nötig ist. Ich wüsste jedenfalls nicht, wozu. Was ist das für eine angebliche Änderung?

Also habe ich einen Testtermin angelegt und exportiert. Sieht so aus:

BEGIN:VEVENT
CREATED:20201114T103521Z
LAST-MODIFIED:20201114T103601Z
DTSTAMP:20201114T103601Z
UID:48702a24-8f16-470f-a5e3-5692981c1b7c
SUMMARY:Test mit Erinnerung
DTSTART;TZID=Europe/Berlin:20201114T120000
DTEND;TZID=Europe/Berlin:20201114T130000
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Mozilla Standardbeschreibung
END:VALARM
END:VEVENT

Dann habe ich die Erinnerung abgewartet, diese geschlossen und den Termin erneut exportiert. Danach sieht er so aus:

BEGIN:VEVENT
CREATED:20201114T103521Z
LAST-MODIFIED:20201114T104510Z
DTSTAMP:20201114T104510Z
UID:48702a24-8f16-470f-a5e3-5692981c1b7c
SUMMARY:Test mit Erinnerung
X-MOZ-LASTACK:20201114T104510Z
DTSTART;TZID=Europe/Berlin:20201114T120000
DTEND;TZID=Europe/Berlin:20201114T130000
TRANSP:OPAQUE
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Mozilla Standardbeschreibung
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE paramet
 er with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT

Man erkennt zunächst, dass er jetzt den Fehlereintrag "X-LIC-ERROR" enthält und dass sich der Time Stamp "LAST-MODIFIED" geändert hat.

Ich vermute (!) nun, dass der X-LIC-Fehler dazu führt, dass der Termin neu geschrieben wird, eben, um diesen Fehlereintrag zu hinterlegen. Damit wird dann auch der Time Stamp aktualisiert.

Lädt man diesen Termin nun erstmals mit einem anderem Profil, das diesen Termin offline gespeichert hat, erkennt Thunderbird, dass der Termin geändert wurde und gibt die entsprechende Meldung aus. Dazu passt auch, dass man diesen Fehler temporär beseitigen kann, wenn man die Caches des Kalenders von Hand löscht.

Soweit zur Theorie. Wenn sie zutreffen sollte, dann wäre der X-LIC-Fehler, ausgelöst im Thunderbird, die Ursache des Übels.

Folglich habe ich nach der vollständigen Fehlermeldung gesucht und habe neben diesem Faden auch diesen Bug gefunden:

https://bugzilla.mozilla.org/show_bug.cgi?id=1560151

Der wiederum verweist auch auf ein Duplicate:

https://bugzilla.mozilla.org/show_bug.cgi?id=1566908

dessen Beschreibung dem Fehlerbild nahe kommt. Es finden sich auch Berichte, wonach sich der gesamte VALARM-Block bei jeder Änderung verdoppelt wird und dann zu mehrfachen Alarmen führt. Das trat bei mir bisher nicht auf.

Lange Erklärung, kurzer Sinn: Wer betroffen ist sollte den genannten Bug im Auge behalten.

Ich weiß leider den genauen Wortlaut der Meldung nicht mehr und bin zu faul, das alles nochmal zu reproduzieren. Es geht darum, dass man bei Terminen mit Erinnerung eben dieses Erinnerungsfenster manchmal nicht einfach schließen kann. Es kommt eine Meldung, die besagt, der Termin sei auf dem Server geändert wurden. Man hat dann sinngemäß die Optionen, die vermeintlichen Änderungen zu verwerfen und neu zu laden oder trotzdem zu übertragen.

Ich habe mich schon immer gefragt, was das für einen Änderung sein sollte, denn der Inhalt des Termins wurde definitiv nicht verändert. Bisher hatte ich mir das aber noch nie genauer angeschaut.

Nun denke ich, die Ursache liegt in dem genannten Bug und hege die Hoffnung, dass dieser irgendwann einmal gefixt wird. Ich kann nicht abschätzen, wie kompliziert das ist. Jedenfalls sieht es so aus, als würde der Parser im Thunderbird irrtümlich einen Fehler in der ics-Syntax des Alarms entdecken und das dann im Termin vermerken.

Ja, kann man. Man kann dort auch voten.

(Blöd wäre allerdings, wenn sich meine Theorie am Ende als falsch erwiese.)

Weil dieses Thema gestern erneut in einem anderen Beitrag hochkam, bin ich wieder über meine Theorie hier gestolpert.

Ich denke, sie kann so nicht ganz stimmen. Warum? Wenn man eine Erinnerung bestätigt, dann wird die Uhrzeit der Bestätigung in X-MOZ-LASTACK hinterlegt. (Das X-MOZ zeigt, dies ist kein Standardfeld, sondern nur für Thunderbird von Interesse.)

Das bedeutet, der Timestamp wird in jedem Fall geändert, auch wenn der X-LIC-Fehler nicht auftritt. Die Änderung des Timestamps allein kann also nicht die Ursache sein.

In dem Wert von X-MOZ-LASTACK steckt keine Benutzer-ID, nur eine Uhrzeit. Das führt zu einer Frage, die vielleicht einer der Kalenderexperten hier beantworten kann.

Man denke an einen Teamkalender. Angenommen, ein Benutzer bestätigt eine Terminerinnerung. Wenn der Thunderbird sich das auf dem Server merkt, wie erhält dann ein zweiter Benutzer desselben Kalenders, der ebenfalls Thunderbird benutzt, seine Erinnerung? Dessen Thunderbird liest ja vom Server: wurde bereits "acknowleded".

Meiner Meinung nach gehören solche Informationen ausschließlich lokal bei jedem einzelnen Benutzer gespeichert. Vielleicht liegt dort der Fehler, dass X-MOZ-LASTACK wie auch der X-LIC eigentlich gar nicht in das Event auf dem Server eingetragen werden sollen, sondern nur lokal?

Andere Clients, z.B. auch der auf meinem Smartphone verfahren so. Der hinterlässt keinen Eintrag auf dem Server. Überhaupt, wenn jeder Client, jede App und jeder Benutzer die Bestätigung auf dem Server eintragen würde, dann würden sich die Events aufblähen ohne Ende.

Vielleicht ist das also ein Erbe aus einer Zeit, in der Kalender nur lokal gespeichert wurden.

Ganz nebenbei, der von mir oben angeführte Bug ist inwischen als gefixt markiert. Bei mir trat das Problem auch schon länger nicht mehr auf. Bei anderen anscheinend schon, auch mit der 91.

Zitat von Susi to visit

Bei mir trat das Problem auch schon länger nicht mehr auf. Bei anderen anscheinend schon, auch mit der 91.

Das hätte ich vielleicht nicht schreiben sollen. Die durchaus bittere Enttäuschung ließ nicht lange auf sich warten. Es ist zum Mäusmelken!

Heute habe ich wegen des jüngsten Patchdays nach längerer Zeit mal wieder Windows angebootet und dort auch den Thunderbird aktualisiert. Prompt traten (noch mit der 91.5. und auch mit der 91.6) die Probleme mit den Erinnerungen auf. In beiderlei Gestalt: Fenster "Termin wurde auf dem Server geändert" wie auch in der Form, dass sich dieses Fenster partout nicht schließen ließ.

Kurze Rückfrage in der Familie: Einige Familienmitglieder haben schon längst aufgegeben. Sie verzichten entweder auf die Offline-Unterstützung oder - das betrifft die Fraktion Smartphone - sie nehmen den Kalender des Thunderbird gar nicht mehr her. Kein Wunder, dass es schon länger keine Beschwerden mehr gab.

Das Problem scheint tatsächlich ein schwieriges zu sein. Meine Behelfslösung war bisher auch die, die Offline-Unterstützung zu deaktivieren und von Zeit zu Zeit mal zu schauen, ob es nun auch mit funktioniert. Bei einem nicht-mobilen Gerät ist das kein Beinbruch.

Momentan bin ich trotzdem ziemlich gefrustet und enttäuscht, weil man das immer noch nicht in den Griff bekommen hat. Dabei ist das Teilen von Kalendern doch nun wirklich auch im kleinsten Dorf angekommen. Wir sind doch nicht mehr in den 90ern.

Kein anderes mir bekanntes Kalenderprogramm zeigt diesen Fehler - der Windows-Kalender nicht, Evolution und Co. nicht und auch keine der verschiedenen Apps auf den Smartphones.

Also, es bleibt wohl dabei: Wer Kalender auf mehreren Geräten verwendet und auf dieses Problem stößt, sollte die Offline-Unterstützung deaktivieren.

Ich für meinen Teil werde mich meinen Lieben anschließen und die Kalender vorläufig nicht mehr über den Thunderbird verwalten. Mir wird das jetzt wirklich zu dumm.