vdr-sxfe: Das unbekannte Wesen....

xineliboutput hat zwei Betriebsarten: Das 'local frontend' startet als VDR-Plugin zusammen mit dem VDR, und das 'remote frontend' startet VDR erst mal blind (oder mit einem anderen Frontend / einer FF-Karte / etc), und erlaubt dann das Verbinden mit einem reinen Frontend-Programm (dh. vdr-fbfe, vdr-sxfe oder angepasste xine-Versionen) über das Netzwerk. Egal in welchem Modus, das OSD und das Videosignal wird immer zusammen ausgegeben. Verbindet sich ein Remote-Frontend, wird ein eventuell aktives lokales Forntend so lange inaktiv.

Die -fbfe Frontends benutzen das Kernel Framebuffer Device, und brauchen daher keinen laufenden X-Server. Die -sxfe Frontends benutzen diverse Video-Erweiterungen des X-Servers, laufen als im Fenster des X-Server.

Gruß,

Udo

dietmar:

vdr mit xineliboutput mit reinem remote frontend:
vdr ... -P"xineliboutput -l none --remote=37890" ..

auf dem remoteclient (in meinem fall verwende ich nur X nicht fb):
./vdr-sxfe xvdr://ip-des-vdr:37890

voraussetzung: xine-libs - am client "xineplug_*.so" im "rundir", IP des clients in svdrphosts.conf -- weiterführende infos siehe xineliboutput-README/wiki - x-server wird bei vdr-sxfe benötigt

so die theorie.

Urig:
so wie oben beschrieben starte ich xineliboutput und vdr-sxfe. vdr-sxfe findet auch den server und verbindet sich schön (via tcp). allerdings bekomme ich einfach kein bild am client. immer nur das "no signal" bild und auf der stdout:
"[input_vdr] No data in 8 seconds, queuing no signal image"

was mache ich falsch oder habe ich übersehen??

bin dankbar für jeden weiterführenden hinweis!!!

gruß, ciax

Die tcp-Verbindung ist nur die Kontrollverbindung, die eigentliche Videoübertragung läuft per UDP im Multicast-Adressbreich, ich glaube über 224.0.1.9:37890 (Multicast, d.h. das ist die Sende- und Empfangsadresse gleichzeitig). Schau mal mit netstat o.ä. nach, ob Daten raus gehen, und ob sie auf dem Zielrechner ankommen. Eventuell stört eine Firewall, oder die Multicast-Unterstützung fehlt im Kernel.

Sollte gar nichts gehen, kann man per Kommandozeile auch tcp-Verbindungen und klassische udp-Verbindungen auswählen, siehe "Available transports for video/audio" im README.

Gruß,

Udo

Urig

Hallo.

Kann es sein, das man für eine lokales Frontend auch die "Multicast-Unterstützung" im Kernel benötigt?

Mein Problem ist, das ich zwar Aufnahmen anschauen kann, aber von der ss2 immer ein no signal bekomme.

Hi ihr Xine-Experten! Ich null koma nix kapische von dat allet!
Könnte ich vielleicht einen klitze kleinen Teil eurer Aufmerksamkeit auf dieses einer meiner Problemchen abzweigen?

Zitat

Original von ciax
so wie oben beschrieben starte ich xineliboutput und vdr-sxfe. vdr-sxfe findet auch den server und verbindet sich schön (via tcp). allerdings bekomme ich einfach kein bild am client. immer nur das "no signal" bild und auf der stdout:
"[input_vdr] No data in 8 seconds, queuing no signal image"

was mache ich falsch oder habe ich übersehen??

bin dankbar für jeden weiterführenden hinweis!!!

gruß, ciax

Alles anzeigen

Versuch doch mal mit weniger Plugins zu starten (?).
Hintergrund:
Ich habe mal easylinux mit xineliboutput und vdr-fbfe in einer VMware gestest, und das gleiche Verhalten gehabt wie bei dir.
Bei deaktivieren fast aller Plugins funktionierte es dann (danach habe ich die Pluginliste wieder erweitert), ich habe mir damals nicht die Zeit genommen herauszufinden welches Plugin in Verbindung xineliboutput nicht funktionierte .

Zitat

Original von Urig
Die tcp-Verbindung ist nur die Kontrollverbindung, die eigentliche Videoübertragung läuft per UDP im Multicast-Adressbreich, ich glaube über 224.0.1.9:37890 (Multicast, d.h. das ist die Sende- und Empfangsadresse gleichzeitig). Schau mal mit netstat o.ä. nach, ob Daten raus gehen, und ob sie auf dem Zielrechner ankommen. Eventuell stört eine Firewall, oder die Multicast-Unterstützung fehlt im Kernel.

