Kalender-Sync von Sunbird(!) auf Android

Hallo narf,

Zitat von narf2

nun habe ich das mit gmx ausprobiert. sunbird > datei > kalender publizieren.

Das funktioniert nicht. Du kannst dort nicht einfach Dateien ablegen.

Du musst den umgekehrten Weg gehen: Einen existieren Kalender bei GMX in SunBird per CaldDav einbinden. GMX unterstützt CalDav. Ich selbst benutze Ligthning. Damit funktioniert das auch einwandfrei.

Laut den Beschreibungen, die ich im Internet gefunden habe, unterstützt der SunBird ebenfalls CaldDav. Somit sollte es ebenso funktionieren wie mit Lightning.

Der URL für GMX sieht so aus: https://kalender.gmx.net/begenda/dav/Anmeldename/calendar/ . Der Anmeldename und Passwort sind dieselben, die Du auch für den E-Mail-Login benutzt.

Gruß

Susanne

Zitat von narf2

gibt es vielleicht unterschiedliche ics-standards?

Nicht, dass ich wüsste. Der Standard ist in RFC 2446 definiert. Aktuell ist Version 2.

Der Sunbird ist schon sehr alt und wird meines Wissens schon seit 2010 nicht mehr weiterentwickelt. Die letzte Version war die 1.0 beta 1, also nicht einmal ein endgültiges Release. Möglich also, dass es an dem alten Sunbird liegt. Das weiß ich aber nicht.

Näheres kann Dir vielleicht generalsync dazu sagen. Er hat ein Sync-Tool entwickelt und kennt den RFC bestimmt fast auswendig.

Zitat von narf2

oder muss ich die datenbank von sunbird irgendwie reparieren?

Die ics-Dateien sind reine Textdateien. Die kannst Du Dir mit einem Texteditor anschauen. Ein Blick auf die Version könnte sich lohnen. Das sollte etwas so aussehen:

BEGIN:VCALENDAR
   PRODID:irgendwas   
   VERSION:2.0
   BEGIN:VEVENT
   [...]
   END:VEVENT
   weitere events
END:VCALENDAR

Zitat von narf2

der gibt es einfach ein tool, das "beschädigte" ics files prüft und glattbügelt?

Ich kenne keines. Das will aber nichts besagen, denn ich hatte bisher auch noch keinen Bedarf. Eine Idee wäre, den Kalender einmal in den aktuellen Lightning zu im- und exportieren.

Hallo narf,

Zitat von narf2

> 1 MB ,was wohl die grenze bei gmx darstellt.

das scheint ein gut gehütetes Geheimnis zu sein. Auf die Schnelle habe ich dazu jedenfalls nichts finden können. Ich erinnere mich aber, dass hier schon einmal jemand von einem solchen Limit berichtet hat. Das betraf web.de. Somit ist es keine Überraschung, wenn gmx dasselbe Limit setzt.

Abhilfe kannst Du schaffen, indem Du

• die Daten auf mehrere Kalender aufteilst. Das beginnt mit der Trennung beruflich/privat und geht typischerweise weiter mit je einem Kalender für jedes Familienmitglied, einen für Geburtstage, einen für Feiertage und Ferien usw. .
  Das hat ganz nebenbei auch den Vorteil, dass man die einzelnen Kalender in der Anzeige ausblenden kann, um die Übersicht zu verbessern und die Downloadzeit zu verkürzen. Bei großen Kalendern und einer schmalen Verbindung am Smartphone könnte die schon lästig werden. Vom Volumen ganz abgesehen.
  Wir hatte hier auch einen Forenteilnehmer, der den Kalender als Tagebuch benutzt. Dabei kommt natürlich ganz schön was an Bytes zusammen.
  
  GMX erlaubt meines Wissens nur einen Kalender. Einige kostenpflichtige Provider erlauben mehr: Posteo z.B. bis zu 20. Davon sind aber nur die ersten drei im Basistarif enthalten. Jeder weitere kostet 1,20 EUR pro Jahr. Das scheint mir durchaus verkraftbar.
• die Kalender entschlackst, sofern möglich. Der Termin beim Zahnarzt aus 2005 oder der Empfang beim Kini anno 1883 sind vielleicht gar nicht mehr nötig.

