[gelöst] [0.4] streamdev-Problem

  • Hi!


    Da ich mich in den anderen Thread lediglich eingemischt habe, wollte ich nochmal mit einer Zusammenfassung meines Problems durchstarten:


    Problem: streamdev-client läuft nicht


    Hardware: siehe Signatur


    was ich anfangs tat:
    - yaVDR 0.4 aufs jungfräuliche System installiert
    - streamdev-client geladen und installiert

    Code
    1. sudo apt-get update
    2. sudo apt-get install vdr-plugin-streamdev-client

    - per Hand (s.u.) /var/lib/vdr/setup.conf angepasst:

    Code
    1. streamdev-client.StreamFilters = 1
    2. streamdev-client.SyncEPG = 0
    3. streamdev-client.RemoteIp = 192.168.23.115
    4. streamdev-client.RemotePort = 2004
    5. streamdev-client.StartClient = 1

    hinzugefügt und

    Code
    1. streamdev-server.StartServer = 0

    gesetzt


    - auf dem Server ebenfalls die setup.conf

    Code
    1. streamdev-server.AllowSuspend = 1
    2. streamdev-server.SuspendMode = 1

    und /etc/vdr/svdrphosts.conf bzw. (/auch) /etc/vdr/plugins/streamdev-server/streamdevhosts.conf um
    192.168.23.0/25
    erweitert (Subnet ist schon richtig so, siehe aber auch weiter unten)
    - mit der Channelpedia auf dem Server den 3 IPTV-Chans 10 Standard-Chans hinzugefügt (ard, zdf, rtl, sat1, ...) und diese auf den Client kopiert


    Ergebnis: läuft nicht. Sollte es aber. Also: Logs und Forum durchwühlen:


    Logs:
    - der streamdev-server startet, bekommt An- und Abmeldung vom Client (hatte den Client um 18:38 neugestartet und um 18:50 ausgeschaltet)

    Code
    1. Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] streamdev server thread started (pid=1162, tid=1410)
    2. Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] Streamdev: Listening (VTP) on port 2004
    3. Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] Streamdev: Listening (HTTP) on port 3000
    4. Nov 15 18:38:36 whiteyaVDRsrv vdr: [1410] Streamdev: Accepted new client (VTP) 192.168.23.116:48392
    5. Nov 15 18:38:36 whiteyaVDRsrv vdr: [1410] streamdev: closing streamdev connection to 192.168.23.116:48392
    6. Nov 15 18:40:44 whiteyaVDRsrv vdr: [1410] Streamdev: Accepted new client (VTP) 192.168.23.116:47079
    7. Nov 15 18:50:38 whiteyaVDRsrv vdr: [1410] streamdev: closing streamdev connection to 192.168.23.116:47079


    - der Client meldet sich offensichtlich auch am Server an und ab:

    Code
    1. Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] dynamite: streamdev-client detected, leaving 1 additional slot(s) free
    2. Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] starting plugin: streamdev-client
    3. Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] streamdev-client: got device number 24
    4. Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] Streamdev: Connected to server 192.168.23.115:2004 using capabilities TSPIDS,FILTERS,PRIO
    5. Nov 15 18:50:37 whiteyaVDRcli vdr: [1117] stopping plugin: streamdev-client
    6. Nov 15 18:50:39 whiteyaVDRcli vdr: [1117] deleting plugin: streamdev-client


    - beim Umschalten von 3sat (11,IPTV) auf RTL (4) bzw. Sat1 (5) gibts aber Probleme und er schaltet wieder zurück auf 3sat


    nachgegangene Hinweise aus dem Forum/Internet:
    - das Netzwerk läuft: sowohl avahi-mount

    Code
    1. Nov 15 18:34:07 whiteyaVDRsrv mountd[1128]: authenticated mount request from 192.168.23.116:689 for /media/movies (/media/movies)

    funktioniert, als auch darüber Aufnahmen vom Server schauen; client meldet sich ja auch beim streamdev-server
    - dennoch mal in der svdrphosts.conf bzw. streamdevhosts.conf das Subnet auf /24 gestellt
    - im ClientMenü nochmal explizit die Plugin-Parameter von streamdev-client aufgerufen, gecheckt und gespeichert
    - oben genannter Error deutet wohl auf Probleme mit channel.conf hin: also selbige nochmal gecheckt, der Server hat diese inzwischen erweitert/geupdated, (obwohl es keine Rolle spielen sollte) die dann nochmal kopiert; auch mal die Gruppen, die ich angelegt hatte (Main, und IPTV) entfernt
    - mit AllowSuspend und SuspendMode alle Möglichkeiten durchprobiert, diese Werte sowohl per Hand in der setup.conf als auch im Menü geändert. Der Server hat auch weiterhin ein hübsches weißes Suspend-Bild, wenn ich auf dem Client auf "Server pausieren" gehe
    - mit den Priorities (PrimaryLimit) rumgespielt (verschiedene Wertkombinationen durchgespielt, welche genau weiß ich nicht mehr; am Ende wieder alle auf 0 gestellt)
    - gar nicht erst den streamdev-server auf dem Client starten: -streamdev-server in /etc/vdr/plugins/order.conf eingetragen



    ich bin mir nicht mehr so sicher, ob das alles war, schließlich ist die Liste lang und bereits einige Zeit der Recherche und vor allem Verzweiflung ins Land gestrichen; falls mir noch was einfällt, werde das ggfs. noch ergänzen


    Abschließend also mein Fazit: HILFE! ;(


    TIA, whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

    The post was edited 2 times, last by whitedwarf ().

  • Ich habe bei mir hier noch die Freigaben erteilt:
    /etc/vdr/plugins/streamdev-server/allowedhosts.conf


    und nach sudo apt-get update mache ich immer
    sudo apt-get dist-upgrade

    YaVDR Server: Intel DH67BL B3 + Intel G1610/ 4x1GB Kingston RAM/64GB SSD/2TB HDD/CineS2 V6/Netzteil Be Quiet Pure Power BQT L7-300W 300Watt / YaVDR- 0.5.0a Headless
    Client 1: Intel DH67CF-B3/ 2x2GB Kingston/ 64 GB SSD/Zotac GeForce GT 640/Origenae M10/ Yavdr 0.5.0
    Client 2: Macbook xbmc
    Client 3: Andoid Tablet Ainol Novo 7 Elf XBMC
    Client 4: Raspberry PI: Openelec Gotham

  • /etc/vdr/plugins/streamdev-server/allowedhosts.conf

    gibt es bei mir nicht. Nur streamdevhosts.conf.


    sudo apt-get dist-upgrade


    bin mir grad nicht mehr sicher, aber ich denke schon, dass ich das gemacht hatte.



    whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • Moin!


    Ich würde mir per "apt-get source vdr-plugin-streamdev" die Sourcen holen und dann in client/socket.c die Funktion cClientSocket::ProvidesChannel anpassen und zum einen per isyslog ausgeben, was der Client an den Server schickt und was er zurückbekommt. Da weder 220 noch 560 als Replycode zurückkommt, bleibt eigentlich nur noch 501 (Hilfetext) bzw. 550 (undefined channel) über (siehe cConnectionVTP::CmdPROV in server/connectionVTP.c). Leider gibt der Client das nicht aus.
    Netzwerkprobleme können eigentlich ausgeschlossen werden, denn die Verbindung steht. Wenn ich raten sollte, sind sich Server und Client nicht über die Channel-ID einig, warum auch immer.


    Lars.

  • Wie sieht es denn aus, wenn sowohl auf Server- als auch Client-Seite keine IPTV-Kanäle in der channels.conf sind? Oder habe ich diesen Test und das Ergebnis schlicht überlesen?


    Gruss


    plego

    VDR 1: Asus P5N7A-VM, Media Pointer S2 V5.4, yaVDR 0.4 pre1

    VDR 2: Mecool KI pro S905D mit CoreELEC 9.2.1

    Client 1: X96 S905X mit CoreELEC 9.2.1

    Clients 2,3,4: Fire TV Sticks mit Kodi 18.5

  • Ich würde mir per "apt-get source vdr-plugin-streamdev" die Sourcen holen und dann in client/socket.c die Funktion cClientSocket:rovidesChannel anpassen und zum einen per isyslog ausgeben, was der Client an den Server schickt und was er zurückbekommt. Da weder 220 noch 560 als Replycode zurückkommt, bleibt eigentlich nur noch 501 (Hilfetext) bzw. 550 (undefined channel) über (siehe cConnectionVTP::CmdPROV in server/connectionVTP.c). Leider gibt der Client das nicht aus.

    hui... ok, das geht natürlich ein wenig über .conf anpassen und plugins mit apt-get ziehen hinaus. Dem werde ich mich frühestens am Wochenende widmen können, dann aber auch tun.


    Wie sieht es denn aus, wenn sowohl auf Server- als auch Client-Seite keine IPTV-Kanäle in der channels.conf sind? Oder habe ich diesen Test und das Ergebnis schlicht überlesen?


    Nein, hast du nicht überlesen, wird heut abend getestet.




    weitere Ideen, die ich dann direkt mit testen kann?


    whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • Vielleicht könntest Du den Server mal per Hand vorher auf den Sender Tunen. (z.B. mit svdrp chan X)


    Ich hatte es hin und wieder das bei mir das Umschalten auf dem Server so lange gedauert hat das das Timeout für den Request abgelaufen war.
    Falls Du den Server oder Client neu bast, könntest Du das Timeout hoch setzen.
    Jedoch sollte das nicht zutreffen wenn der Server eh schon auf dem Channel ist.

  • Vielleicht könntest Du den Server mal per Hand vorher auf den Sender Tunen. (z.B. mit svdrp chan X)

    ist notiert ... allerdings hab ich

    Jedoch sollte das nicht zutreffen wenn der Server eh schon auf dem Channel ist.


    bereits probiert, von daher erhoffe ich mir da nicht so viel :(



    whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • weitere Ideen, die ich dann direkt mit testen kann?


    Ja, deaktiviere auf dem Client das IPTV-Plugin, damit es dort ein Eingabedevice weniger gibt.


    Gruss


    plego

    VDR 1: Asus P5N7A-VM, Media Pointer S2 V5.4, yaVDR 0.4 pre1

    VDR 2: Mecool KI pro S905D mit CoreELEC 9.2.1

    Client 1: X96 S905X mit CoreELEC 9.2.1

    Clients 2,3,4: Fire TV Sticks mit Kodi 18.5

  • Gute Nachricht: es läuft!


    was ich gemacht hab:


    - in /etc/vdr/svdrphosts.conf und /etc/vdr/plugins/streamdev-server/streamdevhosts.conf 192.168.0.0/16 eingestellt (auf dem Server)


    - die drei IPTV-Sender aus der Channel.conf geschmissen (auf beiden)


    - auf dem Client ein Update gemacht

    Code
    1. sudo apt-get update
    2. sudo apt-get -dist-upgrade


    Dabei hat er folgendes gemeldet:




    Da es läuft bin ich glücklich, aber ich habe ungeduldigerweise alle drei Vorschläge gleichzeitig umgesetzt, weswegen nicht ganz klar ist, woran es nun konkret lag. Um das herauszufinden, hab ich im Nachhinein nochmal die Hosts angepasst und gesetzt, wie sie sein sollten. Danach lief es ohne Probleme. Und heut morgen noch die 3 IPTV Channels wiedereingefügt. Ich kanns nur nach Log beurteilen, aber auch jetzt scheint es noch zu laufen. D.h. am wahrscheinlichsten ist wohl, dass ich das dist-upgrade vergessen hab. Dennoch finde ich es dann recht komisch, dass es nur an libplist1 liegt...




    Danke an alle für die helfenden Ideen!


    whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • libplist1 ist ja nur neu dazu gekommen.
    Tippe eher das es am Update vom vdr-plugin-streamdev-client lag.

  • wieso hat er dann nicht auch schon beim ersten sudo apt-get install die aktuellste Version von streamdev-client gezogen? Oder liegen dort nur "ältere" Versionen und man sollte/muss nach jedem Plugin-Download ein -dist-upgrade machen?

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • Moin!


    man sollte/muss nach jedem Plugin-Download ein -dist-upgrade machen?


    Wenn ich ein Plugin installieren will, dann mache ich immer vorher ein "sudo apt-get update". Ein "dist-upgrade" mache ich bei Problemen und hoffe, dass es neue Versionen gibt. :-)
    Mit "sudo apt-get -s dist-upgrade" kann man sich ja vorher ansehen, was er machen würde und dann entscheiden, ob man es tun will.


    Das streamdev-Plugin wurde außerdem erst am 14.11. im Repository auf einen neuen Upstream-Snapshot aktualisiert.


    Lars.

  • wieso hat er dann nicht auch schon beim ersten sudo apt-get install die aktuellste Version von streamdev-client gezogen? Oder liegen dort nur "ältere" Versionen und man sollte/muss nach jedem Plugin-Download ein -dist-upgrade machen?


    Wenn du ein apt-get install machst, dann sieht er nicht nach was im PPA die neueste Version ist. Er sieht in Dateien auf deinem Rechner nach der Version und holt dann genau diese. Wenn die Dateien auf deinem Rechner alt sind, dann steht da eben auch eine alte Version drin. Die Dateien werden mit einem apt-get update auf deinem Rechner aktualisiert. Also solltest du nicht einfach ein apt-get install machen, sondern vorher immer ein apt-get update. Ein apt-get dist-upgrade würde überhaupt nichts bringen, weil er ohne apt-get update gar nicht weiß, dass es was upzugraden gibt.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • So hatte ich mir das schon fast gedacht. Was dann wiederum merkwürdig ist, denn dass ich ein update vor dem install gemacht hatte, da bin ich mir recht sicher (nur eben bei dist-upgrade nicht). Vllt. hat das libplist1 ja doch irgendeine Bedeutung für das streamdev. Das detailiert zu erörten will ich mir sparen, schließlich reicht es einfach nur die wirklich aktuellste Variante von streamdev zu installieren und das eben mit einem vorgeschobenen update und einem nicht zu vergessenden dist-upgrade im Nachhinein.


    whitedwarf

    Server: yaVDR 0.6.1, ASRock H61M-U3S3, Asus P8H61M, Intel G860, Scythe Big Shuriken 2, ASUS ENGT520 Silent, Silverstone SuGo SG02B-F, 2x2GB Kingston, BeQuiet PurePower L7 300W, 4TB HGST, TeVii S480 v2.1
    Client: yaVDR 0.6.1, ASRock H67M-ITX, Intel G860 Boxed, ASUS ENGT520 Silent, JCP MI-111.B, 2x2GB Kingston, Xilence SFX SPS.XP200

  • Hallo,


    ich habe bei einer neuen installation auch das problem das keine streamdev-verbindung mit dem server aufgebaut werden kann. es liegt definitiv nicht am server. ein easyvdr kann wunderbar verbinden.
    was ich feststellen konnte mit einem tcpdump
    der client sendet ein PROV mit den satdaten "S19E2... "
    darauf kommt ein 550 das der channel unbekannt sei.
    damit es keine irretationen mit der channels.conf gibt habe ich vorher die channels.conf vom server auf den client kopiert.
    es wird also offensichtlich entweder die falsche channelkennung mit den satdaten gesendet oder
    die gegenseite versteht das PROV nicht (laut c-quelle sollte es das aber)


    leider kann ich nicht genau sagen welche satdaten gesendet werden, weil ich aufgrund dieses threads ein
    dist-upgrade gemacht habe wasleider dazu geführt hat das die kiste nun nicht mehr öäuft :-(


    bye woodym

  • hallo,
    nein, diese zeile gibt es nicht für das erste. folgendes ist in der channels.conf:
    Das Erste;ARD:11836:HC34M2O0S0:S19.2E:27500:101=2:102=deu@3,103=mis@3;106=deu@106:104:0:28106:1:1101:0


    in der epg.data:


    C S19.2E-1-1101-28106 Das Erste


    die channels.conf wurde durch einen scan auf dem server erstellt (vdr 1.7.16) und 1:1 auf den client kopiert.


    wenn ich das richtig sehe überträgt der client die frequenz des transponders (111836). wobei das stremdev-wiki hier nicht sehr aussagekräftig ist:
    'Kanal ist eine Textzeile welches den Kanal beschreibt. Es kann zum Beispiel der Kanalname oder die Kanalnummer sein.'


    die transponderfrequenz anzugeben ist auch nicht sonderlich ergiebig da hier ja mehrer kanäle übertragen werden. das zeigt sich auch bei den anfragen


    PROV 0 S19.2E-0-111836-0
    550 Undefined channel "S19.2E-0-111836-0"


    PROV 0 S19.2E-0-111836-0
    Undefined channel "S19.2E-0-111836-0"


    das sind zwei anfragen an zwei wdr-kanäle die auf dem gleichen transponder sind.


    bye woodym



    berichtigung: das sind nicht zwei wdr-kanäle sondern diese beiden gewesen:


    Bayerisches FS Süd;ARD:11836:HC34M2O0S0:S19.2E:27500:201=2:202=deu@3,203=mis@3;206=deu@106:204:0:28107:1:1101:0
    hr-fernsehen;ARD:11836:HC34M2O0S0:S19.2E:27500:301=2:302=deu@3,303=mis@3:304:0:28108:1:1101:0

  • Streamdev-client sendet die Channel-ID, die über die Methode GetChannelID geholt wird. Wenn NID und TID den Wert 0 haben, wird in dieser Methode anstelle der TID die Frequenz inkl. führender Ziffer für die Polarisationseben ausgegeben. Genau dies passiert offenbar auf Deinem Client. NID und TID sind das drittletzte und vorletzte Feld in den Einträgen der channels.conf. Laut channels.conf Deines Servers, sind beide Felder ungleich 0. Offenbar sieht das bei Deinem Client aber anders aus (S19.E-0-... statt S19.E-1-...). Schau Dir auf dem Client mal die Kanäle über das Kanal-Menü an. Vermutlich stehen auch dort falsche Werte für NID und TID.