[ggf. Lösung für RasPi-Cam am CSI] mjpg_streamer > Stürzt ab mit "Standbild"...

    • Offizieller Beitrag

    Wisst ihr eine Möglihckeit den mjpg_streamer zu überwachen bzw. die Ursache für die Abstürze zu finden:


    Hatte meinen DoorPi mehrere Wochen im Testbetrieb und dort hat sich der in der Zeit einmal verabschiedet. War mir aber nicht ganz sicher, ob da nicht jemand an die Verkabelung zur Kamera gekommen ist. Hier hat auch nur ein Neustart vom RasPi geholfen.


    Nach dem Einbau hatte ich meist nach weniger als 12 Stunden einen Ausfall, konnten mit service mjpg_streamer restart aber wieder ein Kamerabild bekommen.
    Danach habe ich einen cronjob eingerichtet der mir jede Viertelstunde ein Bild speichert, dann waren die Probleme erst mal weg.


    Seit drei Tagen etwa reicht das nicht mehr, der mjpg_streamer stürzt wieder vermehrt ab. Also habe ich einen cronjob eingerichtet, der den service einmal am Tag startet.


    Jetzt habe ich trotz dieser Maßnahmen oft bereits wenige Stunden nach diesem Neustart einen Ausfall.


    Das Bild ist entweder nahezu ganz weiß oder ganz schwarz mit einem winzigen Lichtpunkt von einer Straßenbeleuchtung, die tatsächlich an der Stelle im Bild ist.


    Gibt es eine Möglichkeit festzustellen, dass das Bild Mist ist, damit ich dann neu starten kann?
    Noch besser wäre es natürlich zu Wissen warum das überhaupt passiert...


    Viele Grüße,
    Max

  • Hallo Max,


    diese Probleme hatte ich auch.
    Ich schiebe es auf die 6m USB Verlängerung über Cat.7 Kabel ohne Extender.
    Ab und zu lieferte die USB Cam ein überbelichtetes Bild. Oft war er dann ganz weg. Nach neustart des Streamers war alles wieder OK.
    Im Testaufbau hatte ich keine Probleme, aber auch nur 3m USB Leitung.
    Vor kurzen gab's einen Post der mit Änderung der Auflösung experimentierte.
    Ich habe es, mit einen Script gelöst, weil ich keine andere Lösung fand.
    Bis jetzt hatte ich dadurch keinen Bildausfall mehr :)


    Hier der Link zu meinen Beitrag:
    doorpi Beispielscripts

    • Offizieller Beitrag

    Danke CBMOD,


    wenn ich mir dein Beispielskript mit dem Watchdog für den mjpg-streamer anschaue, bekommst du am Port 9000 keine Daten mehr oder? Bei mir kommen immer noch Daten, so dass er den Ausfall bei mir wahrscheinlich gar nicht erkennt auf diesem Weg... Auch jpegs, die ich per Cron hole sind immer valide Bilder...


    Meine Idee wäre daher, dass ich diese über- oder unterbelichteten Bilder irgendwo ablege und mit den Bildern die ich regelmäßig ziehe irgenwie vergleiche. Stimmen die zu sehr über hängt der mjpg-streamer und ich starte dann neu.


    Ein erster Ansatz könnte ImageMagick mit compare sein...

    • Offizieller Beitrag

    Ich habe ja die RasPi-Cam am CSI-Port dran. Sollte das mit der Belichtungsnachführung dort auch funktionieren? Ich bekomme da nur eine Fehlemeldung, dass es den Befehl nicht gibt. Bei uvcdynctrl -c wird "Auto Exposure" aber mit aufgeführt...


    [Nachtrag]:
    uvcdynctrl -s 'Auto Exposure' 0 bzw.
    uvcdynctrl -s 'Auto Exposure' 1
    könnte funktionieren?!


    ...mit uvcdynctrl -c -v weiß ich nun mehr: 0=Auto, 1 Manual Mode...!


    Das mit compare ist auch nicht schlecht was die weißen Tagbilder angeht: >37% Abweichung.
    Nur bei Dunkelheit wird es eng: Dunkel mit Fehler weicht nur etwa 1,5% von einem Bild ohne Fehler ab.
    Aber vielleicht werde ich das mal mitprotokollieren, wenn sie sehr ähnlich sind.


    Also mit dem Auto Exposure verschlimmbessere ich das Ganze noch - das war gestern noch nicht der Fall:
    nach dem Umschalten auf manuell habe ich ein weißes Bild, zurückschalten auf Automatik hilft nicht. Der mjpg-streamer will neu gestartet werden, damit ich wieder ein Bild habe...


    Jetzt habe ich noch den Weißabgleich entdeckt (uvcdynctrl -s 'White Balance, Auto & Preset' 0 / 1). Mal sehen, ob ich damit das Bild wieder zurückbekomme.


    Ansonsten verfolge ich auch noch den Ansatz mit compare weiter...

    • Offizieller Beitrag

    Jetzt habe ich mal ein paar Einstellungen durchprobiert aber das "Einfrieren" des Bildes passiert schon recht häufig - auf ein Mal...


    Einstellungen mit uvcdynctrl bringt bei mir leider gar nichts. D.h. mit mit 'Auto Exposure' kann man den mjp_streamer zuverlässig zum Absturz bringen - danach muss ich ihn neu starten...


    Das Bild wirkt abends oft auch zu dunkel und tagsüber ist es meistens zu hell. Hier hilft bisher nur ein Neustart vom mjp_streamer. Auch wenn das schon länger her ist, scheint es da noch keine Lösung zu geben? Siehe auch:
    https://www.doorpi.org/forum/thread/719-mjpg-stream-zu-hell/
    https://www.doorpi.org/forum/t…mer-automatisch-anpassen/


    Da ich ja einen Helligkeitssensor an meiner Außenstelle am Teensy habe, könnte ich natürlich bei einer großen Helligkeitsänderung den Dienst neu starten.
    Oder ich verküpfe das zusätzlich mit compare indem ich Bilder passend zur Tagesheligkeit ablege und die mit dem aktuellen Livebild vergleiche und dabei das Bild suche, das am nächsten an der aktuellen Tageshelligkeit dran ist...


    Elegant ist das natürlich alles nicht...

    • Offizieller Beitrag

    Vielleicht ist das Absturzproblem gelöst:
    Durch Zufall habe ich diesen Fork vom mjpg_streamer entdeckt:
    https://github.com/jacksonliam/mjpg-streamer


    Zuerst bin ich auf diese Seite aufmerksam geworden:
    https://discourse.octoprint.or…onfiguration-options/1106


    Die /etc/init.d/mjpg_streamer habe ich dazu wie folgt modifiziert:

    Code
    /usr/local/bin/mjpg_streamer -i "/usr/local/usr/local/lib/mjpg-streamer/input_raspicam.so -fps 24 -x 1024 -y 768 -ex auto -quality 85" -o "/usr/local/lib/output_http.so -n -w /usr/local/www -p 9000" >/dev/null 2>&1 &


    Das Beste: die Patches von Nea wollten nicht, scheinen hier aber enthalten zu sein (habe jetzt keinen richtigen Code-Review gemacht...).
    Mit -ex auto stellt man auto exposure ein, das mir mit input_uvc.so den mjpg_streamer zum Absturz gebracht hat. Nun sind die Farben zwar anders (aber auch viele Parameter da um das ggf. noch anzupassen).


    Der wirkliche Hammer ist aber:
    Der mjpg_streamer braucht jetzt unter 5% CPU-Leistung anstelle der rund 45% zuvor.


    Ob die Abstürze nun ausbleiben werden wohl erst die kommenden Tage und Wochen zeigen...


    ACHTUNG:
    Leider geht das nur mit einer RasPi-Kamera am CSI-Port!!! Wer eine USB-Kamera im Einsatz hat, dem bringt dieser Fork wahrscheinlich nichts...