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
Alles anzeigen
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
Alles anzeigen
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.