Sollte gar nichts gehen, kann man per Kommandozeile auch tcp-Verbindungen und klassische udp-Verbindungen auswählen, siehe "Available transports for video/audio" im README.

Gruß,

Udo

Alles anzeigen

Hallo Urig!

Danke für deine Hinweise! In der Tat - zwischen Client und xineliboutput (vdr-Server) steht eine Firewall. Problem ist nur, daß ich keine Broadcasts bzw. Multicasts über diese propagieren kann (Client und Server liegen in unterschiedlichen Subnets - Multicast wird von der FW nicht unterstützt). Meine Versuche konnte ich aus diesem Grund bis jetzt nur via TCP unternehmen. Dabei werden auch 2 separate TCP-Connections "established" (Steuer und Datenkanal - Danke für den Verständnis-PushUp!). Totzdem kein Bild!

Auch wenn ich UDP am vdr in der plugins-conf (für xineliboutput) aktiviere, wird leider kein UDP-Port auf meiner vdr-Box gebunden. Sonst bliebe ja noch der Weg über TCP (Steuer-) und UDP (Datenkanal).

Auszug aus xineliboutput-README:
------------------------------------------------
Available transports for video/audio

--> udp Use UDP unicast for data and TCP for control.
------------------------------------------------

Allgemein sollte "Multicast" im Kernel aktiviert sein - dies ist es normalerweise auch bei den gängigen Kernelversionen (in meinem Fall Ubuntu). Multicast-Router muß nicht dabei sein.

vdrchuck: wenn alles nichts hilft, werde ich doch noch "try & error" probieren und einmal schauen, wie's ohne den ganzen anderen plugins läuft. Ich werde berichten..

Danke an Euch! CiaX

Hallo nochmal!:

Leider habe ich keinen Erfolg mit dem xinliboutput-Plugin.

Urig:
Ich habe mir die ganze Sache nochmal angesehen (zwecks Protokoll):

vdr 1.4.4-2
xineliboutput-1.0.0pre6 (inkl. cvs update im src-dir)

varianten in xineliboutput plugin-conf:
* nur tcp
* nur udp
* tcp + udp
* tcp + udp + rtp (multicast geht ohnehin nicht über 'meine' FW)
* announce "broadcast"

--> kein Erfolg!

TCP: client-aufruf: "vdr-sxfe xvdr:tcp://ip-des-vdr:37890" (--> control- und datastream werden via tcp aufgebaut und sind im "established state")

--> "no signal"-Bild / [input_vdr] No data in 8 seconds, queuing no signal image

syslog am vdr-server:
----------
Dec 21 18:02:03 oldbox vdr: [17874] [xine..put] Data connection (TCP) requested
Dec 21 18:02:03 oldbox vdr: [xine..put] cBackgroundWriter initialized (buffer 512 kb)
----------

UDP: client-aufruf: "vdr-sxfe xvdr:udp://ip-des-vdr:37890" (--> controlstream wird via tcp aufbgebaut - datastream wird via udp vom vdr-server zum(!) client aufgebaut)

--> "no signal" / [input_vdr] Data stream connected (UDP)

syslog am vdr-server:
----------
Dec 21 18:07:49 oldbox vdr: [17874] [xine..put] Trying UDP connection ...
Dec 21 18:07:49 oldbox vdr: [17874] [xine..put] Client address: ip_des_clients
Dec 21 18:07:49 oldbox vdr: [17874] [xine..put] setsockopt(SO_SNDBUF): got 210944 bytes
----------

Das ganze Spiel wiederholte ich local am Server - genau der selbe Effekt!

vdrchuck
Ich habe auch deinen Ratschlag befolgt und alle plugins bis auf "remote" weggelassen - nep - geht nicht!

Bin leider am Ende mit meinem Latein -- vielleicht liegt's noch an der Buffegröße, was ich aber nicht vermute.

Ihr habt vermutlich auch keinen Hint mehr parat?!?

CiaX

.. kein tipp weit und breit?

Um es noch einmal klar zusammen zu fassen: vdr-sxfe und vdr-fbfe sind eigenständige Programme, die auf der xine-lib und auf dem xine-Plugin 'xvdr' aufsetzen.

Ich verwende bei mir durchgehend libxine-1.1.1 (und die dazugehörige -dev) aus fertigen Binärpaketen, und kopiere daher folgende Dateien aus dem xineliboutput-Pluginverzeichnis auf die jeweiligen Zielrechner:

xineplug_inp_xvdr.so => /usr/lib/xine/plugins/1.1.1/
xineplug_post_autocrop.so => /usr/lib/xine/plugins/1.1.1/post/
vdr-fbfe => /usr/local/bin/
vdr-sxfe => /usr/local/bin/

Die genaue Position von /usr/lib/xine/plugins/1.1.1/ kann sich je nach System unterscheiden, und Binärkompatibilität zu verschiedenen xine-Versionen und Distributionen würde ich mal nicht erwarten.

Gruß,

Udo

Ich will nicht sagen , dass ich es besser kann aber da ich gerade
selber xinelibout anteste und erst nach verzweifelten
2 Stunden nen Bild bekam aber WIKI und README kann man
knicken.
VDR "MUSS" man mit Parameter "-l none" starten und die
Autodetection im Makefile sollte man weglassen.
Stattdessen einfach nur nen CLIENT=1 bzw. SERVER=1 .
Damit erspart man sich das fehlerhafte Kompilieren , wenn libxine
auffen Server drauf ist aber eben nicht die geeignete Version.
Wobei man libxine fuer den Server net braucht. etc. hier laeuft es jetzt

Vielleicht hilft ja die Kurzanleitung einigen (Server/Client),
speziell fuer Kanotix rc4:
Serverseite mit 1 x FF-Karte:
==================
Vorm Kompilieren vom Plugin im Makefile aendern:
XINELIBOUTPUT_X11= 0
XINELIBOUTPUT_FB = 0
XINELIBOUTPUT_XINEPLUGIN = 0

VDR starten mit :
./vdr -P'xineliboutput -l none'

Dann im OSD Einstellungen machen (Client erlauben , Nur TCP ist interessant)

Clientseite:
Kanotix Live-CD starten , auf VDR klicken,
IP aendern (muss die vom Server sein ;)) ,
dann auf obersten Eintrag xineplayer klicken.
Wenn "No signal" erscheint , dann noch auffen Server unter
Einstellungen/DVB das Device umschalten und uebers Bild freuen.

Zitat

Original von Morone
Wenn "No signal" erscheint , dann noch auffen Server unter
Einstellungen/DVB das Device umschalten und uebers Bild freuen.

das war'S Morone!

sollte unbedingt ins WIKI!

ciax

ps: da sucht man an stellen .. und dann sowas!

dank(!) für das xineliboutput-plug .. funktioniert nun (nach einem stück recherche) ziemlich ok, wenn auch nicht voll stabil (--> osd (client-abstürze bei "tcp" remote-keyboardbedienung..insb.bei setup/dvb-dev wechsel) - aber das kann woanders liegen -> XKeySym./remote.conf)

also noch kurz mein beitrag ..

udp: läuft nicht wirklich gut (buffer > 30Kb error / udpsched - am server .. 'core' nach dieser meldung am client- egal)

tcp: wie Morone beschrieben + Urig's hints zu den libs!

bei mir mit:
xinelib 1.1.1 am server (plug damit compiliert - 1.0.0pre7).
xinelib 1.1.2 am client (frontends - libs)

@FW/Subnets/NAT

damit macht xinliboutput ziemlich probleme ..

zwischen subnets (server & client in unterschdl. nets) darf kein NAT über FWs laufen. das vereinbaren der sockets (data-/controlchannel) dürfte wohl "native" im protokoll implementiert sein? die 2 netze sollten sich via routing kennen..

hallo, da bin ich nochmal.

leider muß ich meine erfolgsbotschaft bzgl. xineliboutput-plug revidieren.

der tcp-stream wird schön aufgebaut. auch das OSD ist sichtbar und man kann via keyboard in ihm steuern. allerdings stürzt der client "vdr-sxfe" bei jeglicher 'härteren' aktion im osd mit einem core-dump ab.

was immer zu einem absturz führt, ist wenn per keyboard ein senderwechsel durchgeführt wird. aber nicht nur das - wenn per remote am originalen vdr (server) der sender gewechselt wird (ohne aktion am vdr-sxfe client), stürzt der client auch komplett mit "core dump" ab.

meine genutzten versionen sind weiter oben beschrieben. ich hab leider keine ahnung, welches schräubchen ich noch drehen kann, um dieses plugin funktionstüchtig zu machen.

so nebenbei: mit streamdev zu streamen macht kein problem (ist aber nicht sonderlich konfortabel).

für weiterführende hilfe wäre ich sehr dankbar!!

.. nach langem hin und her, läuft's nun letztendlich!

Zitat

Original von ciax
dank(!) für das xineliboutput-plug .. funktioniert nun (nach einem stück recherche) ziemlich ok, wenn auch nicht voll stabil (--> osd (client-abstürze bei "tcp" remote-keyboardbedienung..insb.bei setup/dvb-dev wechsel) - aber das kann woanders liegen -> XKeySym./remote.conf)

also noch kurz mein beitrag ..

