Kalender-Sync von Sunbird(!) auf Android

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

    • Sunbird-Version: 1.0b1
    • Betriebssystem + Version: Win 7 x64
    • Eingesetzte Antivirensoftware: Avira
    • Firewall (Betriebssystem-intern/Externe Software): Comodo


    Hier können Sie Ihren Text schreiben:


    hallo zusammen,


    ich wage es einmal, das gefühlt 200. topic zu synchronisierungen aufzumachen :)


    ich benutze noch sunbird (er ist einfach schlanker als mein überladener donnervogel) und möchte den kalender mit meinem android synchronisieren. nun habe ich hier drinnen mehrere ansätze gelesen, aber am schönsten finde ich den, bei dem ich den kalender bei einem dienst meines vertrauens (also nicht g**gle) speichere und von dort mit allen geräten (pc, android) synchronisiere.


    nun habe ich das mit gmx ausprobiert. sunbird > datei > kalender publizieren. als fehlermeldung bekomme ich nach passworteingabe folgende:

    "Publizieren der Kalenderdatei fehlgeschlagen.

    Statuscode: 405: Method Not Allowed"


    hat denn jemand schon erfahrungen mit sunbird und android? vielleicht bei einem anderen hoster? oder funktioniert dieser weg mit sunbird überhaupt nicht (mehr)?


    vielen dank schon einmal fürs lesen.


    grüße

    narf

  • Hallo narf,


    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

  • danke für deine antwort, susanne. das erklärt es natürlich :) und danke für deine recherchen...


    jetzt habe ich meinen kalender als ics-file exportiert, aber sobald ich das file in den gmx kalender importieren will, bekomme ich nach einigem rödeln "ausgewählte datei ist fehlerhaft". ich schätze, wir kommen gerade vom hundertsten ins tausendste ;)

    gibt es vielleicht unterschiedliche ics-standards? oder muss ich die datenbank von sunbird irgendwie reparieren? oder gibt es einfach ein tool, das "beschädigte" ics files prüft und glattbügelt?


    gruß,

    narf

  • 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.


    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:


    Code
    1. BEGIN:VCALENDAR
    2. PRODID:irgendwas
    3. VERSION:2.0
    4. BEGIN:VEVENT
    5.    [...]
    6. END:VEVENT
    7.    weitere events
    8. END:VCALENDAR


    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.

  • danke für deine ausführliche antwort, susiTux :)


    ich habe nun den kalender in lightning importiert und nach ca. 10 min rödeln war er dann auch drinnen. als ich beide kalender importiert hatte, war dann das ics-file nach erneutem exportieren > 1 MB ,was wohl die grenze bei gmx darstellt. und wenn ich nur den einen kalender als ics in gmx importieren möchte (knapp unter 1 MB), bringt es nach einigen minuten "ein fehler ist aufgetreten" :/


    ich schaue morgen mal nach alternativen kostenlosen, vertrauenswürdigen hostern, die caldav können.


    grüße

    narf

  • Hallo narf,


    > 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

  • Näheres kann Dir vielleicht generalsync dazu sagen.

    Ohne die Daten gesehen zu haben kann ich aber auch nur bedingt hellsehen, wo das Problem liegt. Eine Vermutung ins Blaue hinein wäre vielleicht ein Zeichensatz- oder Newlineproblem, wenn die Daten ansonsten in Ordnung aussehen. Denkbar wäre auch, dass GMX über nicht unterstützte Daten stolpert, z.B. Aufgaben oder Termine mit komplexen Wiederholungsregeln.

  • Hallo zusammen,

    ich habe jetzt nicht alles genau gelesen, aber ich weiß das die letzte offizielle Version vom Sunbird fehlerhaft war.

    Ich habe eine Version am laufen, sunbird-1.0b3pre.de, die diesen Fehler nicht mehr hat.

    Diese Version wurde vom Deutschen Übersetzer aus den letzten Mozilla Builds gebaut.

    Wenn Du möchtest kannst Du dir diese Version herunterladen.

    sunbird-1.0b3pre.de.win32.zip


    Datensicherung bitte vorher ausführen.

    Diese zip Datei dann einfach in dem Programmordner vom Sunbird entpacken.

     
    Gruß
     EDV-Oldi

  • Hallo edvoldi,

    Ich habe eine Version am laufen, sunbird-1.0b3pre.de, die diesen Fehler nicht mehr hat.

    gibt es die auch als Linux-Version?


    Gruß

    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

  • Hallo Feuerdrache,

    gibt es die auch als Linux-Version?

    ich habe nur noch diese Version, ob es auch eine für Linux gegeben hat weiß ich nicht.
    Da die Sunbirdseite nicht mehr Online ist kann ich da auch nicht mehr nach schauen.


     
    Gruß
     EDV-Oldi

  • Hallo edvoldi,


    danke für die Rückmeldung.


    Gruß

    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

  • vielen dank für eure zahlreichen antworten und eure mühe.

    ich könnte mir mittlerweile auch vorstellen, dass gmx seine limits unterschiedlich definiert. meine ics datei hat ~1.026.000 bytes, was < 1MB ist. aber vielleicht hat gmx in seiner anwendung ein limit von 1.000.000 bytes (1 MiB) und nur in der prüfroutine vorher (die mir den fehler "datei muss < 1 MB sein" auswirft) die korrekten ~1.048.000 bytes. ist aber nur ein schuss ins blaue.


    anyway: ich hatte hier ohnehin noch einen raspberry pi herumliegen. ich baue mir da grade einen kalenderserver mit "radicale" drauf, bevor ich noch versucht bin, ein kostenpflichtiges emailkonto bei posteo zu eröffnen ;)


    lightning läuft schon damit. jetzt muss ich es nur noch auf sunbird und android hinbekommen. die "neue" version von sunbird werde ich dann auch installieren - merci :)


    ich melde mich wenn das projekt abgeschlossen ist.


    viele grüße

    narf

  • Hallo narf,


    ... 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)

  • daaanke für die vielen wertvollen infos, susanne.

    ich bin niemand der sofort auf die neueste major version aufspringt, von daher bleibe ich sicher noch eine weile auf version 1.1.2 :) aber dann werd ich, solange noch keine anderen dienste auf dem rpi definiert sind, einfach auch einen regelmäßigen reboot einplanen.


    wobei ich sagen muss, dass das aktualisieren extrem langsam ist. mein sunbird hat gute 10-15 min gebraucht für den ersten import. mein handy (mit davdroid) ist grade schon eine stunde am rödeln.

    auch wenn ich einen neuen termin in sunbird erstelle, braucht es etliche minuten bis der termin in sunbird erscheint. genauso, wenn ich eine benachrichtigung lösche... ist das normal bei einem 1 MB kalender?! - macht irgendwie nur begrenzt spaß ;) 

    oder liegt das an dem aktualisierungsintervall (von aktuell 30 min)? - wartet er erst auf eine komplette aktualisierung bevor er feedback zu der selbst gemachten änderung bekommt?


    viele grüße

    narf

  • 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.


    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.


    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.


    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.

  • wieder einmal vielen dank für deinen wertvollen input...


    ich benutze ein RPI 2 B, von daher sollte es -wie du sagst- deutlich schneller gehen.


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

    https://github.com/Kozea/Radicale/pull/569


    die altbestände aus dem kalender zu löschen wäre mir tatsächlich zu aufwendig - zumindest manuell.


    vielleicht muss ich mir einfach mal baikal ansehen bevor es noch komplizierter wird.


    viele grüße

    narf

  • 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.

  • als kurze info: ich hab es nicht genau überprüft und schon gar nicht mehfach (ich bin froh dass es läuft), aber mit baikal geht es deutlich schneller.

    mein sunbird/lightning haben sich in etwa 3 minuten den ganzen kalender aufgebaut. mein android handy hat für die erstladung etwa 10 minuten gebraucht. und wenn ich neue kalendereinträge in sunbird mache, erscheinen die auch ca. 10 sec später in sunbird.


    das ist immernoch nicht ganz performant, aber ich kann damit leben.


    falls es ein tool gäbe, das alte kalendereinträge zuverlässig löscht -also auch von sich wiederholenden terminen nur die entfernt, deren letzter termin schon lange zurück liegt- oder gar in einen archiv-kalender überführt, wäre ich dabei. aber ich bin zu faul, mich in die syntax von ics einzuarbeiten und dann etwas zu scripten :)

    ansonsten ist das für mich jetzt abgeschlossen ;)


    vielen dank auf jeden fall nochmals für eure tolle und ausführliche hilfestellungen und beiträge.


    viele grüße

    narf

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


    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.