Thunderbird hängt sich beim Start auf (neues Testprofil funktioniert)

Hallo Susanne,

klasse & danke, dass Du weiter dabei bist .

Wir haben schließlich doch noch eine local.sqlite mit einigermaßen vollständigen Daten gefunden (trotz angesichts auch schon 33 MB vermutlich bereits defekt - nur noch nicht so ausgeprägt - und zwar bereits länger als mindestens Ende Oktober 2020), so dass ich mittels Export (DB Browser SQLite) in csv-Dateien und etwas Aufbereitung in Excel für Sophia, zumindest die sonst schwerlich erinnerbaren Informationen noch mal sicht-, filter- und sortierbar machen konnte. Sie erstellt die Einträge in einem neuen Kalender nun neu. Das ist nüchtern betrachtet wohl die weniger aufwändige Lösung.

Thunderbird läuft jetzt in der Version 78.6.0 64-Bit und mit deaktivierter Updateautomatik bei der Threaderstellerin.

Dankeschön auch für die Info zum Epoch- bzw. Unix-Timestamp . Meine Suche dazu im Kontext Thunderbird war erst nicht sehr ergiebig und als ich die Timestamps aus der local.sqlite dann auch mit Hilfe einiger Konverter-Websites nicht lesbar bekam, dazu noch etwas von 13-stellig las (entgegen den 16-stelligen Werten in local.sqlite), kam ich zunächst nicht weiter.

Aber dann fand sich doch noch eine Seite, die das auflöste. Es ist also ein Timestamp in Microsekunden seit 01.01.1970 00:00. Entweder Integer oder Float. Ich kann Deine Formel für LibreOffice Calc noch mit einer für MS Excel ergänzen, falls das mal jemand damit nutzen möchte:

=DATUM(1970;1;1)+(LINKS(A1;10)/86400)

(Die ersten 10 Stellen genügen, die folgenden 3 Stellen entsprechen den Millisekunden.)

Fachlich bin ich hinsichtlich der Datenstrukturen weiter neugierig, wie die Datenbank funktionieren soll. Um mir ein paar Zusammenhänge zu erklären, hatte ich schon mangels Doku begonnen, quasi revers in Thunderbird Termine und Aufgaben anzulegen, um deren Abbildung in den Daten nachzuvollziehen. Da gibt es zum Beispiel die Spalte 'flags' in 'cal_events', deren Inhalte sich aber nicht so 1-2-3 auf dem Weg nachvollziehen lassen. Aufgrund der dazu erstellten 'Items' kann ich bis jetzt aber schon vermuten, dass nicht immer Verknüpfungen in andere Tabelle bestehen müssen.

Den Gedanken, ob man nicht durch Leerung der Tabelle cal_alarms das Desaster einfangen könnte, finde ich ganz interessant. Vorher müsste man aber noch wissen, wie die Tabelle cal_recurrence damit zusammenhängt und es bliebe ja auch noch, die Tabelle cal_todos auf die echten Einträge zurückzufahren, wo ohne weiteres nicht klar ist, wie man die identifizieren kann (bei fast 39.000 Einträgen in der defekten local.sqlite) und wie besagte Spalte flags geändert werden muss, damit die Logik wieder passt.

Du hattest in der inzwischen gelöschten Antwort noch gefragt, ob diese 6 Zeilen in meiner prefs.js vorhanden sind: nein, sind auch nicht da.

In Punkto Kalender / Aufgaben mit Wiederholungen und Erinnerungen ist aber irgendwas in Thunderbird nicht erst mit der 78.6.1 im Argen. In den letzten Wochen sind diverse Hilfesuchende hier ins Forum gekommen, die das so oder so ähnlich auch feststellen mussten:

Speicherung eines einzelnen Wiederholungstermins (wournaje)

TB bleibt nach Mausklick stecken ("keine Rückmeldung" + vergrauter Bildschirm) - trotz Neuinstallation (omega99)

Aufgaben lassen sich nicht erledigen (Jochen Lengler, feuerfuchs7, heinzenzo, TBatPC, Blitzebub, HomerB)

Vervielfältigte Termineinträge in Kalendervorausschau "Demnächst (7 Tage)" (ByteRyder)

ByteRyder stellt hier die These auf, dass es erst mit dem Wechsel zur 78er-Linie bei ihm zu den Problemen gekommen ist; das schreibt er im November '20 für 78.4.0; ich kann das mit den bei Sophia gesehenen Daten nur eindrücklich bestätigen)

