Nextcloud und Thunderbird, zufällige (?) Termine fehlen in TB

Thunderbird-Versionen: 128.4.3, 128.5.0; Problem existierte aber auch schon in 115.x
Betriebssysteme: Sowohl MacOS, als auch Win10, als auch Linux Manjaro
Nextcloud-Kalender mit CalDAV in TB eingebunden
NC-Version: Nextcloud Hub 8 (29.0.9)
NC-Kalender-App: Version 4.7.16

Ich nutze mit meinen Kolleg*innen ein System aus NC-Kalendern, die mittels CalDAV in TB eingebunden sind. Es gibt einen Hauptkalender, der mit ca. 6–10 Terminen pro Tag gefüttert ist. Die restlichen Kalender haben weniger Termine. Die Termineintragungen erfolgen alle über TB von zwei NC-Benutzern aus, nicht über das NC-Interface. Die Kalender sind jeden Tag in Benutzung, es erfolgen täglich bestimmt ca. 20–30 Änderungen in den unterschiedlichen Kalendern. Um die Last zu reduzieren haben wir immer nur ca. 2 Jahre lang Termine im Kalender, d.h. alle Termine die länger als 2 Jahre her sind sind in einen Archivkalender gewandert und nicht mehr im aktiv abonnierten Kalender zu sehen.

Problembeschreibung:

Einzelne Termine verschwinden ohne Vorwarnung und auch für mich bisher ohne erkennbares System aus TB, bisher ausschließlich im Hauptkalender. In der NC sind sie hingegen noch zu sehen. Wenn sie verschwinden, dann anscheinend in allen TB-Instanzen und Versionen, die wir nutzen. Wir greifen auf die Kalender mit unterschiedlichen NC-Benutzerkonten zu – überall fehlen dann diese Termine, ebenfalls unabhängig vom Betriebssystem oder der TB-Version. In anderen Apps/Programmen, die mit CalDAV arbeiten (z.B. Android Kalender über DAVx⁵) werden die Termine korrekt angezeigt und fehlen nicht.

Bisherige Ansätze, die nicht erfolgreich waren:

• TB neu synchronisieren -> hilft nix, eben so Kalender aus TB löschen und neu hinzufügen
• TB Kalender Cache leeren -> hilft nix
• hat auch nichts mit diesem Offline-Support-Fehler zu tun, der existiert; in unseren Kalendern ist überall Offline-Support deaktiviert
• Betterbird nutzen -> kein Unterschied, gleiche Termine fehlen
• Sind es Termine, die von einem bestimmten NC-Nutzer angelegt wurden? Nein, egal von welchem Benutzer, verschwinden einzelne Termine
• Sind es Termine, die alle in einem bestimmten Zeitraum angelegt wurden oder einen bestimmten Zeitraum betreffen? Nein, weder noch.
• Termin in der NC ändern (z.B. Beschreibung oder Ort ändern) -> Nach Synchronisation wird der Termin, oh Wunder, in TB angezeigt. Allerdings nur bis zu einem Neustart von TB, dann ist er wieder weg.
• Termin in der NC manuell neu anlegen und Daten aus "verschwundenem" Termin dort eintragen -> Termin wird in TB zuverlässig angezeigt.
• Vergleich der ICS vom "verschwundenen" vs erscheinenden Termin: Keine augenscheinlichen Unterschiede, bis auf die Zeile "X-MOZ-GENERATION". Hier zeichnet sich aber kein Muster ab, ob bei einer bestimmten X-MOZ-GENERATION die Termine erscheinen oder verschwinden. Sonst sind die ICS-Dateien nahezu identisch.

Das bringt mich zu der Vermutung, dass es gar nicht an der NC liegt sondern daran, wie TB Termine verarbeitet. Ggf. irgendetwas mit dem Puffer? Ich hatte auch mal versucht diesen Bugreport hier zu verstehen, der wiederum auf den TB-Bug hier verlinkt.. aber auch diese scheinen nicht eine Lösung zu haben, bzw spielen sich NC und TB den Ball hin und her? Oder kann mich hier jemand erleuchten?

