IPCAM: Wrong or not supported image format: error while reading source image

Begonnen von Alcamar, 24 Juni 2017, 17:50:01

Vorheriges Thema - Nächstes Thema

Alcamar

Die Fehlermeldung im Log:
Wrong or not supported image format: error while reading source image
ist nicht neu, wenn man hier durch die Threads stöbert.
Ich habe eine IP-Kamera seit über einem Jahr im Einsatz, die bei einem Event eines Homematic Bewegungsmelders 4 Snapshots erstellt, die dann in der Folge automatisch versendet werden. Bisher lief die Einstellung ohne Probleme. Seit einer Woche bekomme ich aber häufiger die o.g. Fehlermeldung.

In einem Thread habe ich nun gelesen, dass eine timeout-Einstellung das Problem beheben könnte. Ich zweifle ein wenig daran, weil ich ja bewusst nichts geändert habe. Zudem ist die Funktion GetFileFromURL im Modul IPCAM versteckt, das ich nicht so einfach verändern will und genaugenommen gar nicht wüsste wo ich den Standardparameter für das Timeout von 4 auf z.B. 5 setzen könnte.

Am IPCAM-Modul scheint es in letzter Zeit ebenfalls keine Änderung gegeben zu haben. Woran kann das also liegen, dass die Fehlermeldung generiert wird und keine snapshots erstellt werden?


Alcamar

Ich habe nun im Modul 49_IPCAM eine Zeile geändert:
GetFileFromURLQuiet($camURI, 8, "", 1, 5);
Die ursprüngliche Meldung ...Wrong or not supported image format... kommt nun seltener, bleibt aber nicht aus. Teilerfolg?
Gibt es eine Möglichkeit den gesamten Vorgang zu debuggen?
Mir ist folgendes aufgefallen: mit dem Get Image der IP-Cam, werden nun 5 Bilder im Abstand von 2 Sek. erstellt. Eigenartigerweise werden erst Bild 3,4 und 5 erstellt, bevor dann Bild 1 und 2 generiert werden.
Weiß jemand warum?
Dies ist natürlich beim Versenden der Bilder nicht unwichtig. Bisher habe ich per Telegram immer das Bild mit der Nummer 1 versendet. Nun ist wohl das Bild mit der Nummer 3 das erste und für mich interessante.
Nochmal: bis zur genannten Fehlermeldung im Log funktionierte alles perfekt.  :-[

Wird mir mit dem nächsten Update die Datei 49_IPCAM wieder überschrieben, zurück in den Originalzustand?

topfi

Dieses Verhalten kenne ich. Ist aber eigentlich nicht Homematic ...  8)

*Die Fehlermeldung rührt wahrscheinlich von einer schlechten WLAN-Verbindung zur Kamera. Ich vermute, ein Nachbar hat Deinen Kanal oder einen Nachbarkanal belegt. Danke für den Tip mit dem Timeout, das werde ich bei mir auch mal höher setzen. Allerdings kommen die Fehler hier kaum noch, seit ich mein Netzwerk aufgeräumt und die Verbindung zu den Kameras verbessert habe. Die Änderung in der 49_IPCAM sind nach dem nächsten update wieder weg, es sei denn, du änderst die Schreibrechte.

*Mitunter - vor allem nach dieser Fehlermeldung - kommen die Bilder in verkehrter Reihenfolge, das kenne ich auch. Abhilfe: Einfach die Definition, in der das getimage aufgerufen wird, also hier z.B.:

define Foto_Flur_betreten notify PIR:Bewegung get Kamera_Flur image


"Foto_Flur_betreten" neu laden. Einfach die Definition in der Webansicht aufrufen und auf modifizieren klicken, ohne was zu ändern. Danach stimmt die Reihenfolge wieder.


ph1959de

Zitat von: topfi am 26 Juni 2017, 12:37:40
... Die Änderung in der 49_IPCAM sind nach dem nächsten update wieder weg, es sei denn, du änderst die Schreibrechte.
Bitte nicht ... dafür gibt es exclude_from_update
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

topfi

Danke, das ist ein sehr nützliches Attribut, das kannte ich noch nicht. Wieder was gelernt.  :D

Alcamar

Der Hinweis mit dem exclude-Update war sehr gut. 49_IPCAM wird bei update check nicht mehr aufgelistet. Falls allerdings mal ein "richtiges" Update kommen sollte, bekomme ich das auch nicht mehr automatisch mit. Damit kann ich aber leben.

