Posts by berni123

    Was meinst du damit?

    Na z.B. so in der Art:


    Code
    1. :HD Programme Kabel Tuner 1
    2. Das Erste HD;ARD:330000:C0M256:C:6900:5101=27:0;5102=deu@106,5103=mis@106:5104;5105=deu:0:11100:1:1051:0
    3. ZDF HD;ZDFvision:450000:C0M256:C:6900:6110=27:0;6120=deu@106,6121=mis@106,6123=mul@106:6130;6131=deu:0:11110:1:1079:0
    4. :HD Programme FritzWlan Adapter
    5. ZDFHD: ....

    Also das ich eine Programm ZDF HD habe, was direkt von der TV-Karte kommt und ein Programm ZDFHD, was von dem WlanRepeater kommt ...

    Bei mir läuft der script von kla.b

    Hallo jsffm,


    könnte es evtl mit dem Ausgabeplugin zu tun haben?

    Ich gebe über xine mit libximoutput aus - oder hat das Augabeplugin damit nichts zu tun.

    Der Unterschied zwischen den beiden Scripte ist ja im Aufruf von vlc - und bei mir scheint beides nicht zu funktionieren,

    obwohl es "lokal" mit vlc ja geht, nur halt über den Umweg über den VDR und dem iptv-plugin geht es nicht.


    Gruss,

    Bernd

    >>satip? Wie bekomme ich das mit IPTV konfiguriert?


    Irgendwie gibt es ein Verständnisproblem. Die Fritzbox unterstützt afaik SAT>IP anstelle von IPTV.

    Wobei IPTV und SATIP beide gemeinsam auf die gleichen Protokolle UPnP, RTP, RTCP und RTSP aufbauen, nur eben mit kleinen Unterschieden.



    Ja Danke, das ist mir jetzt auch klar geworden durch Experimentieren - schade, dass das nicht unbedingt nachvollziehbar dokumentiert ist ;-)

    Ich ging halt blind davon aus, dass IPTV (wegen rtsp) mit dem Fritz WlanRepater umgehen kann ...


    Also -> Teilthema Fritz Repater ist gelöst via SATIP ...

    Aber -> Teilthema IPTV ist noch ungelöst, das das Script, weder vlc2iptv_raw noch das vlc2iptv, was bei mit drauf war, immer noch nicht funktioniert ...

    Hallo kla.b,


    danke für den Tip - das habe ich experimentell auch herausgefunden, als ich

    über das Plugin "Signalinformationen" beim Kanal ZDF-HD gesehen habe, dass

    ich dort auch den SAT-IP Tuner aktivieren konnte und ich das Signal dann

    vom Wlan-Repeater bekam, anstelle von der TV-Karte ;-)


    Umgekeht bedeutet das aber auch, dass ich faktisch keinen eigenen Eintrag erzeugen kann,

    der mit direkt das SIgnal via SATIP Plugin gibt?


    Gruss,

    Bernd

    Hey, ich bin bisher kläglich daran gescheitert das IPTV via rtsp zu konfigurieren.


    Gerade versuche ich mich am satip mit dem Fritz WlanRepeater DVB-C, aber das klappt auch irgendwie alles nicht so wie es angeblich soll. Das FritzOS ist 7.01 - das ist das aktuelle für den Repeater.

    Hallo,


    ich habe gehört, dass anstelle des vdr-plugin-iptv man für den FritzWLan Repater DVB-C lieber das vdr-plugin-satip benutzen soll.


    Nun ist: http://www.vdr-wiki.de/wiki/index.php/Satip-plugin

    nicht aus ausführlich.


    Wie bekomme ich das Plugin denn konfiguriert?


    Wenn ich es einfach installiere, startet es und erzeugt mir zwei Devices (per default).

    Es erkennt wohl im Netz auch den Wlan Repater mit dem DVB-C aber ich bekomme im log:


    Naja und so weiter ...


    Wie bekomme ich denn jetzt das Ding richtig zum Laufen?


    In der conf Datei habe ich mal probiert mit:

    -d 1 nur ein Device und den Server explizit anzugeben.


    Wie bekomme ich jetzt die channels.conf EInträge zusammen dazu?

    Also bei mir geht es auch mit dem Script von kla.b nicht:


    3.16 ist ein gepflegter LTS-Kernel, also ist das schon in Ordnung.


    media_build_experimental hat evtl. auch einen Treiber für die DD dabei, vielleicht wurder dddvb ja nie genutzt? Was passiert, wenn du media_build_experimental baust?

    Sorry, hatte noch eine Zeit den media_build_experimental zu bauen und zu testen ... gerade zu viel um die Ohren.

    Bisher bleibe ich beim Kernel, mit dem es ohne media_build_experimental und mit dem dd v 0.9.36 läuft.


    Ich melde mich hier, sobald ich es getetet habe ...

    Hallo,


    ich habe hier: IPTV Stream (IP-Kamera) als Kanal

    mal eine config gefunden, die ich nutzen wollte, um meinen rtsp Streams, die mein Fritz DVB-C Empfänger

    in mein Netz einspeist, aber komischerweise klappt das nicht.


    Aber der Reihe nach:


    1. Test mit vlc in der console, der Stream funktioniert:

    Code
    1. vlc "rtsp://192.168.0.248:554/?avm=1&freq=450&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,6100,6110,6120,6121,6123,6130,6131,6170"

    bzw direkt aus dem Internet:

    Code
    1. vlc "rtsp://77.72.196.214:8554/live/mp4:AltoAdigeTV"


    2. config unter: /etc/vdr/plugins/iptv/vlcinput:

    Code
    1. AltoAdigeTV.conf: URL="rtsp://77.72.196.214:8554/live/mp4:AltoAdigeTV"
    2. ZDFHD.conf: URL="rtsp://192.168.0.248:554/?avm=1&freq=450&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,6100,6110,6120,6121,6123,6130,6131,6170"

    3. Eintrag in der channels.conf:

    Code
    1. :IPTV plugin
    2. ZDFHD;IPTV:10:S=0|P=0|F=EXT|U=vlc2iptv|A=1:I:0:5=2:6=@4:0:0:1:0:0:0
    3. AltoAdigeTV;IPTV:20:S=0|P=0|F=EXT|U=vlc2iptv|A=1:I:0:5=2:6=@4:0:0:1:0:0:0

    Schaltet man auf die Sender, kein Bild, kein Ton.

    Im syslog steht:

    Also die IP-TV channels sind vorhanden.


    Erster Versuch:


    Zweiter Versuch:

    Was auffällt ist:


    Code
    1. [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB

    Aber ich bin mir nicht sicher, ob das was damit zu tun hat, da das immer kommt.


    VLC selber kann den rtsp Stream abspielen.


    Zum Vergleich noch mal ein anderer Kanal vom Kabel:

    Hier kommt diese ARGB Meldung auch, aber der die Ausgabe ist länger und der Codec wird erkannt usw.


    Ich stehe irgendwie mit diesem iptv plugin auf Kriegsfuss ... habe schon mehrere Anläufe unternommen, aber bin immer wieder gescheitet.


    Version des vdr-plugin-iptv ist 2.2.1 via Debian Jessie mit vdr-experimental jessie vdr-multipatch von e-tobi.net


    Für Tips bin ich dankbar.


    Gruss,

    Bernd


    Hallo,


    folgendes Problem: DDbridge Treiber ädt nicht (mehr) richtig nach Kernel update


    Basis: Debian Jessie mit E-Tobi Archiv vdr-experimental


    DD-Treiber v 0.9.36 compiliert mit Kernel 3.16.0-7 laufen und keine Probleme.

    Das war auch mit 3.16.0-7, so kein Problem mein Laden und Laufen ...


    Neuen Kernel von Debian Jessie installiert: 3.16.0-10 und neue Treiber 0.9.37 compiliert:

    Treiber laden nicht beim boot.

    modprobe ddbridge lädt ohne Fehler, auch modprobe -vvv zeigt keine Fehler an, aber /dev/dvb Devices werden nicht erzeugt.


    Das einzige was mir auffällt ist, dass ich bei Kernel 3.16.0-5 und 3.16.0-4 zusätzlich die media_build_experimental Treiber

    mit übersetzen und installieren musste, was ich bei Kernel 3.16.0-7 nicht musste (den 3.16.0-6 hatte ich übersprungen)

    und freute mich, dass der Distro-Kernel das jetzt so sauber hinbekommt.


    Ist da evtl. was zurück gedreht worden im Debian Kernel Paket, so dass ich jetzt media_build_experimental wieder mit übersetzen muss?


    Werde ich ausprobieren, wenn ich Zeit habe, nur unschön ist es, falls sich meine Theorie als wahr erweist.


    Viele Grüße,

    Bernd


    Hallo zusammen,


    es wird mal wieder Zeit meinen in die Jahre gekommen VDR zu renovieren.

    Was für Tipps habt Ihr denn in Sachen Mainboard/Gehäuse?


    Ziel:

    Mainboard:

    + mit CPU/Grafik on board (fähig für alle aktuellen DVB-C/C2 HD Standards)

    + Gbit LAN

    + mindestens 2-3xPCIe (für DD-Karte 2xTwin-Tuner und CAM/CI)

    + COM optional für Slotblechmontage, da gute alter serieller IR-Empfänger benutzt wird


    Gehäuse: nicht zu groß, aber Platz für

    - Slots: 2-3x PCIe (je nach Board), 1x DualCAM/CI. 1x COM-Port-Slotblech

    - 1xDVD-Brenner (ja rustikal gehts noch zu, brenne gerne mal nen paar Filme weg)


    Netzteil passend zum Board

    Festplatten 2x für Raid1


    Für Tipps bedanke ich mich schon mal.


    Bernd
    :]:]:]

    So ich habe jetzt mit netfilter getrickst!


    Da laut netstat sich der vdr ums verrecken nur an 127.0.0.1:37890 gebunden hat, habe ich per:


    Code
    1. iptables -t nat -D PREROUTING -p tcp -d 192.168.0.201 --dport 37890 -j DNAT --to-destination 127.0.0.1

    erst mal alle tcp Pakete an port 37890 vom lokalen Netzwerkinterface auf das loopback device umgebogen.


    Damit dann der remote client auch die Pakete zurück bekommt habe ich unter /etc/sysctrl.d die Datei vdr.conf angelegt:

    Code
    1. #
    2. net.ipv4.conf.all.route_localnet = 1

    damit die Pakete vom loopback device auch wieder zurück geworfen werden.


    Damit kann ich dann auf dem remote Rechner per: vdr-sxfe xvdr://192.168.0.201:37890

    die Verbindung herstellen.


    Fertig!


    Nicht schön aber selten ;-)

    Dann steht bei Dir in der plugin config sicher --remote=34890, denn 37890 ist der default Wert.

    Aber Du hast die 0.0.0.0:34890 und da es bei Dir funktioniert und bei mir mit 127.0.0.1:37890 nicht, bin ich schon mal dicht dran.

    Kannst Du bei Dir mal nachsehen, was im syslog steht?


    Interessant wären diese Zeilen mit [xine..put]:

    Code
    1. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Binding server to 127.0.0.1:37890
    2. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Listening on port 37890
    3. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Listening for UDP broadcasts on port 37890


    Irgend jemand anderes eine Idee, warum trotz entsprechender config (siehen weiter oben), bei mir der connect aus dem Netzwerk nicht klappt?


    Gruss,

    Bernd

    Bei mir steht in allen "allowed_hosts"-Dateien immer das hier drin und ich kann von allen LAN-/WLAN-Clients zugreifen; zB von Stand-PC 192.168.192.61 auf VDR 192.168.192.50:

    127.0.0.1 # always accept localhost

    192.168.0.0/16 # any host on the local net

    (der any-Eintrag ist bei mir auskommentiert)

    Habe ich schon alles ausprobiert, sowohl die beiden Zeilen, die Du hast, als auch die any-Zeile.

    Es funktioniert einfach nicht. Es wird kein connect aus dem lokalen Netzwerk zu gelassen.

    Der tcpdump zeigt, dass nach dem syn-Paket ein reject-Paket fliegt.

    Die iptables sind leer und alle auf default policy accept.


    Kannst Du mal schauen, was bei Dir die Ausgabe von netstat -tulpn | grep 37890 ergibt?


    Bekommst Du da eine Zeile mit: tcp 0 0 127.0.0.1:37890 0.0.0.0:* zurück

    oder eine Zeile mit: tcp 0 0 0.0.0.0:37890 0.0.0.0:*

    zurück?


    Da ich ein 127.0.0.1:37890 bekomme, zusammen mit der logmeldung im syslog, dass sich xine..put an 127.0.0.1:37890 bindet,

    ergibt für mich das Verständnis, dass trotz der plugin-Konfiguration --remote=37890 keine Bindung an das physikalische

    Netzwerkinterface erfolgt. Wenn jedoch bei Dir auch die Zeile 127.0.0.1:37890 erscheint, es bei Dir aber geht, muss der

    Teufel bei mir woanders stecken.


    Hat jamend noch eine Idee?


    Viele Grüße,

    Bernd

    tcpdump:

    Code
    1. root@vdr2:~# tcpdump -i eth0 -n -l port 37890
    2. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    3. listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    4. 19:37:13.905783 IP 192.168.0.2.46762 > 192.168.0.201.37890: Flags [S], seq 765292401, win 29200, options [mss 1460,sackOK,TS val 66117198 ecr 0,nop,wscale 7], length 0
    5. 19:37:13.905831 IP 192.168.0.201.37890 > 192.168.0.2.46762: Flags [R.], seq 0, ack 765292402, win 0, length 0
    6. ^C
    7. 2 packets captured
    8. 2 packets received by filter

    Da kommt ein R (reject) ...


    Das würde erklären warum netstat:

    Code
    1. root@vdr2:~# netstat -tulpn | grep 37890
    2. tcp 0 0 127.0.0.1:37890 0.0.0.0:* LISTEN 2955/vdr
    3. udp 0 0 255.255.255.255:37890 0.0.0.0:* 2955/vdr

    evtl hier 127.0.0.1:37890 ausgibt.


    Im syslog steht ja auch:

    Code
    1. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Binding server to 127.0.0.1:37890
    2. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Listening on port 37890
    3. Mar 11 18:48:57 vdr2 vdr: [3098] [xine..put] Listening for UDP broadcasts on port 37890

    Also scheint der vdr bzw. das plugin sich nicht ans lokale Netzwerk zu binden, sondern nur an das loopback, trotz der config:

    Code
    1. --local=none
    2. --primary
    3. --remote=37890

    Kann man das Problem lösen? Wie bekommt man das plugin an 127.0.0.1 UND für das äußere Netz gebunden?