Ich wende mich mit der Bitte um Ideen an die TB-Community, da das was mir logisch erschien zu prüfen, gar keinen Effekt hatte... Letztendlich können wir so mit TB nicht arbeiten, da die Terminanzeige nicht zuverlässig ist. Vielen Dank!

Zitat von ggbsde

Hast du den Workaround aus dem Bugreport probiert? https://bugzilla.mozilla.org/show_bug.cgi?id=1795720#c16

Vielleicht lohnt sich auch ein Blick in die Fehler-Konsole?

Da ich den Offline-Support ja standardmäßig deaktiviert habe, ändert das An- und Ausschalten vom Offline-Support leider nichts.

Worauf müsste ich in der Fehlerkonsole achten? Ich habe die bisher noch fast nie benutzt. Kann ich dort direkt zu einem bestimmten Termin/Tag schauen, ob Fehler angezeigt werden?

Danke für den Hinweis. Ich hänge mal den Screenshot der zwei Fehlerkonsolen an: oben und hell Thunderbird 128.4.3, unten und dunkel Betterbird 115.15.0. Da der Fehler ja bei beiden Programmen auftritt, dachte ich könnte man es dadurch herausfinden, was bei beiden in der Fehlerkonsole angezeigt wird. Es wird zwar kein Fehler mit "calender" o.Ä. angezeigt, aber es gibt zumindest einen Fehler der gleich ist: XML Parsing Error: not well-formed Location: moz-nullprincipal:{d79cca11-0cd4-4bbe-826d-38f4beafcb08} Line Number 36475, Column 7

Ich kann nur überhaupt nicht einschätzen, was das für ein Fehler ist und ob er irgendwelche Auswirkungen auf den Kalender haben könnte.

Zitat von ggbsde

Vielleicht bringt es auch was, in den erweiterten Einstellungen 'calendar.baseview loglevel' auf 'All' zu setzen.

Habe ich gemacht, in der Fehlerkonsole wird nichts anderes angezeigt als wie auf den Screenshots zu sehen ist.

Zitat von ggbsde

Als erstes könntest du mal auf TB128.5 updaten. Dort ist ein Fehler mit dem Komprimieren beseitigt worden.

Hallo nochmal! Danke für die ganzen wertvollen Tipps. Für mein Manjaro Linux ist 128.5 noch nicht in den Paketquellen angekommen. Ich habe jetzt Nebenbei Betterbird 128.5 installiert, aber das macht leider auch keinen Unterschied.

Zitat

Das ist interessant. Das sind keine Zeilennummern aus Thunderbird, denn dann müßten sie verschieden sein. Kann es sein, das deine Kalender tatsächlich über 30000 Zeilen enthalten? Gibt doch mal die Adresse deines Kalenders in den Webbrowser ein, vielleicht kannst du die Datei dann runterladen und nachschauen. Alternativ in NC exportieren, obwohl das nicht unbedingt dasselbe Ergebnis liefern muß. Aber letztere Datei könntest du mal versuchen in TB zu importieren.

Wenn ich die reine NC-Caldav-Adresse vom Hauptkalender im Browser eingebe, kann ich nicht drauf zugreifen. Ich kann nur die ICS downloaden und ja die hat weit über 30.000 Zeilen. Ich habe in den entsprechenden Zeilen geschaut -> das war mitten in der Beschreibung eines bestimmten Termins. Ich habe diesen Termin einfach geändert und die Beschreibung gelöscht. Der Fehler taucht aber weiterhin auf, nur mit geringfügig veränderter Zeilenangabe, diesmal auf einen komplett anderen Termin bezogen.
Ich habe nach und nach andere Kalender abbestellt und immer überprüft, ob der Fehler weiterhin auftaucht – es scheint tatsächlich an diesem Hauptkalender zu liegen. Sobald der nicht mehr abonniert ist, taucht der Fehler in der Konsole nicht mehr auf. Ich glaube aber nicht, dass es an einem konkreten Termin liegt, dafür ist mir noch etwas anderes aufgefallen:

