Mal wieder externremux.sh, nur für Profis ?

    Hallo vdr-ler allesamt,


    ich benutze debian sid mit vdr 1.7.27 und habe bei einer Neuinstallation - ich hab das wohl schon vor ewigen Zeiten mit einer vorherigen Version hinbekommen, jetzt gehts mit 1.7.27 / streamdev-server 0.6 nicht mehr - das Problem dass ich das externremux nicht zum Laufen bekommen.


    Ich verwende die externremux.sh (1) aus dem vdr-wiki und eine speziell angepasste mencoder Option. Da ich genau weiss - ich hab das getestet - das die mencoder Befehlszeile aus der Shell heraus funktioniert kann es IMHO nicht an den mencoder Optionen oder Libs liegen. Dies scheint der Blick in das Log zu bestätigen (ab Zeile 82), welches wie folgt aussieht



    Ich schliesse daraus, das mencoder beginnt zu konvertieren und nach ca 3,5 Sek. (ab Zeile 107) abbricht, da offensichtlich die PIPE zur FIFO zerschossen wird. Das schliesse ich aus dem VDR Logfile, denn da drin steht:


    Code
    cat: write error: Broken pipe
/etc/vdr/plugins/externremux.sh: line 12: rm -rf /tmp/externremux-13700: No such file or directory


    Meine externremux.sh sieht so aus wie im Wiki (abgesehen bis auf die Bash Shell):


    Bash
    #!/bin/bash
umask 077
tmpdir=${TMPDIR-/tmp}/externremux-${RANDOM:-$$}
FIFO=$tmpdir/out.avi
OUTLOG=$tmpdir/out.log
mkdir -p $tmpdir || exit 1
mkfifo $FIFO
(cat $FIFO; rm -rf $tmpdir) &
mencoder <OPTIONEN> -o $FIFO -- - &>$OUTLOG


    Ja, und nun verliessen sie ihn. Wer hat eine Idee zur Lösung des Problems? Umgebungsvariablen der Shell? Cache? FIFO Parameter?
    Ich würde mich über jeden Hinweis freuen.

    Ich glaube mich zu erinnern das die neuere streamdev versionen die HTTP header nicht mir senden in Zusammenhang mit EXT.
    Dafur hat Schmirl ein neues externremux.sh mitgeliefert der dass wohl macht.


    Greetz Carel

    Hi carel, Danke für die Info.


    Wie kann ich den Schmirl mal auf das Problem aufmerksam machen? Ich habs nochmal nach heutigen DU versucht aber es funtkioniert nicht.


    Die Syntax des externremux-Skriptes kann IMHO nicht falsch sein, denn das Skript funktioniert tadellos, wenn ich mit den mencoder-Optionen "-lavf mpeg -ovc copy -oac copy" ein reines "Durschschleifen" des TV-Datenstroms ohne Rekodieren konfiguriere. Und das mencoder Kodierungs-Skript kann nicht falsch sein, da es auf Shell-Ebene ausserhalb des VDR mit der Aufnahme-Datei ebenfalls geht.


    Was mich furchtbar irritiert und ärgert, sind die Meldungen aus den Logs



    a) VDR-Log

    Code
    cat: write error: Broken pipe


    b) SYSLOG

    Code
    vdr: [8507] ERROR: read from client (HTTP) <ip-adresse>:50058 failed: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
vdr: [8507] streamdev-server: externremux process won't stop - killing it
vdr: [8507] ERROR: read from client (HTTP) <ip-adresse>:50059 failed: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
vdr: [8507] streamdev-server: externremux process won't stop - killing it
vdr: [8507] ERROR: read from client (HTTP) <ip-adresse>:50060 failed: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
vdr: [8507] streamdev-server: externremux process won't stop - killing it


    c) out.log (Abbruch nach 3,5 s Kodieren und Neustarten des gesamten Vorganges)


    d) VLC Log (beim Versuch, http://<ip-adresse>/EXT/T-8468-258-15 zu öffnen)


    Wenn ich den Datenverkehr mit wireshark trace, sehe ich ganz genau, dass da ein TCP Paket mit RST-Flag ankommt was offenbar zum Abbruich der PIP führt. Es ist zum Mäuse melken...

    ... geht auch nicht, hier das Log:


    Hallo,
    ich nutze auch seit langer Zeit VDR und hin und wieder streame ich mal mit externremux.sh -> bislang lief alles. Jetzt unter streamdev 0.6.0 und Ubuntu 12.04 mit der "original" externremux.sh habe ich das gleiche Problem wie du: nach ca. einer Sekunde bricht der Stream mit "Broken pipe" im Log ab.


    Hast du schon eine Lösung?


    Grüße
    Christopher

    easyvdr 3.0 als headless server
    Intel coreI3 - 64GB SDD + 3TB HDD - 8 GB RAM - DVB-C (4 Tuner DigtialDevices + Terratec Cinergy HTC XS)

    Hi Christopher,


    es freut mich, einen "Mitleidenden" zu finden, aber eine Lösung habe ich bisher nicht gefunden. Schade, dass der schmirl oder andere das hier vielleicht noch gar nicht gelesen haben.

    Hi ballerbu,


    das würde ja bedeuten, dass rm nicht im Suchpfad wäre. Ist es aber, denn in der Shell wird rm gefunden. Ich probiere es mal, habe aber wenig Hoffnungen.


    Ich sehe eigentlich nur zwei Lösungsansätze: Entweder ist es irgendwas mit den Umgebungsvariablen der Shell, z.B. das für Unteraufrufe nicht mehr genügend Speicher zur Verfügung steht o.ä.. Oder die in den mencoder einkompilierten Libs für die Kodierung bzw. der durch diese erfolgte Aufruf von x264 Routinen bringt die PIPE zum abwürgen. Habe aber keinen blassen Schimmer wie man das debuggen könnte.


    Und wie ich schon geschrieben habe kann das Skript und der mencoder-Aufruf nicht falsch sein, denn ohne Kodieren (mit der copy Option, auch im "Original"-externremux Skript als Option enthalten) funktioniert es genauso tadellos wie auch der mencoder-Befehl als Aufruf in einer Bash-Shell mit den x264 Kodieroptionen. Und mit ffmpeg an Stelle von mencoder geht es in der Bash-Shell hervorragend und im externremux-Skript wieder nicht.


    Nun ja, eben halt zum Mäuse melken.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden