Webcam friert ein

edited January 18 in Repetier-Server
Hallo liebe Forengemeinde,

ich habe gerade einen Druck laufen über insg. 109 Stunden, aktuell bei etwa Stunde 80.
Seit einigen Stunden allerdings ist irgendwie der mjpg-streamer eingeschlafen. Der Aufruf im LAN über Port 9000/stream_simple.html liefert nur alle etwa 5 Sekunden sehr widerwillig ein Bild (erinnert so ein bisschen an 1200bd Akustik-Koppler), ebenso wie in der Server-GUI auch.
Ein Restart des Streamers via "systemctl restart mjpg_streamer" hat ebenso wenig Erfolg gebracht wie ein Neustart des WLAN auf dem PI4 sowie ein Neustart meines WLAN-Netzes.

An dieser Stelle wollte ich jetzt nicht wild weiter experimentieren, da ich echt Schiss habe, den Druck zu schräddern...

Jemand eine Idee, welchen Dienst ich noch ohne Gefährdung des laufenden Drucks neu starten könnte? Den Webserver (was läuft denn da überhaupt?) vielleicht? Oder noch was anderes? Konnte dazu hier über die SuFu nichts finden...

Bin für jeden Hinweis dankbar...


Comments

  • Ich würde erst mal mit
    top
    nachsehen wer CPU Zeit oder Speicher über maßen beansprucht. Hört sich ja an als ob es geht aber nur langsam. Auch eine Frage ist wieso reicht die bandbreite oder cpu nicht mehr.

    pi cam ist allerdings seit bullseye etwas kompliziert, da es ja nach Grafiktreiber unterschiedliche Lösungen im mjpg_streamer gibt. Hab gerade einige Wochen damit verbracht das zu optimieren fürs nächste bookworm image wo es nur noch den neuen Garfiktreiber gibt.

    Prinzipiell startet
    startAllCams
    alle streamer neu. Im neuen Grafiktreiber nutzt er software komprimierung und wenn andere Processe alle CPU beanspruchen (was nicht sein sollte) könnte es langsamer sein insbesondere wenn die Auflösung hoch ist.
  • Danke erstmal für den Tip. startAllCams hat allerdings keine Änderung bewirkt.
    Wenn ich mir die Tasks via htop anschaue, ist da nichts Auffälliges. CPU Durchschnitt liegt bei 0,28/0,37/0,31, Speicherlast bei rund 6% (390mb/8gb)  und die einzigen Tasks, die etwas mehr als 1% verbraten sind "mutter" als Sub von LightDM (3-15% stark schwankend) und der RS selbst (2-10% schwankend). Dann wäre da noch umzu 5% der Chromium und der Streamer mit 1% etwa... Das war's ... Nix Besonderes oder auffälliges also...
  • In der Tat unauffällig und wie es sein sollte.

    Wenn er am lan hängt würde ich auch vermuten das es nicht die Bandbreite ist, oder ist er am wlan?
  • edited January 19
    ... indirekt ... Er hängt mit einem kleinen Switch an einem FritzRepeater als Gateway. Das ist aber auch unauffällig. Hatte ich auch schon mehrfach neu gestartet (das ganze System), obwohl der am gleichen Switch hängende Rechner die volle Bandbreite ausgibt; sogar die Ports am Switch habe ich schon getauscht...

    (hier viele ganz böse Schimpfwörter denken)... Ich muss den Druck abbrechen... Zwei Tage für die Katz... ABS ist ne Bitch :s
  • Ja ABS ist echt schwierig zuweilen.

    Mal gespannt ob sich dann was ändert oder ob reboot was ändert. Wobei die relevante software ja schon mehrfach restartet wurde und nicht schneller wurde.
  • Ja, ich werde berichten. Dauert aber. Haben heute sehr schweren letzten Weg mit unserem kleinen Hund zu bewältigen :'(

  • So, kleine abschließende Info zu dem Problem:
    Dieser Fehler ist inzwischen nur einmal erneut aufgetreten. Zwischenzeitlich habe ich zudem eine zweite CAM dran (Logi c270) und bisher keine Probleme.
    Dieser Fehler gehört offensichtlich zur Gruppe der gemeinsten und hinterhältigsten Fehler, da er sich irgendwie nicht provozieren und/oder reproduzieren lässt. Neustart Kamera-Dienste bringt nichts, ebenso wenig wie Neustart LAN/WLAN. Es hilft tatsächlich nur ein kompletter Reboot... Im laufenden Druck nicht wirklich sinnvoll...
    Ich werde das beobachten und mich ggf. noch mal melden. Aktuell aber war's das erstmal...

    DLzG
    Micha

    PS, OT: Am PI angeschlossenen Touchscreen kalibrieren? Ist Rasbian-Geschraffel... oder? Bin ich noch nicht hinter gestiegen. Derzeit muss ich immer etwas über die Schaltflächen tippen...
  • Log dich in Global Einstellungen->Terminal am pi ein und gehe auf Touchscreen und dann auf Touchscreen kalibrieren dann sollte xinput_calibrator gestartet werden. Lies die Text durch was zu tun ist.
  • edited January 25
    Danke für den Hinweis. Da muss ich mich mal durchfummeln...
    Bekomme ich nicht hin :s
    Auf dem Display kann ich zwar treffgenau die Kreuze antippen (mit einem Stift), aber in RS liegt das immer noch daneben resp. im oberen Bereich zu niedrig (ich muss darüber tippen um zu treffen). Auch Änderungen in der 99-calibration.conf haben keinerlei Auswirkungen, auch nicht, wenn ich da totalen Quatsch eintrage (nach Neustart versteht sich)
    Display ist ein ELECROW 5" mit 800x480 Rev3.3 (https://www.elecrow.com/hdmi-5-inch-800x480-tft-display-with-automatic-backlight-control.html), allerdings der Vorgänger davon mit der fehlenden Backlight-Kontrolle


  • Das ist der normale Web für Linux. Aber wir starten es immer für das default input device. Was gibt
    xlibinput_calibrator --list
    aus? Wenn es mehrere gibt nimmt er vielleicht das falsche. Oder es gibt noch eine andere Datei in /etc/X11/xorg.conf.d in der die Kalibrierung gespeichert wird.
  • edited January 25
    Jetzt wird es interessant:
    Als PI eingeloggt:
    pi@3D-Repetier-PI:~ $ xlibinput_calibrator --list
    ERROR: unknown parameter '--list'
    ...
    xlibinput_calibrator --list-devices       show the devices availables
    Ok, dann also ...
    pi@3D-Repetier-PI:~ $ xlibinput_calibrator --list-devices
    Speicherzugriffsfehler
    pi@3D-Repetier-PI:~ $
    Dann als root:
    root@3D-Repetier-PI:~# xinput_calibrator --list
    Unable to connect to X server
    root@3D-Repetier-PI:~#
    ... und dann ...
    root@3D-Repetier-PI:~# xinput_calibrator --list-devices
    Unknown option: --list-devices
    ...
    root@3D-Repetier-PI:~#

    Das ist irgendwie vollkommen schräg...

    Ist übrigens das PI-Image. Hinzu gekommen ist lediglich Samba und WSDD

    In /etc/X11/xorg.conf.d/ befinden sich nur zwei Dateien:

    - 10-blanking.conf (war schon da)
    - 99-calibration.conf (habe ich angelegt)

    In Letzterer steht aktuell das hier drin (die Quatschwerte hatte ich wieder gelöscht; Verschiedenes aus dem Forum geklaut und probiert)

    Section "InputClass"
        Identifier "calibration"
        MatchProduct "ADS7846 Touchscreen"
    #    MatchProduct "raspberrypi-ts"
            Option "MinX" "65003"
            Option "MaxX" "-205"
            Option "MinY" "64545"
            Option "MaxY" "-717"
            Option "SwapXY" "0"  # unless it was already set to 1
            Option "InvertX" "0"  # unless it was already set
            Option "InvertY" "0"  # unless it was already set
    EndSection

    EDIT sagt:
    In der Anleitung zum Display ist angegeben, das folgende Zeile in die /boot/config.txt gehört:
    dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900
    M.E.sind die letzten drei Zeilen in der calibration.conf überflüssig, da bereits im Overlay deklariert. Komisch finde ich aber die Angaben in der Overlay-Zeile zu den max- und min Werten, welche um den Faktor 10 kleiner sind als in der calibration.conf...
    Und, wenn ich das nicht falsch verstehe, sollte das OS die ermittelten Werte nach Kreuzchen-jagen auf dem Kalibrier-Schirm doch in die calibration.conf schreiben, oder nicht?





  • CBX_Micha said:
    Und, wenn ich das nicht falsch verstehe, sollte das OS die ermittelten Werte nach Kreuzchen-jagen auf dem Kalibrier-Schirm doch in die calibration.conf schreiben, oder nicht?
    Ich habe die Datei jetzt noch mal neu angelegt als Benutzer PI und Gruppe USERS mit Rechten 0777... Keine Änderung. Einträge werden ignoriert und (falls das so soll) nicht nach Häkchen-jagen aktualisiert.

    Ich geb's erstmal auf...
  • Möglich das deine cmdline.txt Werte das überschreiben oder der Treiber so nicht im xserver konfiguriert werden kann. Die Werte
            Option "MinX" "65003"
            Option "MaxX" "-205"
            Option "MinY" "64545"
            Option "MaxY" "-717"
    Machen jedenfalls keinen Sinn. minx muss kleiner als maxx sein. 
    Du kannst den cursor in touchscreen einstellungen aktivieren, dann siehst du wo linux denkt das du klickst und von da deine cmdline.txt werte verbessern. Ich nehme mal an es ist nur ein Versatz?
  • Ja, da hast Du recht. Die Werte machen so keinen Sinn. Nach Häkchen-jagen bekomme ich auch andere Werte, die sich um die aktuell eingetragenen Werte bewegen:
    Option "MinX" "2500"
    Option "MaxX" "63000"
    Option "MinY" "5400"
    Option "MaxY" "64500"
    Aber wie gesagt ändern diese Einträge nichts. Ich hatte auch seit Stunden die Vorgaben in der Herstellerzeile mit den Werten gelöscht und nur den vorderen Teil stehen lassen. Auch das wird ignoriert.
    #dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=1,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900
    dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=1,swapxy=0,pmax=255,xohms=150
    Erklärt sich mir irgendwie nicht...

    Repetier said:
    Du kannst den cursor in touchscreen einstellungen aktivieren...
    öhhhh... Wie denn? Wo denn? Was denn?

    Und ja, aber der Versatz ist nicht linear. Auf der X-Achse scheint es zu passen, die Y-Achse passt unten, aber je höher man im Bildschirm kommt, umso weiter weicht Ziel und Treffer voneinander ab.


  • Auch in dem repetier-setup im touchscreen Menü - ist der Punkt Mouse.

  • Damit man alternativ eine Maus anschließen kann.
  • edited January 25
    ... ich weiß nicht so recht, was Du meinst. Das mit der Kalibrierung muss ich von der Shell aus machen. Einen Menüpunkt gibt es da bei mir nicht im GUI, auch nicht für die Maus...
    Vergiss was ich gesagt habe... Ich doof :#
  • edited January 25
    Ok, nach etlichem Gefummel läuft es nun.
    Die Installation des nigthly funktioniert bei mir aus der RS-Konsole nicht, aber aus der SSH-Shell. Nach Update auf die nighly konnte ich nunmehr erneut eine Kalibrierung des Touchscreens durchführen und alles ist schön.
    Irgendwie scheint da irgend etwas gefehlt oder zerschossen gewesen zu sein, was sich durch das Update wieder gerade gezogen hat...
    Allerdings geht das sofort wieder in die Büx, wenn man den weiter oben erwähnten Overlay-String incl. der min/max-Werte für X&Y benutzt... warum auch immer.

    Also vielen lieben Dank für die tatkräftige Unterstützung... Endlich haben die Zielversuche ein Ende B)
  • Ja update aus terminal im server geht nicht weil dabei der server beendet wird was den installer beendet:-)
  • Repetier said:
    Ja update aus terminal im server geht nicht weil dabei der server beendet wird was den installer beendet:-)

    Jo, hab' ich bemerkt o:) Aber so ist das mit mir: Wenn's Fallstricke zu finden gibt, bin ich immer ganz vorne mit dabei >:)
Sign In or Register to comment.