Offline-Unterstützung funktioniert mit 78.6.1 nicht mehr korrekt (HoFri)

TB 78.6.1 erinnert ständig an erledigte oder veschobene Termine/Aufgaben (ColaFan)

Das sind, soweit ich das überschlägig eben nachgeschaut habe, alles Anwender, die Probleme mit Kalender + Aufgaben und Erinnerungen sowie Wiederholungen bei alleiniger Nutzung des Kalenders ohne CalDAV / Add-ons / Sync haben.

Gruß

Sehvornix

Zitat von Sehvornix

Sie erstellt die Einträge in einem neuen Kalender nun neu. Das ist nüchtern betrachtet wohl die weniger aufwändige Lösung.

Das kann tatsächlich gut so sein, wenn die Anzahl der Einträge noch handhabbar ist.

Zitat von Sehvornix

Um mir ein paar Zusammenhänge zu erklären, hatte ich schon mangels Doku begonnen, quasi revers in Thunderbird Termine und Aufgaben anzulegen, um deren Abbildung in den Daten nachzuvollziehen.

Ja, das habe ich so ähnlich gemacht. Eine Doku habe ich auch nicht gefunden. Damit hätte sich gut Zeit sparen lassen. Sehr schade.

Zitat von Sehvornix

In Punkto Kalender / Aufgaben mit Wiederholungen und Erinnerungen ist aber irgendwas in Thunderbird nicht erst mit der 78.6.1 im Argen.

Ganz gewiss. Die Probleme begannen auch nach meiner Wahrnehmung nicht erst mit der 78.6.1. sondern deutlich früher mit der 78. Kleinere Holperer schon in der 68. Ich gehe deshalb sehr davon aus, dass die Linux-Distris vorerst weiterhin auf der 68 bleiben werden.

Zitat von Sehvornix

sowie Wiederholungen bei alleiniger Nutzung des Kalenders ohne CalDAV / Add-ons / Sync haben

Meine Kalender sind sämtlich CalDAV-Kalender. Kleinere Probleme konnte ich reproduzieren, aber schwere Probleme habe ich damit auch mit der 78 (Windows) bisher nicht beobachten können. Allerdings nutze ich sie selten.

Hallo erst einmal !

Im Zuge einer Disaster Recovery einer local.sqlite (Thunderbird läßt sich nur noch abschießen)

Sind bei mir einige SQL-Skripte entstanden, um mit den Daten in der local.sqlite zu arbeiten:

"Normale Zeitanzeige"

Die Zeiten in der local.sqlite werden als Mikrosekunden vom 01.01.1970 00.00 Uhr in der jeweiligen Zeitzone gespeichert.

SELECT cal_id,id, datetime(round(time_created/1000000),'unixepoch') FROM cal_events
WHERE id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');

So sieht eine Beispielausagbe von Zeiten aus der Tabelle cal_events

d5ae769c-7624-4a65-8f90-c1ba5e69b7a2    01eda322-86e0-47f7-979a-45cfc595cd51    2021-02-17 15:30:50
d5ae769c-7624-4a65-8f90-c1ba5e69b7a2    07201874-e644-4e46-ac2d-526421623cfc    2021-02-17 15:30:50

Kalender trennen /zusammen führen

In diesem Zusammenhang ist die cal_id von Bedeutung.

Wie komme ich an sie ?

In der pref.js wird der Zusammenhang zwischen cal_id und Kalendernamen hergestellt.

calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.cache.enabled", false);
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.calendar-main-in-composite", true);
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.color", "#804000");
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.disabled", false);
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.imip.identity.key", "");
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.name", "Müllabfuhr");
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.readOnly", false);
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.suppressAlarms", false);
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.type", "storage");
user_pref("calendar.registry.d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.uri", "moz-storage-calendar://");

d5ae769c-7624-4a65-8f90-c1ba5e69b7a2.name", "Müllabfuhr");
           cal_id                            Kalendername

Warum sollte man das machen ? zb. um die Termine im neuen Kalender als *.ics zuexportieren

Alle Termine mit dem Titel "Bioabfall" werden in den "Müllabfuhr"-Kalender überführt.