Ich archiviere jedes Jahr die Termine des Hauptkalender des Vorvorjahres in einen separaten Archivkalender, zur Entlastung wie oben schon beschrieben. Das ganze mache ich über TB: Alle Termine eines Monats im Hauptkalender markieren, kopieren, im Archivkalender einfügen, dann im Hauptkalender löschen. Aber auch hier lädt TB anscheinend nie ALLE Termine des Hauptkalenders, es fehlen immer vereinzelte, die nicht geladen werden. Nach der Archivierung eines Monats schaue ich nämlich im NC-Interface und entdecke vereinzelte Termine, die noch im Hauptkalender rumschwirren, die von TB nicht gesehen wurden. Schließe ich TB und öffne es neu, lass die Kalender neu laden, findet TB wieder vereinzelte Termine in den sonst schon archivierten Monaten im Hauptkalender und zeigt sie mir an.
Das Spiel, diese dann auch in den Archivkalender zu übertragen, kann ich mehrere Male wiederholen – es ist keine Garantie dass TB nach Schließen und wieder Öffnen tatsächlich alle bisher fehlenden Termine aus den sonst schon bereinigten Monaten findet. Es tauchen immer mal wieder welche auf, teilweise auch aus schon längst vergangenen Jahren, die ich vor 1 oder 2 Jahren archiviert habe. In der NC sieht man hingegen gleich, welche Termine TB nicht gesehen hat. Dort werden sie zuverlässig noch im Hauptkalender angezeigt.

Ich verstehe nicht, nach welchem System TB Termine lädt/nachlädt und wie TB "entscheidet", welche Termine es gerade nicht lädt aber vllt nach dem nächsten Start. Das macht es extrem unzuverlässig. Wie landen Termine von CalDAV in TB – gibt es eine Art Zwischenspeicher (nicht Offline-Support), der hier spinnt?

Vielen vielen Dank schon mal fürs Mitdenken und für die Hinweise! Vllt kommen wir dem Problem ja doch noch auf die Schliche.

Hallo und vielen Dank für die ganzen Hinweise und Ideen. Ich hatte heute ein bisschen Zeit auszuprobieren aber habe noch nicht alles geschafft. Nur soweit: Die UID finde ich tatsächlich interessanter Weise nicht in der ICS. Eigentlich wäre das ja logisch, aber weder in kompletter Form noch in Bestandteilen ist sie in der ICS-Datei zu finden. Ich glaube aber, die UID ändert sich auch bei jedem Start von TB. Das überprüfe ich nochmal.

Die Netzwerkanalyse nehme ich mir die kommenden Tage nochmal in Ruhe vor und melde mich dann dazu.

Hallo nochmal,

folgendes konnte ich herausfinden:

1.) Die Adresse/UID die in der Konsole beim Fehler angegeben wird, ändert sich bei jedem Start von TB, die Zeilen- und Spaltennummer bleiben hingegen gleich. Die Adresse lässt sich nirgends wiederfinden bisher. Nicht in der ICS und auch nicht wenn ich sonst im Entwickler-Werkzeugkasten danach suche. Man kann ja theoretisch auch drauf klicken, aber das führt auch ins Nichts.