Übrigens, danke für den Hinweis. Ich hoste unsere Kalender auf einem eigenen Server. Deren Größe ist jeweils deutlich unter einem Megabyte. Ich habe mir noch gar keine Gedanken gemacht, ob ich jemals an ein Größenlimit stoßen könnte und wie man Altlasten am geschicktesten los wird. Ich weiß z.B. auch nicht, ob die App auf meinem Smartphone irgendwann "Stop" sagt.
Vielleicht sollte ich tatsächlich dazu übergehen, für jedes Jahr neue Kalender anzulegen. Bei den klassischen Papierkalendern und Timesystems ist das ja auch so, und für die Feiertage und Ferien mache ich eh bereits. Ich muss ich mir bei Gelegenheit mal ein paar Gedanken dazu machen.

Gruß

Susanne

Hallo narf,

Zitat von narf2

... ich hatte hier ohnehin noch einen raspberry pi herumliegen. ich baue mir da grade einen kalenderserver mit "radicale" drauf,

Willkommen im Club!

Bevor Du richtig loslegst, noch ein paar Hinweise zum Radicale ... .

Es wird in den nächsten Monaten eine Version 2 geben. Derzeit ist die Version 1.1.1 aktuell. Die neue Version wird nicht mehr datenkompatibel sein Es gibt ein Migrationstool, das aber in komplexen Fällen nach wie vor manuelles Anpassen oder Eingreifen erfordert. Von der Version 2 gibt es bereits einen Release-Kandidaten. Wie gut der schon ist, kann ich nicht beurteilen. Ich bleibe vorerst auf der 1.x, weil ich mir die Migration nicht antun möchte, bevor ich sicher bin, dass die 2.x stabil ist.

In der 1.x. gibt es einen schwierig zu reproduzierenden Bug. Bei einigen Benutzern, so auch bei mir, bleibt der Radicale manchmal hängen. Der Fehler tritt sehr sporadisch auf. Der Radicale läuft manchmal Monate ohne Fehler, dann hängt er plötzlich. Das Gemeine daran ist, dass der Prozess selbst weiterhin läuft. Man merkt es also zunächst nur daran, dass der Sync plötzlich nicht mehr funktioniert.

Der Radicale lässt sich dann auch nicht mehr per stop beenden. Es hilft dann nur noch ein kill oder reboot.

Der Entwickler hatte zunächst eine Race-Condition vermutet und diese gefixt. Das Problem tritt aber trotzdem noch auf.

Mir ist aufgefallen, dass es immer dann, wenn der Radicale hängt, eine noch offene Verbindung Verbindung gibt, die aber längst nicht mehr existiert.

Ein

sudo lsof -c radicale -a -i zeigt so etwas:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
radicale 5734 root 3u IPv4 272791 0t0 TCP *:5232 (LISTEN)

Bei waren das stets Verbindungen zu einem NAT-Client in einer VM. Seit ich den per Netzwerkbrücke ins Netz bringe, habe ich das Problem nicht mehr beobachten können. Das ist aber erst einige Wochen her, kann also Zufall sein. Ich habe mir vorsorglich ein kurzes Script geschrieben, welches den Radicale per Cron neu starten kann (stop, kurze Pause, kill mit Signal 9, kurze Pause, start).

Im Bug hat jemand berichtet, dass er das Problem mit der Version 0.7.1. noch nie gesehen hat. Auch bei mir ging es erst mit der 0.9 oder 1.0 los. Das weiß ich nicht mehr genau.

Falls Du nicht gleich auf die Version 2 gehst, wäre es also u.U. ratsam, auf die 0.7.1 zu gehen.

Gruß

Susanne

Sorry, kleiner copy%paste-Fehler oben.

Wenn alle Verbindungen geschlossen sind, dann liefert lsof wie oben:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
radicale 5734 root 3u IPv4 272791 0t0 TCP *:5232 (LISTEN)

Wenn eine Verbindung geöffnet ist, sieht es so aus:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
radicale 5734 root 4u IPv4 8459 0t0 TCP *:5232 (LISTEN)
radicale 5734 root 5u IPv4 77175 0t0 TCP hostname:52 32->clientname:50102 (ESTABLISHED)

Zitat von narf2

von daher bleibe ich sicher noch eine weile auf version 1.1.2

Die *.2 ist an mir vorbei gegangen. Danke für den Hinweis. In den Release Notes habe ich gefunden, dass CVE-2017-8342 bzw. CB-K17/0768 gefixt wurde. Das betrifft zwar nur Red hat/Fedora, aber es gibt laut der Projektseite auch "various minor fixes", was immer das im Detail auch meint.

Zitat von narf2

dann werd ich, solange noch keine anderen dienste auf dem rpi definiert sind, einfach auch einen regelmäßigen reboot einplanen.