Die Kamera läuft über PowerLan und es ist unwahrscheinlich, dass sich darin ein Nachbar verirrt. Ich habe einen neuen Switch auf dem Netzwerksegment. Das ist die einige Änderung, die dort überhaupt vorgenommen wurde. WLAN ist mir für die Anbindung von Kameras nicht so sympathisch. 😊

Da der Restart von Fhem bisher die Reihenfolge der Bilder vermutlich wieder berichtigt hat, könnte ich mir vorstellen, dass ein modify ohne Veränderungen vorzunehmen zum gleichen Ergebnis führt. Wäre auch besser. Leider kann ich das derzeit nicht verifizieren.


Das aktuelle Setup ist derzeit insgesamt nicht zufriedenstellend. Es dauert mir zu lange bis mir ein Bild zugesendet wird. Und per Mail kommen dann ebenfalls nach relativ langer Zeit Bilder an, die wenn ich Glück habe, in der richtigen Reihenfolge sind.

enno

Moin Alcamar,

ich habe mir dafuer zwei Device von IPCAM angelegt. Eines das nur ein Bild macht, und das andere ausführlicher mit 5 Bildern. Da die Bilder erst verschickt werden, wenn wenn das letzte Bild angelegt wurde reagiert das Device mit einem Bild sofort und die anderen folgen dann deutlich später.

Vielleicht eine Lösung um schneller an Bilder zu kommen.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

Alcamar

Moin Enno,

wie bekommst du es hin, dass erst, wenn das letzte Bild gemacht wird der Versand startet?
Welchen Event muss ich da abgreifen?

Bei mir setze ich zum Versenden ein notify ein:
MyCam:.*snapshots.*

Sobald Snapshots generiert werden, startet der Versand.

enno

Einfacher FHEM Anwender auf Intel®NUC

Alcamar

Sowohl mit der Analyse wie auch mit der Lösung komme ich langsam voran, aber folgendes würde ich mittlerweile behaupten:

  • die Fehlermeldung ...Wrong or not supported image format... führt zu einer veränderten bzw. falschen Nummerierung der erstellten Bilder
  • die Reihenfolge lässt sich bei mir nur durch einen shutdown restart beheben. Mag sein dass auch ein reload eines Einzelmoduls auch ginge.
Auch wenn ich kein Entwickler bin, vermute ich, dass sich dieses beobachtete Verhalten (Bug) im Modul IPCAM beheben lässt. Zusammen mit dem Mechanismus, der meine ursprüngliche Fehlermeldung auslöst, wird auch die Initiierung für die laufende Nummerierung der erstellten Bilder neu gesetzt. Bei mir fängt die Bilderserie erst bei 3 an. Dann kommt Bild 4,5,1,2. Erst ein Reboot (oder eventuell Reload?) setzt den Startwert der Nummerierung von 3 zurück auf 1.
Für einen Entwickler müsste das doch schnell zu verifizieren sein, oder? Oder ist es kein Bug in dem IPCAM-Modul? Es kann auch sein, dass ich es einfach immer noch nicht kapiere.

Auch wenn ich fhem eine Weile einsetze, fühle ich mich immer noch als Neuling. Falls ich wirklich ein Bug identifiziert hätte, würde das dann der Entwickler des Modul implementieren oder sollte ich auch gleich die Lösung bereithalten? Dafür muss ich erst in die Programmierung eintauchen.  ;)

Alcamar

Zu Punkt 1. muss ich ergänzen, dass die falsche Nummerierung der Bilder nicht immer erfolgt, nach dem die Fehlermeldung im Log erscheint. Also leider ist auch diese Gesetzmäßigkeit nicht vorhanden.

Trotz Erhöhung der Wartezeit ist die Fehlermeldung sporadisch weiterhin im Log. Leider weiß ich nicht, wie ich die Bedingungen festhalten kann, die zum Fehler führen.  :-\

Otto123

Hallo Alcamar,

ich lese das immer mit und denke es ist mittlerweile klar, dass es gar nicht um Homematic geht. Ich will nicht die Forumspolizei spielen, aber ich denke der Thread wäre in Unterstützende Dienste (der "Heimat" von IPCAM) besser aufgehoben.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Alcamar

Hallo Otto,

Ich danke Dir für den Hinweis. Was heißt es für mich? Kann ich den Thread ändern?
Oder macht das ein Admin?

Was kann ich tun?

Grüße
Alcamar

Otto123

Kannst Du machen. Einfach verschieben, irgendwie ganz unten. eventuell im ersten Beitrag  8)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Alcamar