2.) Die Netzwerkanalyse zeigt nach dem Start von TB circa 60-70 Anfragen mit der Methode "REPORT" an. Ca. 40 davon betreffen den problematischen Hauptkalender. In jeder Antwort gibt es ca. 7000-16000 Zeilen. Bei 11 der Reports steht bei der Antwort oben drüber in rot "Antwort wurde gekürzt". Diese sind auch in der Größe wesentlich größer als alle anderen. Im Normalfall sind die Reports um die 400 - 900kB groß. Die mit dem Vermerk "gekürzt" sind oft um die 2,5 MB groß, teils auch bis zu 7 MB. Ich weiß aber nicht, ob nur die Darstellung in der Netzwerkanalyse gekürzt ist oder tatsächlich bei diesen Reports nicht die ganze XML geladen wird? Angezeigt wird nur bis ca rund um Zeile 13000, aber die Größe selbst liegt ja trotzdem bei mehreren MB. Diese "gekürzten" und großen Reports tauchen random zwischen den anderen auf. Tatsächlich erscheinen gekürzte Reports auch vereinzelt in den anderen Kalendern, wobei uns da noch nicht aufgefallen wäre, dass Termine fehlen.

Was allerdings bei den großen Reports auffällt ist, dass die Termine meist in der Beschreibung sehr umfangreich sind. Ich kann auch grob nachvollziehen, dass anscheinend teilweise in die Beschreibung der Termine einfach Mailtexte kopiert und eingefügt wurden, inkl Formatierung, manchmal auch mit Signatur-Bildern (ohne dass diese in TB in der Beschreibung angezeigt werden). Aber in der ICS sieht man, dass sie dennoch im Hintergrund abgespeichert wurden. Das zieht in der ICS ellenlange Zeichenketten nach sich.

3.) Ich habe mir ein paar der XML-Antworten (nicht alle 40) mal durch so einen XML Check gejagt, da wurden keine Fehler angezeigt.

Weiß das jemand, ob bei "Antwort gekürzt" in der Netzwerkanalyse dann tatsächlich das Laden abgebrochen wird? Und ich frage mich auch, nach welchen Kriterien TB einen Report beendet und einen neuen anfängt? Immer nach einer bestimmten Anzahl von Events? Und wenn dann aber ein Event wegen einer zu großen Beschreibung den Rahmen sprengt... haben wir den Salat? Oder denke ich in eine falsche Richtung?

Wenn es Screenshots von irgendwas braucht, gerne Bescheid geben. Ich bin weiterhin dankbar für alle Ideen und Lösungsvorschläge. Danke ggbsde für die unglaublich hilfreichen Ansätze!

Hallo nochmal,

wenn ich versuche den Hauptkalender als ICS wieder in TB zu importieren, frisst das Programm noch bevor ich den Import abschließen kann, nach einigen Minuten 100% meines 32GB Arbeitsspeichers und kommt aber zu nichts. Ich habe es mehrfach probiert und dann wieder abbrechen müssen. :-/ Die ICS ist derzeit 15 MB groß.

Im Endeffekt kann ich den Abgleich aber auch über die NC machen: Ich sehe ziemlich genau, welche Termine fehlen, wenn ich mich in NC und TB parallel durch den Kalender klicke. Allerdings haben diese fehlenden Termine keine Besonderheiten. Es sind oft sogar Termine, die als Kopie auch noch an 10 anderen Stellen im Kalender existieren, mit exakt dem gleichen Inhalt, identisch in der ICS bis auf das Datum. Es gibt keinerlei Grund, warum diese Termine fehlen, wenn sie an anderer Stelle doch genau so auch existieren.

Daher ja meine Vermutung, dass es gar nicht an diesen Terminen konkret liegt sondern daran, dass ein Prozess schon beim Laden unterbrochen wird und diese Termine gar nicht erst bei TB landen.

-