UPDATE cal_alarms
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_attachments
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_attendees
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_metadata
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_properties
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_recurrence
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_relations
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE item_id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');
UPDATE cal_events
SET cal_id ='d5ae769c-7624-4a65-8f90-c1ba5e69b7a2'
WHERE id IN (SELECT id FROM cal_events WHERE cal_events.title LIKE 'Bioabfall');

Beim Schreiben dieser Zeilen ist mir eingefallen mal in die Sourcen zu schauen (sind 2,8 GB) grep sei DANK !

Hier ist die Frage nach den Flags aufgeworfen worden:

// Storage flags. These are used in the Database |flags| column to give
// information about the item's features. For example, if the item has
// attachments, the HAS_ATTACHMENTS flag is added to the flags column.
var CAL_ITEM_FLAG = {
  PRIVATE: 1,
  HAS_ATTENDEES: 2,
  HAS_PROPERTIES: 4,
  EVENT_ALLDAY: 8,
  HAS_RECURRENCE: 16,
  HAS_EXCEPTIONS: 32,
  HAS_ATTACHMENTS: 64,
  HAS_RELATIONS: 128,
  HAS_ALARMS: 256,
  RECURRENCE_ID_ALLDAY: 512,
};

Das ergibt nochmal ganz Abfragemöglichkeiten !

Das Verzeichnis thunderbird-78.7.1/comm/calendar ist nur 7,2 MB groß.

grep Aufrufe der Form

 grep -rn  -A 3 -B 3 "INSERT" * ODER  grep -rn  -A 3 -B 3 "SELECT" *  ODER  grep -rn  -A 3 -B 3 "UPDATE" *

sind sehr interressant.

Desweiteren ist ein SQL-Skript entstanden um Wiederholungstermine zu kopieren:

ATTACH "C:\Users\tom\Kalender\Kalender\Rettung.sqlite" AS rettung; 
INSERT INTO rettung.cal_alarms
SELECT cal_alarms.cal_id,cal_alarms.item_id,cal_alarms.recurrence_id,cal_alarms.recurrence_id_tz,cal_alarms.icalString
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_alarms ON cal_events.id = cal_alarms.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_attachments
SELECT cal_attachments.item_id,cal_attachments.cal_id,cal_attachments.recurrence_id,
cal_attachments.recurrence_id_tz,cal_attachments.icalString
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_attachments ON cal_events.id = cal_attachments.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_attendees
SELECT cal_attendees.item_id,cal_attendees.recurrence_id,cal_attendees.recurrence_id_tz,cal_attendees.cal_id,cal_attendees.icalString
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_attendees ON cal_events.id = cal_attendees.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_events
SELECT cal_events.cal_id,cal_events.id,cal_events.time_created,cal_events.last_modified,cal_events.title,cal_events.priority,cal_events.privacy,cal_events.ical_status,cal_events.flags,
cal_events.event_start,cal_events.event_end,cal_events.event_stamp,cal_events.event_start_tz,cal_events.event_end_tz,cal_events.recurrence_id,cal_events.recurrence_id_tz,cal_events.alarm_last_ack,
cal_events.offline_journal
 
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_metadata
SELECT cal_metadata.cal_id,cal_metadata.item_id,cal_metadata.value
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_metadata ON cal_events.id = cal_metadata.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_properties
SELECT cal_properties.item_id,cal_properties.key,cal_properties.value,cal_properties.recurrence_id,
cal_properties.recurrence_id_tz,cal_properties.cal_id
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_properties ON cal_events.id = cal_properties.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_recurrence
SELECT cal_recurrence.item_id,cal_recurrence.cal_id,cal_recurrence.icalString
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_relations
SELECT cal_relations.cal_id,cal_relations.item_id,cal_relations.recurrence_id,cal_relations.recurrence_id_tz,
    cal_relations.icalString 
 from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_relations ON cal_events.id = cal_relations.item_id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;

INSERT INTO rettung.cal_todos
SELECT cal_todos.cal_id,cal_todos.id,cal_todos.time_created,cal_todos.last_modified,cal_todos.title,
cal_todos.priority,cal_todos.privacy,cal_todos.ical_status,cal_todos.flags,cal_todos.todo_entry,cal_todos.todo_due,
cal_todos.todo_completed,cal_todos.todo_complete,cal_todos.todo_entry_tz,cal_todos.todo_due_tz,
cal_todos.todo_completed_tz,cal_todos.recurrence_id,cal_todos.recurrence_id_tz,cal_todos.alarm_last_ack,
cal_todos.todo_stamp,cal_todos.offline_journal 
from cal_events 
INNER JOIN cal_recurrence ON cal_events.id = cal_recurrence.item_id
INNER JOIN cal_todos ON cal_events.id = cal_todos.id
WHERE cal_recurrence.icalString IS NOT NULL
group by cal_events.id;
DETACH DATABASE 'rettung';

