Datenausgabe nach IP Adresse u. Port umleiten

man netcat

Hi, das hatte ich schon probiert.

Als erstes startet der Befehl ohne Probleme.
Wenn ich nun aber mit dem vlc oder mplayer drauf zugreife, kommt die 
Fehlermeldung Der Wert ist zu groß für den definierten Datentyp

root@devuanserver:/home/andreas# cat /dev/dvb/adapter0/dvr0 | nc -l -s 
192.168.0.200 -p 1234
GET / HTTP/1.0
Host: 192.168.0.200:1234
User-Agent: MPlayer 1.4
Icy-MetaData: 1
Connection: close

cat: /dev/dvb/adapter0/dvr0: Der Wert ist zu groß für den definierten 
Datentyp

andy_help schrieb:
> cat /dev/dvb/adapter0/dvr0 | nc -l -s 192.168.0.200 -p 1234

das ist so schlecht.
das cat startet sofort, liest Daten von der Karte, schiebt sie ans 
netcat, was aber noch keine Verbindung offen hat ==> die Daten werden 
gebuffert, je nachdem wann dein client startet, viele viele GB.

Wenn das netcat mit der Option "-DGAPING_SECURITY_HOLE" compiliert 
wurde, gibt es eine exec-option, die erst nach Verbindungsaufbau dein 
"cat" starten könnte,

# nc -l -p 1234 -k -e 'cat /dev/dvb/...'

potentiell zweites Problem: dein mplayer schickt wohl einen 
HTTP-Request, den nc nicht versteht/beantwortet. nc macht nur TCP.
Dank "HTTP 1.0" könnte das aber in Ordnung gehen.
Ansonsten -e 'echo -e "Headers....\n\n" ; cat /dev/dvb...'

drittes Problem:
"/dev/dvb/adapter0/dvr0" liefert nur einen Transport-Stream, wenn, 
salopp gesagt, auch ein Sender eingestellt ist. Das geht über das 
zugehörige demux0-device.

Wenn du auf dem "Server" vorher schon TV geguckt hast, bleibt der letzte 
Kanal ausgewählt.
Ansonsten findest du hier zwei Beispiele wie du den richtigen 
Transponder wählst und das dvr-device konfigurierst:

https://www.linuxtv.org/docs/dvbapi/Examples.html

Vielleicht bist du mit einer fertigen Software wie http://mumudvb.net/ 
schneller am Ziel.

KitKat schrieb:
> andy_help schrieb:
>> cat /dev/dvb/adapter0/dvr0 | nc -l -s 192.168.0.200 -p 1234
>
> das ist so schlecht.
> das cat startet sofort, liest Daten von der Karte, schiebt sie ans
> netcat, was aber noch keine Verbindung offen hat ==> die Daten werden
> gebuffert, je nachdem wann dein client startet, viele viele GB.

Das glaub ich kaum. Eine linux pipe hat heutzutage normalerweise per 
default 65KB Kapazität. Wenn ein Programm nicht von einer Pipe liest, 
läuf diese voll, und wenn ein Programm versucht, in eine volle Pipe zu 
schreiben, blockiert der Schreibvorgang einfach, bis Platz da ist, also 
das andere Program von der Pipe Daten liest.

Dirk B. schrieb:
> KitKat schrieb:
>> nc macht nur TCP.
>
> es gibt den Switch -u für UDP Mode

Was sehr gut hilft, um HTTP-Requests zu verarbeiten. Thema verfehlt.

DPA schrieb:
> Das glaub ich kaum. Eine linux pipe hat heutzutage normalerweise per
> default 65KB Kapazität.

Es geht nicht um die Pipe im Userspace. Nach dem "open" auf dem 
DVR-Device (und ggfs. dem START-ioctl) versucht der kernel-Treiber einen 
möglichst unterbrechungsfreien Stream für eine Aufnahme zur Verfügung zu 
stellen.
Nachdem es keinen Rückkanal zum Sateliten gibt, um den zu drosseln wenn 
das netcat hängt, ist die "input"-Datenrate fix vorgegeben.
Der Kernel hat einen Ringbuffer dafür. Wenn die "read()"s aus dem 
userspace nicht schnell genug kommen, läuft der über.
Deutlich mehr als 64kb, aber ok, kein unbegrenzter Speicherbedarf.
Allerdings endet das read() auf dem dvr-device dann mit einem EOVERFLOW, 
und damit bricht die Pipe und das netcat dahinter wohl ab.

Deswegen bleibe ich dabei: das DVR-Device erst aufmachen, wenn die 
TCP-Verbindung steht, wenn es denn schon eine selbst-frickel Lösung mit 
netcat werden soll.

Bessere Alternativen vom einfachen DVB->IPTV Umsetzer bis zur 
Full-Featured TV-Server-Lösung wurden ja genannt. Evtl. MythTV noch mit 
anschauen.