text: [gelöst] [0.4] streamdev-Problem - yaVDR - VDR Portal
  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
  was ich anfangs tat:
  - yaVDR 0.4 aufs jungfräuliche System installiert
  - streamdev-client geladen und installiert
  - per Hand (s.u.) /var/lib/vdr/setup.conf angepasst:
  streamdev-client.RemoteIp = 192.168.23.115
  - auf dem Server ebenfalls die setup.conf
  und /etc/vdr/svdrphosts.conf bzw. (/auch) /etc/vdr/plugins/streamdev-server/streamdevhosts.conf um
  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:
  - der streamdev-server startet, bekommt An- und Abmeldung vom Client (hatte den Client um 18:38 neugestartet und um 18:50 ausgeschaltet)
  Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] streamdev server thread started (pid=1162, tid=1410)
  Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] Streamdev: Listening (VTP) on port 2004
  Nov 15 18:34:06 whiteyaVDRsrv vdr: [1410] Streamdev: Listening (HTTP) on port 3000
  Nov 15 18:38:36 whiteyaVDRsrv vdr: [1410] Streamdev: Accepted new client (VTP) 192.168.23.116:48392
  Nov 15 18:38:36 whiteyaVDRsrv vdr: [1410] streamdev: closing streamdev connection to 192.168.23.116:48392
  Nov 15 18:40:44 whiteyaVDRsrv vdr: [1410] Streamdev: Accepted new client (VTP) 192.168.23.116:47079
  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:
  Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] dynamite: streamdev-client detected, leaving 1 additional slot(s) free
  Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] starting plugin: streamdev-client
  Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] streamdev-client: got device number 24
  Nov 15 18:40:44 whiteyaVDRcli vdr: [1117] Streamdev: Connected to server 192.168.23.115:2004 using capabilities TSPIDS,FILTERS,PRIO
  Nov 15 18:50:37 whiteyaVDRcli vdr: [1117] stopping plugin: streamdev-client
  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
  Nov 15 18:44:00 whiteyaVDRcli vdr: [1117] switching to channel 4
  Nov 15 18:44:00 whiteyaVDRcli vdr: [1281] IPTV streamer thread ended (pid=1117, tid=1281)
  Nov 15 18:44:00 whiteyaVDRcli vdr: [1117] ERROR: Streamdev: Couldn't check if 192.168.23.115:2004 provides channel RTL Television
  Nov 15 18:44:00 whiteyaVDRcli vdr: [1117] info: Kanal nicht verfügbar!
  Nov 15 18:44:00 whiteyaVDRcli vdr: [1280] receiver on device 10 thread ended (pid=1117, tid=1280)
  Nov 15 18:44:08 whiteyaVDRcli vdr: [1117] switching to channel 5
  Nov 15 18:44:08 whiteyaVDRcli vdr: [1117] ERROR: Streamdev: Couldn't check if 192.168.23.115:2004 provides channel SAT.1
  Nov 15 18:44:08 whiteyaVDRcli vdr: [1117] info: Kanal nicht verfügbar!
  Nov 15 18:44:15 whiteyaVDRcli vdr: [1712] Text2Skin: channelInfo display update thread ended (pid=1117, tid=1712)
  Nov 15 18:44:15 whiteyaVDRcli vdr: [1117] switching to channel 11
  Nov 15 18:44:15 whiteyaVDRcli vdr: [1117] ERROR: Streamdev: Couldn't check if 192.168.23.115:2004 provides channel 3Sat
  Nov 15 18:44:15 whiteyaVDRcli vdr: [1713] receiver on device 10 thread started (pid=1117, tid=1713)
  Nov 15 18:44:15 whiteyaVDRcli vdr: [1715] IPTV streamer thread started (pid=1117, tid=1715)
  nachgegangene Hinweise aus dem Forum/Internet:
  - das Netzwerk läuft: sowohl avahi-mount
  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
  The post was edited 2 times, last by whitedwarf ( Nov 17th 2011 ).
  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
  gibt es bei mir nicht. Nur streamdevhosts.conf.
  bin mir grad nicht mehr sicher, aber ich denke schon, dass ich das gemacht hatte.
  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.
  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?
  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.
  Nein, hast du nicht überlesen, wird heut abend getestet.
  weitere Ideen, die ich dann direkt mit testen kann?
  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.
  ist notiert ... allerdings hab ich
  bereits probiert, von daher erhoffe ich mir da nicht so viel
  Ja, deaktiviere auf dem Client das IPTV-Plugin, damit es dort ein Eingabedevice weniger gibt.
  Gute Nachricht: es läuft!
  - 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
  sudo apt-get -dist-upgrade
  Dabei hat er folgendes gemeldet:
  ati-remote-dkms debconf debconf-i18n graphtft-fe hid-gyration-dkms
  libmodplug1 libxine1-xvdr libxine2 linux-firmware-yavdr vdr
  vdr-plugin-graphtft vdr-plugin-iptv vdr-plugin-live vdr-plugin-markad
  vdr-plugin-menuorg vdr-plugin-pvr350 vdr-plugin-restfulapi
  vdr-plugin-skinpearlhd vdr-plugin-streamdev-client
  vdr-plugin-streamdev-server vdr-plugin-text2skin vdr-plugin-wirbelscan
  vdr-plugin-xine vdr-plugin-xineliboutput vdr-plugin-xvdr xbmc
  xbmc-addon-xvdr xbmc-bin xineliboutput-sxfe yavdr-base yavdr-i18n
  yavdr-remote yavdr-utils
  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!
  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?
  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.
  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.
  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.
  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
  jetz habe ich es neu aufgesetzt um den fehler berichten zu können:
  PROV 0 S19.2E-0-111836-0
  550 Undefined channel "S19.2E-0-111836-0"
  und das bei allen channels.
  Schau Dir mal die epg.data auf dem Server an. In den Zeilen die mit einem "C" beginnen, stehen die Channel-IDs (siehe http://www.vdr-wiki.de/wiki/index.php/Epg.data). Gibt es dort eine mit S19.2E-0-111836-0?
  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
  Undefined channel "S19.2E-0-111836-0"
  das sind zwei anfragen an zwei wdr-kanäle die auf dem gleichen transponder sind.
  berichtigung: das sind nicht zwei wdr-kanäle sondern diese beiden gewesen:
  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.