Posts by raha

    Da verstehe ich deine Frage nicht so richtig.


    Also das xineliboutput-plugin läuft problemlos parallel zum streamdev-server/client ohne zu mucken und kann dieses auch ersetzen. Wenn Du nur über vdr-sxfe (Linux) deinen VDR-Server verwalten und/oder mit VLC/mplayer (Linux/Win/Mac/weissderGeier...) Fernsehen gucken willst, brauchst kein streamdev-Plugin.


    Das einzige Problem besteht darin, dass man mit dem xineliboutput-Plugin anders als beim streamdev-Server keine Sender aus dem Kanal-Set einer DVB-T Frequenz explizit aufrufen kann, also z.B. http://<VDR-IP>:3000/<Senderkennung>.


    Verstecken geht natürlich net. Du brauchst schon einen offenen Port, zu dem sich die Clients verbinden können, kannst diesen natürlich aber frei bis 65k wählen.

    Hallo vdr-ler,
    habe lange an verschiedenen Lösungen gebastelt, um Live-TV über geringe Bandbreite zu realiseren, hat u.a. zufriedenstellend mit externremux funktioniert.


    Dabei habe ich auch noch eine weitere einfache Lösung mit VLC ( v0.9.8 ) herausgefunden welche darauf basiert, den durch xineliboutput gelieferten Videostrom "on-the-Fly" auf einen anderen TCP-Port zu remuxen.


    Dies hat mehrere Vorteile:
    - ausser vdr-xineliboutput wird nur vlc benötigt
    - einfacher vlc Kommandozeilenaufruf z.B. über skript
    - funktioniert auch mit pvr350-karten, wo externremux bei mir nie ging
    - Ausgabeformat mit vlc leicht anpassbar
    - sowohl der VDR aber auch ein anderer PC im Netz kann remuxen
    - per vdr-sxfe kann der VDR ohne Neustart des Remuxen verwaltet werden (Sender umstellen ...)
    - alles abspielbar, was vlc abspielt


    Es ist - wie fast alles, wenn mans weiss - sehr einfach: VLC greift den von xineliboutput bereitgestellten Stream ab, rekodiert und remuxt ihn und stellt ihn auf einem anderen TCP-Port wieder zur Verfügung. Oder als VLCSyntax:


    cvlc -d http://<VDR-IP>:37890 :http-caching=3000 :sout="#transcode{vcodec=theo,vb=300,scale=1,acodec=vorb,ab=32,channels=1,audio-sync,width=280,height=220}:duplicate{dst=std{access=http,mux=ogg,dst=<VDR-IP>:37899}}"


    Erläuterung:


    cvlc -d
    cvlc ist die Kommandozeilenoption von 0.9.8, startet als Daemon mit -d
    http://<VDR-IP>:37890 :http-caching=3000
    xineliboutput Ausgabeport mit 3 sek. caching
    :sout="#transcode{vcodec=theo,vb=300,scale=1,acodec=vorb,ab=32,channels=1,audio-sync,width=280,height=220}:duplicate{dst=std{access=http,mux=ogg,dst=<VDR-IP>:37899}}"
    vlc Ausgabekette für das Kodieren und gleichzeitiger Streamausgabe des "dünnen" Streams
    auf Port 37899


    Mit Hilfe des revolunet VLC Plugins kann man sehr einfach eine Webseite erstellen und sich im Fenster das Fernsehen anschauen ODER man öffnet halt mit VLC die Adresse http://<VDR-IP>:37899.

    Vielen Dank für die Hilfe, es war eine Mischung aus vielen Kleinigkeiten die dazu führte, dass externremux nicht funktionierte. Hier jetzt meine externremux.sh, die wirklich schnuffich funktioniert:


    #!/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
    mencoder -vf harddup,softskip,scale -zoom -xy 320 -oac mp3lame -lameopts br=32:q=5:mode=3 -ovc x264 -x264encopts bitrate=300:log=0 -o $FIFO -- - &>$OUTLOG


    Mit DVB-T als Quelle und dem revolunet VLC Plugin kann man richtich schön über eine Webseite Internet-fernsehen ... !

    Jo, mit diesem Befehl kommt raus:
    -P "streamdev-server --remux =/etc/vdr/plugins/externremux.sh"
    also das Plugin ist korrekt geladen.


    Da ja im Log auch
    streamdev-server: EOF reading from externremux
    steht, muss er die Datei auch korrekt lesen können.


    Die Rechte sollten auch stimmen, denn mit "su vdr" kann man sich wie folgt anzeigen lassen:
    -rwxr-xr-x 1 root root 438 12. Jan 13:10 /etc/vdr/plugins/externremux.sh


    Dann starte ich das Skript aus der Konsole als Nutzer vdr (der hat zu Testzwecken eine Shell) und bekomme:


    MEncoder dev-SVN-r26940 (C) 2000-2008 MPlayer Team
    CPU: Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz (Family: 6, Model: 15, Stepping: 13)
    CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
    Compiled with runtime CPU detection.
    Reading from stdin...
    success: format: 0 data: 0x0 - 0x0
    vdr@xxx:xxx01$ ============ Sorry, this file format is not recognized/supported =============
    === If this file is an AVI, ASF or MPEG stream, please contact the author! ===
    Cannot open demuxer.


    Exiting...


    Ist ja auch völlig verständlich, denn es gibt keine out.avi die von mkfifo erstellt worden ist.
    Soweit scheint alles zu stimmen.


    Dann habe ich die Zeile
    echo funktioniert >> /tmp/externremux.sh.log
    in die externremux.sh reingeschrieben und wie nicht anders zu erwarten schreibt er auch zweimal
    das Wort "funktioniert" in die Log-Datei.


    Nun bin isch fast am Ende aber es ist mir noch eines aufgefallen.


    Rufe ich im Browser http://localhost:3000/Extern auf muss ich nochmal auf die Kanalgruppe klicken, weil ich eine Kanalgruppierung habe. Könnte es daran liegen?


    Und wie rufe ich den Kanal auf, mit seinem konfigurierten Namen (Das Erste, Phoenix) oder der URL, die mir der Browser anzeigt (http://localhost:3000/Extern/T-8468-258-14) ?

    Vielen Dank, dass Du versuchst, mir zu helfen.


    Meine Frage war ja, ob es exakt mit der Abfrage aus der Proc-List wie ich sie mache bei Dir die Zeile mit den Leerzeichen rauskommt.


    Und das Skript spiet erstmal keine Rolle, wenn er zumindest einen out.avi erstellt.

    Hallochen und danke für die Tipps,
    nochmal kurz zur Konfiguration unter Debian (vdr 1.6, DVB-T):


    Habe eine Datei "/etc/vdr/plugins/plugin.streamdev-server.conf" angelegt und in diese dann
    "-r=/etc/vdr/plugins/externremux.sh" reingeschrieben und den vdr neu gestartet.


    Dann habe ich ich über "ps -lea |grep vdr" die Prozessnummer vom runvdr ausgelesen und über "cat /proc/<ProzessNr>/cmdline" rausbekommen, dass er diese Datei korrekt als Parameter geladen hat (-P"streamdev-server-r=/etc/vdr/plugins/externremux.sh").


    So weit, so gut. Aber mehr auch leider nicht.
    Wenn ich die mir empfohlene Doku richtig verstehe bedeutet dies ja, dass das streamdev-Plugin den Datenstrom in das Dateisystem schreiben kann.


    Habe dann eine externremux.sh angelegt und dies hineingeschrieben


    rm -f /tmp/out.avi
    /usr/bin/mkfifo /tmp/out.avi
    cat /tmp/out.avi | /usr/bin/mencoder -vf harddup,softskip,scale -zoom -xy 320 -oac mp3lame -lameopts fast:preset=standard -ovc x264 -x264encopts bitrate=400:log=0 -o /tmp/out.avi & >/tmp/out.log


    Den mencoder Befehl habe ich an Hand einer nach /tmp kopierten Datei mal probiert und dieser funzt prima.


    Dann mal ausrobiert mit http://localhost:3000/Extern/T-8468-258-14 den transkodierten Stream zu öffnen. Geht nicht, syslog zeigt nur an:


    Jan 12 12:09:53 vdrpc vdr: [16013] streamdev-writer thread started (pid=15778, tid=16013)
    Jan 12 12:09:53 vdrpc vdr: [16014] streamdev-livestreaming thread started (pid=15778, tid=16014)
    Jan 12 12:09:53 vdrpc vdr: [16014] ERROR: write failed: Datenübergabe unterbrochen (broken pipe)


    Mmh, mal alles auf den mkfifo Befehl auskodiert und vdr neu gestartet, aber Fehler bleibt gleich. Also wird doch die out.avi gar nicht erzeugt. Geht also das streamdev-Plugin nicht ?

    hallo vdr-ler,


    trotz langem lesen habe ich bisher nicht die stelle gefunden, wie ich meine /root/externremux.sh beim starten des vdr in debian einbinden kann.


    der streamdev-server läuft fehlerfrei, d.h. die /etc/vdr/plugins/streamdevhost.conf ist richtig konfiguriert.


    wie (und wo) übergebe ich das skript beim starten des plugins ?


    danke für jede Hilfe

    Völlig problemloslos zu realisieren:


    - VDR mit xineliboutput Plugin
    - Win-Client mit VLC, Fernsehen gucken über rtsp:/http://<IP-Adresse-des-VDR>:37890

    Hi,
    das ist ein bisschen sehr langsam für Deinen PC, probier es mal aus mit


    mencoder 001.vdr -vf harddup,softskip,scale -zoom -xy 400 -oac mp3lame -ovc x264 -x264encopts bitrate=600:log=0 -o 001.x264.avi


    oder ohne Optionen mit


    mencoder 001.vdr -vf harddup,softskip,scale -oac copy -ovc x264 -x264encopts bitrate=1000:log=0 -o 001.x264.avi


    um die Geschwindigkeit ohne Skalierung zu testen.


    Audio/Video-Versatz ist bei mencoder Kodierung eigentlich nicht zu beobachten.


    Und guck nochmal vielleicht hier


    http://www.mplayerhq.hu/DOCS/H…ing-options-speedvquality


    Achtung: Das ist hier x264/H264-Kodierung, nach meiner Erfahrung the best wo gibt

    Wenn Du unter Windows die fertigen Aufnahmen konvertieren willst, ist SUPER von erightsoft (OpenSource ffmpeg, ffmpeg2theora, mencoder + Erightsoft grafische Oberfläche) eine schicke Lösung. Re-Konvertiert ziemlich alles nach allem, was ich so kenne.


    Wenn Du direkt nach der Aufnahme konvertieren willst gibt es verschiedene vdr-Plugins oder Du machst Dir einfach ein Skript mit mencoder und ... /recording-hooks/R90.custom zum automatischen Konvertieren einer Aufnahme nach Beenden derselben, z.B.


    mencoder $1/001.vdr -vf spp=2,harddup,softskip,pp=hb/vb/dr/al,scale -zoom -xy 400 -o $1/001.vdr -oac copy -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=700:autoaspect


    Mit vlc definitiv abspielbar. Die mencoder/vlc Doku beschreibt Dir alles was Du brauchst.

    Nach längerem Probieren und Überwachen habe ich festgestellt, dass das vdradmin Plugin vermutlich die Ursache des Problems ist. Nachdem ich dieses deaktiviert habe und nur noch über vdr-sxfe das System verwalte, ist dieser Fehler nicht mehr aufgetreten.

    Ich glaube, die Ursache ist die Modifikation des locales-Paketes in Verbindung mit dem debian-Paket localepurge VOR der Installation des VDR.


    Eine Blitz-Install auf einer alten Büchse brachte den Fehler nicht mehr, wenn ich auf die Veränderung der Spracheinstellungen und die Benutzung von localepurge verzichte.


    Nun denn, wieder etwas schlauer ...

    Das ist ja die krux. Wenn ich über das init-skript ein restart mache, ist alles wieder in englisch, so als wird die Spracheinstellung nicht mehr erkannt wird. Nur ein apt reinstall sagt mir im log, dass er utf-8 erkennt und demzufolge auch deutsches OSD anzeigt, ansonsten meckert er immer über fehlende locales

    oooh mann, wo kann ich denn noch suchen ...


    wie kann man das erklären, dass ein apt reinstall (was ja den prozess neu startet) einmal die sprache richtig einstellt, aber nach dem neustart alles wieder englisch ist ?

    Hallo liebe vdr-ler,


    ich habe auf meiner home-box ein Prob mit VDR 1.6 und der OSD-Sprache. Meine Kiste (ziemlich neu installiert) läuft auf de_DE.UTF-8.


    Der runvdr-Prozess läuft auch mit dieser LANG-Variable, dass habe ich über die environ-Variable in /proc geprüft.


    Allerdings erscheint das OSD-Menü nur und nicht umschaltbar in english, im syslog erscheint immer nur


    Nov 8 20:09:40 pavilux vdr: [9538] unknown locale: 'de_DE'
    Nov 8 20:10:42 pavilux vdr: [9721] found 0 locales in /usr/share/locale
    Nov 8 20:10:42 pavilux vdr: [9721] no locale for language code 'deu,ger'
    Nov 8 20:10:42 pavilux vdr: [9721] no locale for language code 'slv,slo'
    Nov 8 20:10:42 pavilux vdr: [9721] no locale for language code 'ita'
    Nov 8 20:10:42 pavilux vdr: [9721] no locale for language code 'dut,nla,nld'
    Nov 8 20:10:42 pavilux vdr: [9721] no locale for language code 'por'


    Nun kommst ganz dicke. Wenn ich über apt ein reinstall von vdr mache, wird beim ersten Neustart von VDR alles richtig in deutsch angezeigt, die Sprachen sind auch umstellbar.


    Starte ich den VDR wieder neu, ist alles wieder in englisch mit o.a. Fehlermeldung. Eine VDR_LANG Variable in /etc/default/vdr bringt auch nix.


    Kann mir jemand helfen ?

    Hallo alle VDRler,


    ich habe ein 1.6 System mit zwei DVB-T Karten (Philips Semiconductors SAA7133/SAA7135 Chipsatz), bei denen häufiger die Meldung


    /dev/dvb/adapter0/dvr0: Kein passendes Gerät gefunden bzw.
    /dev/dvb/adapter1/dvr0: Kein passendes Gerät gefunden


    im Syslog erscheint. Nun funktioniert kein Streaming und nix mehr. Damit die ganze Schooose wieder geht, muss der PC neu gestartet werden, offensichtlich kann er die DVB Devices nicht mehr erkennen bzw. richtig für die VDR-Benutzung sperren. Benutze ich FEMON -vor dem Neustart -, wird aber auf beiden Karten ein ordentlicher Empfang angezeigt.


    Meine Fragen deshalb an alle:
    Verhaken sich bspw. Streamdev- / und Xineliboutput- Plugin vielleicht ?
    Hat jemand ähnliche oder gute Erfahrungen mit mehreren DVB-T Karten in einem PC ?
    Oder gar Lösungen bei ähnlichen Problemen gefunden ?


    Vielen Dank bereits im voraus!

    ja, die idee mit dem pvrinput plugin war die Lösung der Geschichte, denn das war durch die Update-Orgie irgendwie verlustig gegangen. Neu installiert und schwupps - alles geht wieder wie erwartetet.


    Vielen Dank !

    Hallo liebe vdrler,
    ich hoffe auf den ansatz für eine lösung des o.a. problems.


    Basis: debian sid (sidux) aktuell inkl. Kernel mit vdr 1.6.0.1 und pvr-350
    Problem: ums verrecken findet die kiste mit wirbelscan keine kanäle mehr


    könnte allerdings sein, dass dies nicht unmittelbar mit dem heutigen update in zusammenhang steht


    was habe ich geprüft (siehe anlage) ?
    laden der ivtv firmware, ok
    device erstellt, ok
    vdr geladen (ich verwalte die kiste mit vdr-sxfe)


    scan protokoll findet scheinbar zwar sender, kann die aber nicht "locken", d.h. es wird nix angezeigt.


    nun hoffe ich auf hilfe und habe in der anlage mal die logs zusammengestellt.