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

[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  . 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]

Ich habe nun im Modul 49_IPCAM eine Zeile geändert:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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


Code Auswählen Erweitern

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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

Bisher lief die Einstellung ohne Probleme. Seit einer Woche bekomme ich aber häufiger die o.g. Fehlermeldung.

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

Code Auswählen Erweitern


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