57_Calendar - mal wieder Probleme beim Abruf der Kalenderdaten

[betateilchen]

richte Dir halt einen Kalender ein...

ausserdem solltest Du doch eigentlich am besten wissen, was Du in den HttpUtils zwischen der genannten Version und heute geändert hast?

[betateilchen]

Ich hätte da übrigens gleich noch einen kleinen Patch unterzubringen, um eine unschöne Konsolenmeldung zu unterdrücken, falls $keep größer ist als die tatsächlich gefundene Anzahl Kalendereinträge.

Code Auswählen Erweitern


# svn diff 57_Calendar.pm

Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm      (revision 4753)
+++ 57_Calendar.pm      (working copy)
@@ -962,7 +962,7 @@
     if(defined($a[3])) {
       my $keep= $a[3];
       return "Argument $keep is not a number." unless($keep =~ /\d+/);
-      splice @texts, $keep if($#texts>= 0);
+      splice @texts, $keep if($#texts>= 0 && $#texts >= $keep);
     }
     return join("\n", @texts);


[rudolfkoenig]

richte Dir halt einen Kalender ein...

Falsch. Ich will nicht solange raten, bis was nicht geht, und danach weiter raten, ob das das ist, was auch bei dir nicht geht.

ausserdem solltest Du doch eigentlich am besten wissen, was Du in den HttpUtils zwischen der genannten Version und heute geändert hast?

Sicher. Ich habe es vor ca einem Monat komplett neugebaut, damit es auch asynchron funktioniert, siehe http://forum.fhem.de/index.php/topic,17804.msg119720.html#msg119720
Und danach auf 4 Platformen mit jeweils 6 Testfaellen probiert. Und gehofft, dass wenn es Probleme gibt, nicht nur: "geht nicht, such selber" als Meldung kriege, sondern was besseres.

[betateilchen]

Wenn Du diesen Thread einfach mal von Anfang bis jetzt gelesen hättest (es sind noch nicht einmal zwei Seiten!), hättest Du nicht fragen brauchen, denn es steht schon alles hier drin.

HttpUtils_BlockingGet() bzw. GetFileFromURLQuiet() liefert hier an 57_Calendar.pm kein Ergebnis zurück, wenn die Version 4514 oder neuer der HttpUtils verwendet wird.
HttpUtils_BlockingGet() bzw. GetFileFromURLQuiet() funktioniert hier ohne jegliche Änderung prima bis zur Version 4497.

57_Calendar mit LWP::ua anstatt der HttpUtils funktioniert immer.



Nehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein? Diese Frage ist ernstgemeint.



Ein weiteres Problem (57_Calendar unterschlägt wiederkehrende Termine) muss ich erst noch weiter analysieren.

[rudolfkoenig]

Ich habe diesen Thread gelesen, ich fasse ma zusammen:
- bei dir funktioniert Calendar seit dem Umbau von HttpUtils nicht.
- bei zwei anderen Benutzern funktioniert Calendar mit dem umgebauten HttpUtils.
D.h. wenn ich jetzt bei Google ein Kalender anlege, und nach eine Stunde ungefaehr weiss, wie das Calendar-Modul funktioniert, werde ich wahrscheinlich (66%) keine Probleme haben. Da ich mangels Kenntnisse einen Trivialfall testen werde, ist die Wahrscheinlichkeit noch hoeher. Diese erfolglose Stunde wollte ich mir sparen.

Version 4497 ist vor dem Umbau (und auch noch ohne HttpUtils_BlockingGet), Version r4514 ist nach dem Umbau, der Rest sind Bugfixes fuer Sonderfaelle.

Vorschlag: Du setzt ein Calender-Request mit maximalen loglevel ab, parallel fuehrst du strace durch, und ich versuche aus den beiden Logs schlauer zu werden.

[betateilchen]

Kalender bei Google aufsetzen = 1 Minute, diesen Kalender in fhem einbinden = 1 Minute, keine Ahnung, wofür Du da eine Stunde brauchen willst. Der Kalender selbst braucht noch nichtmal Einträge zu besitzen. Aber in einem hast Du recht - vielleicht tritt das Problem bei Dir gar nicht auf.

Kommen wir deshalb noch einmal auf diese Frage zurück:

Nehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein?

Ich frage das nicht zum Spaß, denn ich bestreite nicht, dass es Installationen geben kann, bei denen das Problem nicht auftritt.


Zum Logging komme ich frühstens heute abend zu Hause.

[rudolfkoenig]

keine Ahnung, wofür Du da eine Stunde brauchen willst

Wenn man sich auskennt, klar. Wenn man nicht so recht weiss, wo/wie/was man machen soll, dann dauert das laenger.
Da es bei dir mit LWP und mit der alten Version der HttpUtils funktioniert, ist es ganz klar ein Bug in der neuen Version.

[Dr. Boris Neubert]

Hallo Rudi,

meine Recherchen deuten auch auf die Ursache in HttpUtils.pm hin. Wenn es Dir hilft, baue ich Dir in den nächsten Tagen eine Teststellung auf, die das Problem lokalisieren hilft - allerdings ohne reproduzierbaren Fehler

Grüße
Boris

[rudolfkoenig]

@Boris: Wenn die Daten von betateilchen nicht reichen, dann bitte.

[betateilchen]

ich habe doch gerade eben hier eine Antwort gepostet???

Habe nun alles auf verbose=5 gestellt und ein Kalenderupdate abgerufen. Mehr als das, was ich hier im Thread schon an Logging gepostet habe, ist fhem nicht zu entlocken. Es werden von den HttpUtils einfach keine Daten zurückgeliefert. Und 57_Calender gibt dann die korrekte Fehlermeldung für nicht gefundene Daten aus.

[rudolfkoenig]

Ich versuchs mit rot und fett, blinken gibts leider nicht:

Vorschlag: Du setzt ein Calender-Request mit maximalen loglevel ab, parallel fuehrst du strace durch, und ich versuche aus den beiden Logs schlauer zu werden.

[betateilchen]

Schrei mich nicht an, ich hatte das durchaus schon heute nachmittag gelesen. Aber im Moment habe ich grade wichtigere Probleme, als mich um Dein von Dir (!) verkorkstes HttpUtils-Modul zu kümmern.

[Dr. Boris Neubert]

Udo,

mir gefällt Dein Ton nicht.

Ich kann gut verstehen, daß Dich das Problem nervt. Für ein Projekt auf freiwilliger Basis bieten wir hier super Support in unserer Freizeit. Bitte dies bei künftigen Antworten stets zu bedenken.

Viele Grüße
Boris

[betateilchen]

Hallo Boris,

mir gefällt Rudis Ton auch nicht. Der muss mich hier im Forum nicht dauernd (und immer wieder!) hinstellen wie den letzten Deppen, der die einfachsten Dinge nicht versteht, um die man ihn bittet. Ich bin mindestens 14 Stunden pro Tag außerhalb unterwegs und kann deshalb nicht immer alles sofort und genau so testen, wie er das möchte. Bisher habe ich immer alle gewünschten Informationen bereitgestellt, ebenfalls auf freiwilliger Basis und auch nicht im 24/7 Support, den hier niemand erwartet und niemand geben kann!

Ich bitte, auch DAS zu berücksichtigen.

Zusätzliches Debugging in HttpUtils_BlockingGet

Code Auswählen Erweitern


sub
HttpUtils_BlockingGet($)
{
  my ($hash) = @_;
  my $err = HttpUtils_Connect($hash);
Debug "err after Connect: $err";
  return ($err, undef) if($err);

  my ($buf, $ret) = ("", "");
  $hash->{conn}->timeout($hash->{timeout});
  for(;;) {
Debug "entered for;; ret: $ret";
    my ($rout, $rin) = ('', '');
    vec($rin, $hash->{conn}->fileno(), 1) = 1;
    my $nfound = select($rout=$rin, undef, undef, $hash->{timeout});
Debug "nfound: $nfound";
    if($nfound <= 0) {
      undef $hash->{conn};
      return ("$hash->{displayurl}: Select timeout/error: $!", undef);
    }

    my $len = sysread($hash->{conn},$buf,65536);
Debug "len: $len";
    last if(!defined($len) || $len <= 0);
    $ret .= $buf;
  }
  return HttpUtils_ParseAnswer($hash, $ret);
}


liefert

Code Auswählen Erweitern


2014.01.27 23:39:19 1: DEBUG>err after Connect:
2014.01.27 23:39:19 1: DEBUG>entered for;; ret:
2014.01.27 23:39:19 1: DEBUG>nfound: 1
2014.01.27 23:39:19 1: DEBUG>len: 0
2014.01.27 23:39:19 1: Calendar testkalender: Could not retrieve file at URL


Das bedeutet für mich, dass die Zeile

Code Auswählen Erweitern

    my $len = sysread($hash->{conn},$buf,65536);

aus welchen Gründen auch immer, keine Rückgabe liefert.

Ich hoffe, das hilft erstmal irgendwie weiter.

Mehr (insbesondere das strace) kann ich im Moment mit den Möglichkeiten, die mir aktuell zur Verfügung stehen, nicht machen!

[betateilchen]

Zurück zum sachlichen Inhalt dieses Threads...

Auch wenn ich diese Frage

Nehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein?

bereits zweimal gestellt habe, muss ich sie noch ein drittes Mal in den Raum stellen.

Der Hintergrund ist nämlich der, dass ich insgesamt drei fhem Installationen habe, bei denen fhem überall auf dem aktuellsten Stand ist:

1. Beaglebone Black mit Debian
2. RaspberryPi mit Debian
3. fhem auf Debian in einer VMware Workstation unter Windows7

Auf allen drei Systemen wird der gleiche Kalender abgefragt.
Auf den Systemen 1 + 2 tritt der beschriebene Fehler mit den aktuellen HttpUtils auf.
Auf den Systemen 1 + 2 funktioniert alles mit der alten HttpUtils Version.
Auf System 3 funktioniert der Kalender mit den aktuellen HttpUtils problemlos.

Es scheint mir so, dass es irgendwelche Abhängigkeiten gibt, die ausserhalb von fhem zu suchen sind.
Deshalb hatte ich bereits zweimal nach weiteren möglichen/denkbaren Ursachen gefragt,
die vielleicht irgendwo in der Abhängigkeitenkette zu suchen wären?

57_Calendar hängt ab von HttpUtils
HttpUtils hängt ab von IO::Socket::INET + fhem.pl (?)
fhem.pl hängt ab von IO::Socket + ... (?)