Unter der Annahme, dass die Netzwerkgeschwindigkeit das Problem wäre, wie könnte ich vor erstellen der Bilder die aktuelle Netzwerksituation prüfen?
Damit könnte ich zumindest sehen, ob wirklich das Netzwerk das Problem ist. Derzeit kann ich nur feststellen, dass IPCAM einfach sporadisch den Fehler generiert. Eine Systematik kann ich leider nirgendwo erkennen.  :-[

Alcamar

Ich habe noch einen Hinweis, der für die Fehlersuche im Modul IPCAM nützlich sein könnte:

Die Kamera soll 5 Bilder liefern und als Delay ist 2 Sekunden eingestellt. Wenn die Fehlermeldung (...Wrong or not supported...) auftaucht, die dann zur falschen Reihenfolge führt, werden die Bilder 3,4,5 in einem Abstand von 2 Sekunden erstellt. Danach vergehen 30 Sekunden bis die Bilder 1 und 2 im Abstand von ebenfalls 2 Sekunden erstellt werden.

Wenn ich das richtig verstanden habe, ist Martin der Autor von IPCAM. Ist der Fehler etwas was im Modul behoben werden kann, oder ist es einfach ein Problem meiner Infrastruktur, die das Modul nicht toleriert? Gibt es eine Aussicht, dass im Modul eine Anpassung vorgenommen werden kann?

Vielleicht ist eine andere Frage wichtiger: Haben nur ganz wenige das beschriebene Problem?
Ich habe zwar ein paar Posts zu dem Fehler gefunden, aber vielleicht ist einfach das Interesse an einer Korrektur nicht so hoch, weil nur wenige davon betroffen sind.


Alcamar

Vielleicht brauch ich etwas mehr Geduld  :D. Aber ich habe den Weg über IPCAM aufgegeben.
Bilder von einer IP-Kamera lassen sich auch anders generieren und das habe ich erstmal so gelöst:
https://forum.fhem.de/index.php/topic,47551.0.html

topfi

Zitat von: Alcamar am 26 Juni 2017, 09:36:27
Ich habe nun im Modul 49_IPCAM eine Zeile geändert:
GetFileFromURLQuiet($camURI, 8, "", 1, 5);
Die ursprüngliche Meldung ...Wrong or not supported image format... kommt nun seltener, bleibt aber nicht aus. Teilerfolg?
[...]
Karma? Jetzt fängt plötzlich eine meiner Kameras auch sporadisch damit an.   ::)

Die Zeile taucht in dem Modul 2x auf (Zeilen 233 und 380 in Version 2626). Welche hast Du geändert? Warum hast du nicht nur die 8 Sekunden gesetzt, sondern auch den loglevel hoch? Da sollte doch dann nichts mehr kommen, bzw. ich wollte doch wissen, falls doch?!

Alcamar

Hallo Topfi,