Ich habe außerdem folgendes versucht: Mir ist ja aufgefallen, dass einige Termine in der Beschreibung extrem umfangreich sind, weil bspw Mailtexte inkl. aller HTML-Formatierung, Signaturen etc. reinkopiert wurden. Ich habe versucht alle diese Termine zu identifizieren (anhand der Netzwerkanalyse immer dort wo in den Reports Größen von mehreren MB angegeben wurden) und die Beschreibungen in der NC als Plain Text einzufügen, ohne Formatierung. Das hat die ICS wesentlich verkleinert (von 50MB auf 15MB). In der Netzwerkanalyse sind jetzt alle Reports kleiner als 1MB und auch nicht mehr "gekürzt". Die Termine fehlen dennoch. Der XML-Verarbeitungsfehler wird weiterhin angezeigt, jedoch mittlerweile in Zeile 2718.. hm...

-

Da ich irgendwie nicht rausfinden kann, was es ist, was den Fehler verursacht, habe ich jetzt überlegt doch den Kalender neu aufzusetzen ab 2025 und Stück für Stück die bestehenden Termine zu kopieren, Beschreibungen gleich präventiv als Plain Text einzufügen, und immer wieder zu checken, wann und ob der Fehler wieder in der Konsole angezeigt wird. Ggf bekomme ich da ja nochmal etwas raus. Eine andere Idee habe ich derzeit sonst nicht.

Hallo nochmal, ich habe gestern Abend tatsächlich noch den Fehler gefunden:

In einem Termin in der Beschreibung war (vermutlich durch Copy & Paste aus einer Mail, wieso auch immer das dort überhaupt war) ein Steuerzeichen (u13) mit eingefügt worden. Daran hat sich TB dann aufgehängt.

Falls jemand anderes auch über solch einen Fehler stolpert (oder ich in 5 Jahren nochmal), hier nochmal Schritt für Schritt, wie ich es am Ende gefunden habe:

1. Thunderbird mit "Thunderbird -devtools" gestartet, Netzwerkanalyse und Fehlerkonsole parallel geöffnet.
2. Beobachtet, wann in der Fehlerkonsole der XML-Fehler auftaucht und die bis dorthin geladenen Reports durch einen XML-Validator gejagt. Die Zeile des Fehlers im XML-Validator stimmte auch mit der ausgegebenen Zeile in der Fehlerkonsole überein. Hier findet sich das Steuerzeichen.
3. Im Report nach dem fehlerhaften Termin weiter gescrollt und überprüft, ob folgende Termine tatsächlich die sind, die TB nicht anzeigt -> Ja sind sie, d.h. TB hört nach dem Steuerzeichen auf zu laden.
4. Den dazugehörigen Termin rausgesucht. Dieser wurde aber weder in TB noch in der Nextcloud angezeigt, da auch die NC anscheinend über das Steuerzeichen gestolpert ist und ihn nicht laden konnte. In der ICS war der Termin aber eindeutig vorhanden.
5. Nach einer anderen Kalender-Software (App/Programm...) gesucht, mit dem ich den CalDAV Kalender verbinde, die den Termin laden kann, damit ich ihn löschen/verändern kann. NC-Interface: Lädt den Termin nicht. Mac Kalender -> Lädt nicht und zeigt ebenfalls Fehler an; GNOME Kalender -> Lädt!
6. Den fehlerhaften Termin über GNOME Kalender gelöscht.
7. TB lädt alle Termine Braucht zwar lange und hakelt dabei, aber das ist ja seit 128er-Version bei mir sowieso ein neues Phänomen leider.

Vielen Dank ggbsde für die zum Ziel führenden Hinweise zur Konsole, Netzwerkanalyse und XML-Validation. Es erklärt ja jetzt auch, warum andere Kalender-Apps die fehlenden Termine geladen haben, da sie ja wahrscheinlich die Termine in ganz anderen Blöcken von der NC abrufen und ggf zwar über den einen fehlerhaften gestolpert sind aber deshalb nicht gleich alle folgenden blockiert haben.

Ich nehme mit: Beim Anlegen von Thunderbird-Terminen und Kopieren von Infos in das Beschreibungs-Feld vorsichtshalber immer ohne Formatierung einfügen.