Die Abfrage aus den Quellen sieht so aus

  this.mSelectEventsWithRecurrence = this.mDB.createAsyncStatement(
providers/storage/CalStorageCalendar.jsm:1131:        "SELECT * FROM cal_events " +
providers/storage/CalStorageCalendar.jsm-1132-          " WHERE flags & 16 == 16 " +
providers/storage/CalStorageCalendar.jsm-1133-          "   AND cal_id = :cal_id AND recurrence_id is NULL"
providers/storage/CalStorageCalendar.jsm-1134-      );

Die Wiederholungstermine müssen kopiert werden, weil die einzelnen Instanzen des Termin nicht in der DB stehen.

Dann habe ich noch ein SQL-Skript, dass Einzeltermine im Intervall exportiert:

Das Intervall befindet sich in der WHERE-Klausel:

In diesem Fall : Event_Start 1.März 2021 Event_start 1 APRIL

Gruss
thomas

Hallo Tom,

vielen Dank für die umfangreiche Bereitstellung Deiner Scripte und Informationen, sogar inklusive Quelle! Klasse.

Bei der Thread-Erstellerin ist das Problem mit dem Kalender nur bedingt gebannt. Zwar konnten wir alle Termine und Aufgaben wieder sichtbar machen und das wurde dazu genutzt, einen komplett neuen Kalender aufzubauen, aber die Nachschau hat zwischenzeitlich auch schon wieder gezeigt, dass weiterhin etwas im Code für Kalender und Aufgaben Amok läuft. Soll heißen, es findet nach wie vor ein unerklärlicher Aufwachs von Einträgen in der Datenbank statt. Das ist in einem so frühen Stadium jetzt nur noch nicht wirklich spürbar. Soll heißen, letzte Woche waren es durchaus schon dutzende, aber eben auch noch weit entfernt von >30.000.

Bei irgendeiner Gelegenheit im Zusammenhang mit dem Verschieben eines Eintrags könnte sich dass dann möglicherweise wieder wie schon einmal erlebt, auswirken. Unzählige bereits erledigte Einträge werden reaktiviert und fluten die GUI mit Erinnerungsmeldungen. Das sind dann auch wieder nicht nur die eigentlichen Einträge, sondern ein vielfaches davon durch die interne Vervielfachung der Einträge. Dann verlangsamt sich Thunderbird zunächst spürbar und im Laufe der Zeit massiv um am Ende nach Wochen oder Monaten auch wieder zu crashen, weil Thunderbird die Ressourcen zur Abbildung der ganzen Einträge ausgehen.

Es bleibt zu hoffen, dass das bereits angekündigte Release 78.8.0 mit Fixes in diesem Bereich wirklich noch einiges mehr an Problemen mit Kalender, Aufgaben, Erinnerungen und Wiedervorlagen abräumt.

[Task "Show" filtering broken in 78.6.1 - recurring tasks are all being marked incomplete (Bug 1686466)] Danke an HomerB für den Link zu dem Bug.

Gruß

Sehvornix

Zitat von tom996

In diesem Zusammenhang ist die cal_id von Bedeutung.

Wie komme ich an sie ?

Siehe Link in Beitrag #20.

Zitat von Sehvornix

Soll heißen, es findet nach wie vor ein unerklärlicher Aufwachs von Einträgen in der Datenbank statt.

Ich habe vor einigen Wochen selbst einiges getestet und reproduziert. In Bugzilla kamen eine Reihe aktuelle Bugs zum Kalender hoch. Ich kann mich leider nicht mehr erinnern, was da alles dabei war.

Bei unseren Kalendern tritt dieser Fehler im täglichen Betrieb jedenfalls nicht auf. Dabei greifen mehrere Thunderbirds (68.x wie 78.x), Evolution und mehrere verschiedene Clients auf den Smartphones darauf zu.

Es muss also irgendeinen Trigger geben oder eine bestimmte Voraussetzung, die bei uns nicht zum Tragen kommt.