ich habe die Zeile irgendwo im Forum "abgekupfert".  :)
Dort waren sogar 10 Sekunden statt 8 Sekunden eingetragen. Ich habe mittlerweile beiden Varianten (8 und 10) ausprobiert und das Ergebnis ist das gleiche >:(. Ich habe die Zeile nur einmal bei mir entdeckt.

Die Fehlermeldung an sich finde ich nicht einmal so schlimm. Problematisch ist nur, dass danach die Numerierung der Bilder oft nicht mehr stimmt. Ein Reload von 49_IPCAM heilt das Problem leider nicht, sondern ein shutdown restart.
Ich bin noch dran zu prüfen, ob das Netzwerk wirklich die Ursache für das Problem ist. In dem betroffenen Segment nutze ich derzeit PowerLAN, plane aber die Ablösung. Mir schwebt ein Skript vor, dass die Verfügbarkeit der Netzwerkverbindung ständig mitprotokolliert. Wenn dann IPCAM den Fehler auswirft, kann ich im Netzwerkprotokoll sehen, ob es da wirklich ein Problem gab.

In IPCAM will ich keine Zeit mehr investieren, weil die Snapshot-Erstellung auf anderem Wege mir mittlerweile lieber ist. Dort mag es die gleichen Netzwerkproblem geben, aber die Konsequenzen sind geringer.

topfi

Anstelle shutdown restart genügt es, das "Gerät" (Funktion, was auch immer das eigentlich ist), in der das IPCAM definiert ist, also z.B.:

define Kamera_Tuer IPCAM 192.168.2.44

neu zu definieren, am einfachsten mit einem leeren modify.

Deine neue Methode habe ich mir gestern kurz angeschaut. Damit wird aber immer nur EIN Bild gemacht, oder?

Alcamar

Ich benötige nur ein Bild. Die Routine kann man aber ohne größere Probleme erweitern.
Theoretisch wäre so ein Aufruf so möglich, dass man der Routine den Namen der Kamera mitgibt, die Anzahl der Bilder und die delay-Zeit. Also in etwa so:
Erstelle_Snapshots(MyCam,5,2);
Das würde von der Kamera MyCam fünf Bilder im Abstand von jeweils 2 Sekunden erstellen.
Genaugenommen macht das ja IPCAM. Die Parameter werden dort als Attribute festgelegt. Ist sehr gut gelöst, wie auch das Modul sehr nützlich ist. Aber mit einem Defizit.  :-[

Patrik.S

Das mit der Timeout Erhöhung in der 49_IPCAM.pm beim Aufruf von GetFileFromURLQuiet() kam wohl von mir.
Ich habe das ganz einfach nachgestellt, indem ich mehrmals mit wget und curl Mitteln die Antwortzeiten meiner Smartphone IP Cams überprüft hatte.

Also in einem Script mehrmals beide Varianten des Bild holens gemacht, zeigt das MEINE Kameras mind. 4 Sekunden benötigen, eher mehr.
Daher ist der Methoden Defaultwert von 4 Sekunden bei mir nicht ausreichend.

time http://user:passwors@192.168.xxx.yyyy/abcdefg.jpg

abcdefg.jpg                             [         <=>                                                       ]   1,31M   277KB/s   in 4,9s
real    0m5.023s

abcdefg.jpg.1                           [        <=>                                                        ]   1,35M   316KB/s   in 4,4s
real    0m4.525s

abcdefg.jpg.2                           [       <=>                                                         ]   1,35M   334KB/s   in 4,1s
real    0m4.199s

abcdefg.jpg.3                           [        <=>                                                        ]   1,35M   291KB/s   in 4,8s
real    0m4.810s

abcdefg.jpg.4                           [       <=>                                                         ]   1,34M   313KB/s   in 4,4s
real    0m4.430s

fotoaf.jpg.5                           [        <=>                                                        ]   1,34M   296KB/s   in 4,6s
real    0m4.682s


curl -so /dev/null -w '%{time_total} sec,msec\n' http://user:passwors@192.168.xxx.yyyy/abcdefg.jpg

4,491 sec,msec
12,700 sec,msec   -- ja, es sind 12 Sekunden
5,028 sec,msec
4,793 sec,msec
32,047 sec,msec   -- ein seltener aber noch heftigerer Ausreißer
4,720 sec,msec
4,730 sec,msec


Wenn nun mehrfach hintereinander Bilder genommen werden sollen, kann es auch bei anderen Kameras passieren, das sie keine Dauer Einzelbilder liefern können, sondern längere Zeit benötigen "sich zu stabilisieren".
Meine Gedanken zum Thema 5 Bilder nehmen:
Kommt es während des Holens von Bild 1 zu dem Timeout, startet ja sofort das Holen des 2. Bildes.
Dieser 2. Request wird der IP Cam nicht schmecken und die Verzögerungen summieren sich.
Einfach mal Lasttesten mit oben genannteten Mitteln und das ganze mind. 10 mal hinereinander.
Mein IP Cams sind bei Dunkelheit noch langsamer, da das Zusammenspiel aus Blitzlicht und Autofocus dann noch länger brauchen.

Das ganze hilft natürlich nur, wenn tatsächlich keine Daten zurückgekommen sind
Eine zusätzlich Logausgabe würde das dann anzeigen


  $snapshot = GetFileFromURLQuiet($camURI, 10, "", 1, 5);
  if ($snapshot eq "" ) {
    Log 3, "IPCAM Snapshot of $name is emtpy!";
  }


Welche Zeile des GetFileFromURLQuiet  ist es? --> Es ist die 2. GetFileFromURLQuiet Zeile, wo dann als nächstes ein $imageFormat = IPCAM_guessFileFormat(\$snapshot); gemacht wird.

Ist $snapshot nicht Leer, können dann die vielen anderen Gründe verantwortlich sein. Falsche Übergabe des User:Password, falscher URL Aufruf, etc...

Alcamar

Hallo Patrick,

dann habe ich bei Dir geklaut.  ;D
Danke dafür.

Bei mir ist die Dauer bei der Bilderstellung nicht da Kernproblem.  Normaleiweise reicht der Default-Wert. Auch mit meiner Altertive die Bilder von der Kamera zu holen, geht rasend schnell, w e n n   ein Netz da ist. Manchmal meldet sich das Netz einfach ab.
In dieser Zeit kann ich einstellen was ich will, es kommt nix.

Ich suche also derzeit eine System-Aufruf in der Form:
Repeat mget Bild von der Kamera
solange die ZielAdresse (IP der Kamera) nicht erreichbar ist

Diese Logik könnte man vielleicht auch in IPCAM einbauen, aber meine Mini-Lösung reicht mir bereits vollkommen. Da will ich jetzt nur noch diese beschriebene Erweiterung vornehmen.

Patrik.S

Bei mir gibt's nicht zu klauen, ist ja nicht mein Code ;)

Bei Dir ist nicht ein möglicher Timeout das Problem, sondern das dein Fhem Rechner nicht immer die IP Cam erreicht.

Erst hatte ich gedacht: Naja er wird ein Netzwerk aus mehreren Segmenten haben, und ein Router dazwischen und jetzt routet was falsch.
Oder wie bei meinem RaspberryPI, das der sich irgendwann zwei IP Adressen zugelegt hatte, weil der Raspi zusätzlich zur statischen IP trotzdem noch einen dhcp client service aktiv hatte und dann vom Telekom Router nur noch über die dhcp bezogene IP ansprechbar war.

ZitatBisher lief die Einstellung ohne Probleme. Seit einer Woche bekomme ich aber häufiger die o.g. Fehlermeldung.
8)
Wenn es bisher immer zuverlässig lief, was hat sich dann geändert im Netzwerk?

Dein IP Cam Kamera Model hast Du noch nicht erwähnt. Vielleicht ist das ja der Verursacher nach dem letzte Firmwarupdate.

Was ist für dich die "aktuelle Netzwerksituation"? Ob die IP Cam erreichbar ist oder der Datendurchsatz von dieser?

Ein simpler PING könnte da helfen für die Erreichbarkeit.
Das ganze über das Modul PRESENCE

# ---- PRESENCE zur Ueberwachung der IP Kammeras, ob diese Absprechbar sind
define pingCheckIPCam PRESENCE lan-ping 192.168.XXX.YYY 60


Anstatt des 60 Sekunden kannst Du auch weniger einstellen, um die Aussetzer besser zu finden.

Wenn der Status über ein event-on-change-reading in ein Logfile geschrieben wird, kann man sehen wie oft das passiert.

Das kann echt alles sein. Dein Powerlan Adapter kann z.B. auch einen Schuss weg haben.

topfi

Kann es sein, dass Deine Kameras zusätzlich mit der eingebauten Bewegungserkennung Mails versenden?

Zwei von meinen Instars fingen kürzlich wie von Geisterhand an, öfter neu zu booten. Normalerweise laufen die monatelang durch. Beide sollten eigentlich nicht gleichzeitig kaputt sein. Nach 2 Abenden Tüftelei hatte ich die Ursache gefunden: der smtp-Server war schuld. Bei den anderen Kameras hatte ich google genutzt und bei den beiden älteren Kameras hier smart-mail, weil die noch kein TLS können. Nachdem ich die auf einen anderen smtp-Server umgezogen habe, ist wieder Ruhe.

Deshalb hatte ich auch kürzlich im IP_CAM-Modul Probleme. "Karma" ;-)