Ich würde es nicht per Reboot lösen sondern per Script, das nur den Radicale beendet bzw. killt. Allein schon der empfindlichen Speicherkarte wegen.

Zitat von narf2

ist das normal bei einem 1 MB kalender?

Das kann ich Dir nicht mit Sicherheit sagen. Für normal halte ich das aber nicht.

Unsere Kalender und Adressbücher sind sämtlich deutlich unterhalb 1MB groß. Zusammen kommen sie aber auf etwas mehr als 1MB. Wenn ich den TB starte, also sämtliche Kalender und Adressbücher auf Änderungen geprüft werden, dauert das Synchronisieren so etwa 10 Sekunden.

Wenn ich nur einen Datensatz ändere oder hinzufüge, dauert es vielleicht 3 Sekunden, bis ich die Änderung im TB sehe.

Das alles auf einem alten RasPi Modell B. Dessen CPU geht beim Starten des TB für diese rund 10 Sekunden allerdings auf fast 100%. Beim Pi 2 oder 3 sollte das spürbar schneller gehen.

Zitat von narf2

oder liegt das an dem aktualisierungsintervall (von aktuell 30 min)?

Im Prinzip sollte das keine Rolle spielen. Ich kann mir vorstellen, dass das in Deinem Fall vielleicht so ist, dass sich in dieser Zeit mehrere Syncs überschneiden, oder der RasPi in der Zwischenzeit noch schwer mit anderen Prozessen zu hat.

Ich aktualisiere am PC gar nicht per Intervall sondern nur beim Start des TB und am Smartphone einmal täglich. Für Kalender und Adressbücher scheint mir das völlig ausreichend. Insgesamt hängen bei uns aber mehrere Rechner und Smartphones am Radicale.

Du kannst ja einfach mal einen Testkalender mit nur wenigen Daten anlegen und schauen, wie schnell der synchronisiert wird. Neben der Größe scheint mir aber der wesentliche Unterschied der zu sein, dass wir von Beginn an Lightning verwendet haben. Vielleicht liegt es nicht an der Größe sondern an den Altbeständen.

Zitat von narf2

ich habe etwas gefunden, aber so wie es aussieht, ist der fix nur für die kommende version 2

In der Beschreibung steht:

Zitat

The tests are performed on a calendar and addressbook with 10,000 files.

Daraus würde ich schließen, dass das dort behandelte Performance-Problem überhaupt nur in der kommenden Version 2 existiert. Die Version 1.x benutzt pro Kalender oder Adressbuch nur ein File mit entsprechend vielen Einträgen. Mit Version 2 ändert sich das, weshalb auch eine Migration nötig sein wird.

Daraus lässt sich nicht schließen, dass die Version 1 auch ein Performance-Problem hätte. Dagegen spricht für mich auch der Umstand, dass Lightning beim lokalen Import, also ganz ohne Beteiligung des Radicale, nach Deinen Worten 10 Minuten gerödelt hat. Das lag sicher nicht an einer langsamen Festplatte.

Und wie geschrieben, bei mir genügen für insgesamt 1MB einige Sekunden.

edvoldi

Du hast doch zu seinen Kontakten auch Fotos hinterlegt. Deine Adressbücher sind deshalb sicher noch weit größer als 1MB. Wie lange dauert die Synchronisation bei Dir?

Von einer solch langen Zeit, wie sie bei narf auftritt, habe ich zuvor noch nicht gehört.

Ich würde deshalb vorerst bei der These bleiben, dass der Fehler in den Altlasten aus dem Sunbird steckt.

Die Zeiten sind m.E. immer noch viel zu hoch. Ich wäre damit nicht zufrieden.

Zitat von narf2

falls es ein tool gäbe, ...

Ich kenne keines, habe aber bisher auch nicht danach gesucht. Falls Du Dir selbst etwas schreiben möchtest, die Syntax ist nicht schwierig. Ein Event beginnt immer mit BEGIN:VEVENT und endet mit END:EVENT.

Den Zeitpunkt, an dem ein Termin beginnt bzw. endet, erkennst Du an:

DTSTART;
DTEND;

Auch längst erledigte, sich wiederholende Termine aus der Vergangenheit haben einen DTEND-Eintrag, der dann natürlich in der Vergangenheit liegt. Daran kannst Du sie erkennen.

Besser und einfacher wäre es aber wohl, wenn Du damit beginnen würdest, parallel mehrere neue Kalender anzulegen und in den alten keine neue Termine mehr einträgst. Dann kannst Du ihn irgendwann abschalten und bist die Altlasten endgültig los.