udp: läuft nicht wirklich gut (buffer > 30Kb error / udpsched - am server .. 'core' nach dieser meldung am client- egal)

tcp: wie Morone beschrieben + Urig's hints zu den libs!

bei mir mit:
xinelib 1.1.1 am server (plug damit compiliert - 1.0.0pre7).
xinelib 1.1.2 am client (frontends - libs)

@FW/Subnets/NAT

damit macht xinliboutput ziemlich probleme ..

zwischen subnets (server & client in unterschdl. nets) darf kein NAT über FWs laufen. das vereinbaren der sockets (data-/controlchannel) dürfte wohl "native" im protokoll implementiert sein? die 2 netze sollten sich via routing kennen..

Alles anzeigen

alle meine geschilderten probs, lagen daran, daß xineliboutput nicht sonderlich tolerant gegenüber unterschiedlichen xinelibs ist - es ist meinen erfahrungen zufolge nötig, den client [(hier: "vdr-sxfe") compiliert am server (vdr) mit 'xinelib-version-xy'] auch am client-pc unter installierter 'xinelib-version-xy' laufen zu lassen [-- getestet zwischen ubuntu "edgy eft"-server <-> -client == yes / zwischen ubuntu "edgy eft" (client) <--> "dapper" (server) == no --]

client via tcp -- funkt!
client via udp -- stürzt oft ab (liegt event. auch an Netz-BB -- buffer leer/handling)

vielleicht hilft's ja jemanden

Urig:

du hast's eh schon beschrieben (hier nun eine "praktische unterlegung"

Zitat

Original von Urig
Um es noch einmal klar zusammen zu fassen: vdr-sxfe und vdr-fbfe sind eigenständige Programme, die auf der xine-lib und auf dem xine-Plugin 'xvdr' aufsetzen.

Ich verwende bei mir durchgehend libxine-1.1.1 (und die dazugehörige -dev) aus fertigen Binärpaketen, und kopiere daher folgende Dateien aus dem xineliboutput-Pluginverzeichnis auf die jeweiligen Zielrechner:

xineplug_inp_xvdr.so => /usr/lib/xine/plugins/1.1.1/
xineplug_post_autocrop.so => /usr/lib/xine/plugins/1.1.1/post/
vdr-fbfe => /usr/local/bin/
vdr-sxfe => /usr/local/bin/

Die genaue Position von /usr/lib/xine/plugins/1.1.1/ kann sich je nach System unterscheiden, und Binärkompatibilität zu verschiedenen xine-Versionen und Distributionen würde ich mal nicht erwarten.

Gruß,

Udo

Alles anzeigen

.. das mit dem Subets/NAT(oben erwähnt) trifft allerdings schon zu - dieser thread wäre für mich "gelöst" und könnte geschlossen werden (wenn auch dietmar zustimmt)

Hi ihr xineliboutput Experten. Bei mir läuft eigentlich alles super. am Server starte ich VDR mit:

/usr/local/bin/vdr -L /usr/local/src/VDR/PLUGINS/lib/ -c /etc/vdr -E /var/vdr -P "xineliboutput --local=none --remote=37890" -P "streamdev-server" -P "epgsearch" 2> /dev/null &

Am Client verwende ich:

xine "xvdr:udp://server.int#nocache;demux:mpeg_block"

Funzt eigentlich super!
Nur habe ich ein sonderbares Problem. Wenn ich so einen halben Tag nicht schaue und ich versuche dann wieder xine zu starten mit genanntem Befehl, dann meldet Xine stets: "No Signal"
Wenn ich dann VDR stoppe und wieder starte gehts wieder einwandfrei.
In den Logs steht wenns geht:

Jul 15 13:50:48 linux vdr: [22923] [xine..put] Client 0 connected: 192.168.0.9:34399
Jul 15 13:50:48 linux vdr: [22923] [xine..put] cxSocket: setsockopt(SO_SNDBUF): got 227328 bytes
Jul 15 13:50:48 linux vdr: [22923] [xine..put] Trying UDP connection ...
Jul 15 13:50:48 linux vdr: [22923] [xine..put] Client address: 192.168.0.9
Jul 15 13:50:48 linux vdr: [22923] [xine..put] setsockopt(SO_SNDBUF): got 227328 bytes

Wenns nicht geht kommt er nur bis:

Jul 15 13:50:48 linux vdr: [22923] [xine..put] Client 0 connected: 192.168.0.9:34399
Jul 15 13:50:48 linux vdr: [22923] [xine..put] cxSocket: setsockopt(SO_SNDBUF): got 227328 bytes

aber Fehler kommt keiner. Weiss wer woran das liegen kann.

Hatte das schonmal wer, oder weiss worans liegen kann?

Danke
Stolzi