Alcamar

@Patrick:
Ich nutze Kameras von Axis (3011, 3024). Zumindest da woch ich auch PowerLan nutzen muss. Sonst habe ich INSTAR.
Das einzige was ich am Netzwerk geändert hatte, war eine zusätzliche Kamera auf den gleichen Switch zu legen. Jetzt gehen zwei Kameras in einer 5-Port Switch, der widerum mit PowerLan verbunden ist.
Offenbar hat die PowerLan-Verbindung nicht die "Power", weil ich auch ein ping keine konstante Antwortzeiten habe. Manchmal sind größere Ausreßer dabei. Deshalb werde ich PowerLan auch ersetzen. Den Ping habe ich auf dem CubieTruck ausgeführt. Deine Idee einen ping von fhem aus zu probieren finde ich gut.

<If ping erfolgreich dann hole Bild> ist das was ich benötige. IPCAM holt ein Bild auch dann,  wenn ein ping nicht erfolgreich wäre und verbiegt sich scheinbar dabei so, dass die Reihenfolge der Bilder nicht mehr paßt.

Wenn die Antwortzeit zu lange dauert, ist das Motiv vor der Kamera auch nicht mehr aktuell. Daher kann die einzige Lösung nur ein Netzwerk ohne PowerLan sein. Als Temporäre Lösung ist PowerLan sehr nützlich, aber Zuverlässigkeit ist leider anders definiert.  ;)

@topfi:
Die Kameras sind bei mir nur als "Auge" im Einsatz. Sie schicken weder Emails, noch sollen sie relevante Bewegungen registrieren. Sie sollen nur Bilder auf Zuruf generieren.