CPU Last auf ~100% bei Streamdev

  • Hi,
    ich hab ein merkwürdiges Phänomen mit meinem Streamdev Server beobachtet. Wenn ich mit meinem Laptop mit mplayer Live TV schaue geht manchmal die CPU Last auf dem VDR auf fast 100% und das Bild fängt dann auch an zu ruckeln bis hin zum Totalausfall. Zuerst hab ich das mit meinem alten Board beobachtet (PII 266). Komischerweise taucht das jetzt auch mit dem neuen Board (PIII 1000) auf. Was aber besonders merkwürdig ist: Ich kann teilweise ziemlich lange streamen und die CPU-Last dümpelt unter 10% rum. Und ganz plötzlich geht die Last rauf. Dann kann es sein, dass ich trotzdem normal weiterschauen kann und die Last dann auch wieder runter geht, es kann aber auch passieren, dass der Stream zusammenbricht. Mplayer zeigt dann nix mehr, die Last bleibt aber bei ~100%.


    VDR ist 1.3.37
    Linux ist SuSE 10.0
    Streamdev ist 0.3.3-pre3-geni


    Sonstige Plugins: remote, mp3/mplayer, skinelchi, streamdev-client, graphlcd, image, osdteletext


    Graphlcd gibt momentan auf Framebuffer aus (bis das LCD endlich da ist)


    VDRAdmin läuft auf nem anderen Rechner (Fileserver)


    Das Linux boote ich mit PXE vom NFS Server. Das ist auch meine große Befürchtung - root-FS per NFS und streamdev blockieren sich irgendwie gegenseitig. Aber plausibel finde ich die Erklärung auch nicht.


    Die SuSE hab ich so schlank wie möglich aufgesetzt. Es laufen also verhältnismäßig wenig Prozesse. Speicher ist auch reichlich vorhanden (512Mb). Swap gibts natürlich nicht da keine Platte eingebaut ist.


    Kann sich da eine nen Reim draus machen?

  • Hi,


    Streamdev und NFS Root blockieren sich keinesfalls!
    Läuft bei mir super.
    CPU Last aufdem Server ca. 3%
    CPU Last asf dem Clienten (EPIA ME6000!) ca 10%



    Schau bitte mal welcher Prozess die hohe Last verursacht.


    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • VDR 1.3.37 und streamdev aus dem cvs.
    Versuche doch mal alle anderen Plugins zu deaktivieren und eine ungepatchte VDR Version zu benutzen.



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • VDR Admin läuft auf dem Server.
    Bei solchen Problemen ist es immer gut sich von allem "Ballast" zu entledigen, damit man eine Aussage treffen kann. Also am besten nur das notwendigste laufen lassen und dann mal schauen. Eventuell hilft das syslog, denn hier kannst du sehen, welche pid welchem Programmteil zugeordnet ist. VDR Prozesse gibt es auf meinem Server mehrere.


    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Habe gestern auf meinem streamdev client das osdteletext aktiviert - und seit dem ähnliche Probleme:
    VDR 1.3.34, streamdev aus CVS, osdteletext 0.5.1


    Client 1: busybox basierend mit streamdev und dxr3. Lässt sich bei aktiviertem osdteletext nicht mehr runterfahren. Wenn ich versuche den VDR auszuschalten ist nur für ca. 2 Sekunden das Bild weg und läuft dann normal weiter. Muss es nochmal prüfen, aber sieht für mich so aus als ob das shutdown-Script ausgeführt wird. vdr muss ich über kill beenden. Es bleiben aber eine Reihe Zombies, u.a. auch runvdr (vdr selbst ist aber weg). Bei Analyse mit ps/proc und Co konnte ich keinen Schuldigen ausmachen. Noch besser: Das System reagiert weder auf reboot noch auf Strg-Alt-Entf, läuft sonst aber normal weiter. Bleibt nur Stecker ziehen!


    Server: wie bei Dir vdr CPU auf 100%. Im Log laufende ring buffer overflows - selbst als der Client schon lange aus war. Kann allerdings nicht sagen ob die 100% erst aufgetreten sind als ich beim Client den Stecker gezogen habe oder schon vorher. Im netstat wurde die Verbindung zum Client jedenfalls immer noch als established angezeigt. Vermute der streamdev-server verursacht die hohe Last indem er immer wieder versucht Pakete an den nicht mehr vorhandenen streamdev-client zu senden.


    Client 2: normaler PC mit streamdev und softdevice. Hier habe ich bislang keine Probleme mit dem osdteletext feststellen können.


    Jemand eine Idee?

  • Hi schmirl,


    Ist Dein Client ohne DVB Karte?



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Hmmm. Also bei mir steht im logfile gar nix. Und ich benutze das osdteletex ja auch nicht auf dem client. Der "Server" ist mein normaler VDR im Wohnzimmer. Wenn ich abends schlafen geh nehm ich halt den Laptop um noch ein bischen zu gucken. Das mach ich aber unter XP mit dem mplayer. Und eigentlich hat das auch immer prima geklappt. Auch mit dem 266er PII. Das war dann aber noch VDR 1.2.6. So langsam glaube ich das hat was mit dem WLAN des Laptop zu tun. Die Plugins hatte ich nämlich testweise mal alle abgeschaltet. Aber das Problem blieb. Wir haben vor kurzem unser Schlafzimmer umgezogen und ich hab im neuen Schlafzimmer noch kein LAN liegen. Im alten Schlafzimmer lag LAN und darüber hatte ich nie Probleme. Wenn ich das streamdev plugin richtig verstanden habe läuft das ganze über TCP. Und bei Funknetzwerken kommt es ja je nach Empfangslage zu häufigen retransmissions. Bei UDP wäre das nicht so - dafür hätte man Paketverluste. Das könnte die hohe Last erklären. Wenn jedes Paket zig mal gesendet werden muss bis es korrekt angekommen ist...
    Ich werd mir mal temporär ein LAN Kabel ins Schlafzimmer legen und das beobachten. Das mit dem WLAN am Bett find ich eh nicht so prickelnd.

  • Hi schmirl,


    Ich frage, weil ich OSD-TEletext nicht auf dem Clienten zum laufen gebracht habe. Allerdings habe ich eine TT 1.6 im Client, welche aber jedoch nur als MPEG Dekoder benutzt wird.



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Ging bei mir Anfangs nicht weil ich das Verzeichnis für die Videotext-Seiten nicht angelegt hatte (Default: /vtx, ändern mit Plugin-Parameter -d)


    Könnte bei Dir aber auch daran liegen, dass die TT Karte als Primary Device läuft. Der localchannelsprovide Patch aus dem streamdev/patches Verzeichnis sollte dann das Problem beheben.

  • Hi schmirl,


    Vielen Dank. läuft jetzt prima.



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!