nordkurve Posted February 3, 2014 Share Posted February 3, 2014 Ich habe mir einen managebaren Switch gekauft und einen Telestar Receiver TD2510Hd der sat>ip fähig ist. Ich habe zwei Fragen zum Recording Service als Sat>ip Server: 1. wenn ich im Switch das igmp snooping einschalte, warum sehe ich den recording Service nicht mehr im DVBViewer als Gerät und auch in allen anderen Apps z.B. elgato usw. nicht? Andere Sat>ip Server sind weiterhin zu sehen!? 2. Wie schon mehrfach in diesem Forum geschrieben möchte ich trotzdem nochmal die Frage stellen, ob man den recording Service nicht so ändern kann das er von Hardware sat>ip Clients (z.B. Telestar s.o.) auch gefunden wird. Ich habe noch einen GSS 400 Sat>ip Server, der wird von allen Geräten und jeder Software immer als erster gefunden, der recording Service von Hardware Clients nie. Was machen die anderen sat>ip Server was der recording Service nicht macht? Link to comment
Tjod Posted February 3, 2014 Share Posted February 3, 2014 Das auffinden von Server läuft glaube ich per Multicast. Was aber genau da die unterscheide sind. Und warum einige Probleme haben und andere nicht kann ich nicht sagen. Link to comment
qupfer Posted February 5, 2014 Share Posted February 5, 2014 (edited) SAT-IP nutzt UPnP zum finden der Geräte. UPnP nutzt wiederum SSDP zum finden der Services. Und SSDP verwendet Multicast. Und für (korrektes) Multicast müssen sich die Geräte mtitels IGMP bei einer Multicastgruppe anmelden. Soweit so gut. In einen "normalen" Heimnetzwerk sind die Geräte ja mittels Switch verbunden, was "eigentlich" ausschließlich Layer2 (Ethernet) entspricht. Multicast/IGMP ist Layer3 (IP) und wird daher von klassischen Switchen ignoriert. Läuft dann auf ein Ethernet-Broadcast hinaus. Nun hast du ja von einem managebaren Switch gesprochen, der IGMP snooping kann. Also kann der IGMP und kann damit im UPnP rumfuschen Warum bei eingeschalteten IGMP Snooping der RecordingService nicht mehr gefunden wird, kann ich dir aber auch nicht sagen. Die einfachste Möglichkeit wär aber, er meldet sich nicht (bzw. nicht korrekt) in der Multicastgruppe an. Switch weiß nicht, dass er zu der Gruppe gehört --> Filtert. Alternativ wär auch eine Fehlkonfiguration des Switches denkbar. Sicher kann das Problem aber auch noch gänzlich andere Ursachen haben. Zu 2) Wenn du Zeit und Lust und Ahnung hast, kannst du ja mal mit z.B. Wireshark die SSDP Antworten vom funktionierenden SAT-IP und vom DVBViewer abfangen und vergleichen. Ich würde ja fast vermuten, der Recording Service hält sich noch nicht genau genug an die SAT-IP Spezifikationen. Oder der Telestar selektiert und schmeißt alle Server raus, die von anderen Herstellern sind. Halte ich aber auch nicht für sonderlich wahrscheinlich. Kannst ja mal (bzw. hast du sicherlich schon) mal ausschließlich RTSP/sat-ip aktiveren und den DVBServer deaktiveren und auch bei Web/UPnP mal die anderen Services deaktiveren. Auch wär eine Direktverbindung zwischen Server und Telestar interessant. Oder verbunden mittels billig 10€ Switch, der wirklich nur "switcht". Wie gesagt, wirklich helfen kann ich nicht^^ Die einfachste Erklärung ist natürlich, die Implementierung von Sat-IP im Recording-Service ist noch fehlerhaft, will mich da aber auch nicht zu weit aus dem Fenster lehnen xD Edited February 5, 2014 by qupfer Link to comment
Derrick Posted February 5, 2014 Share Posted February 5, 2014 Klingt sehr überzeugend Link to comment
qupfer Posted February 5, 2014 Share Posted February 5, 2014 (edited) Da Editieren schon wieder verboten^^ Mit dem TD 2510 wirst du vermutlich kein Glück haben, da dieser, wohl genau wie sein mehr oder weniger direkter Vorgänger Digibit D1, nur mit dem Digibit R1 zusammenarbeitet. Der Hersteller Telestar hat für seinen HD-fähigen Sat-Receiver TD 2510 HD ein Software-Update veröffentlicht: Die neue Firmware (Version 1.2) ermöglicht es, den TD 2510 HD in Verbindung mit dem SAT-IP-Server DIGIBIT R 1 als SAT-IP-Client einzusetzen. Quelle: http://www.infosat.de/Meldungen/?msgID=74193 Also vermutlich doch die "Wegwerfvariante" und ich habe den RS fälschlicherweise beschuldigt, eine nicht korrekte SAT-IP Implementierung zu haben. Sorry Edited February 5, 2014 by qupfer Link to comment
Griga Posted February 5, 2014 Share Posted February 5, 2014 Ich gehe nicht davon aus, dass die Implementation im Recording Service schon in jeder Hinsicht perfekt ist, und werde mal schauen, was ich im Code zu dem Thema finde. Der vorletzte Beitrag von qupfer hat mir mal wieder gezeigt, wie viel mir noch an Netzwerk-Kenntnissen fehlt. Der RS ist mir ja durch den Abschied von Lars zugefallen - dass ich das Projekt übernehme, war nie so geplant Wenn ich etwas finde, werde ich es hier posten, und vielleicht fällt jemand noch etwas dabei auf oder dazu ein... Die neue Firmware (Version 1.2) ermöglicht es, den TD 2510 HD in Verbindung mit dem SAT-IP-Server DIGIBIT R 1 als SAT-IP-Client einzusetzen. Die Formulierung schließt einen Betrieb mit anderen Servern nicht explizit aus. Dass die Firma nur auf ihr eigenes Produkt verweist, ist eigentlich normal. Link to comment
qupfer Posted February 5, 2014 Share Posted February 5, 2014 Die Formulierung schließt einen Betrieb mit anderen Servern nicht explizit aus. Dass die Firma nur auf ihr eigenes Produkt verweist, ist eigentlich normal. Sicherlich nicht. Da aber es beim 2510 "nur" um ein Patch handelt und der Hauseigene SAt-IP Receiver tatsächlich nur den eigenen Server "versteht" (zumind. soweit mir bekannt. Software ändert sich ja auch gelegentlich^^) halte ich es durchaus für möglich, dass er den Recording-Service ignoriert. Wie auch immer. Ohne nähere Analyse wird man vermutlich so- oder so nicht den schuldigen ausmachen können^^ Ich würde - entgegen meiner vorherigen Aussage - aber mal Probehalber alles was irgendwie UPnP kann anschalten und schauen, ob vielleicht doch irgendwas beim Receiver ankommt. Wenn schon nicht SAT-IP, dann eventuell die Videos und Musik. Soll der 2510 ja mehr oder weniger auch können. Dann fliegt schonmal der Switch aus der "mögliche Ursache" Liste^^ Link to comment
nordkurve Posted February 5, 2014 Author Share Posted February 5, 2014 Danke das Ihr euch so intensiv mit meinem Thema beschäftigt. Die verschiedenen Vorschläge Habe ich teilweise ausprobiert bzw. Mich beim Hersteller der Firma Telestar informiert. Also die Firma Telestar hat mir an der Hotline gesagt das es nicht Die Firmenphilosphie ist Geräte zu beschränken und nur auf ihre Geräte zu spezialisieren, da sie eine kleine aufstrebende Firma (Tochter von Technisat) sind die ihren Namen mit guten ,innovativen Produkten machen möchte. Kann ich verstehen und glaube das auch mal, testen kann ich es bisher nicht. Der Telestar findet im DLNA-app den recording service, zwar nach sehr sehr länger Zeit, aber er findet ihn. Ich kann auch viele streams anwählen und sehen aber nicht alle, keine Ahnung wieso diese dann nicht. Mir scheint auch die Verbindung nicht sehr standhaft da er den sever öfter verliert und dann nicht wieder findet, erst nach einem Neustart des Apps. Der DLNA Serverbetrieb des GSS400 ist dagegen viel stabiler, auch wir dieser viel schneller gefunden. Ich habe dem telestar mittels Switch und vlans nur den recording Service als server gegeben und er findet kein satip, nur DLNA. Ich habe IgMP snooping abgeschaltet, alles gleich. Ich werde morgen beim recording Service alles an Servern bis auf satip abschalten und dann mal sehen wie es dann aussieht. Danke nochmal für eure tatkräftige Hilfe! Link to comment
VIDEOFAN Posted February 10, 2014 Share Posted February 10, 2014 Hallo nordkurve, das Gerät ist ja nicht uninteressant. man bezahlt dafür derzeit kaum noch mehr als 80,- € ? Das ist ja wirklich überraschend günstig. Deshalb ein paar kurze Fragen: empfängt der SAT-Tuner HD-Sender (DVB-S2)? Wie schnell sind die Umschaltzeiten bei SAT>IP (wenn Du den recording service nutzt)? Ist die Box auch als Video-Mediaplayer nutzbar - wenn ja, welche Formate? Kann die alternative FW auch cams nutzen? Hmm - den amazon-Rezensionen nach ist die Netzwerkschnittstelle wohl zu dünn für HDTV und selbst mit dem passenden SAT>IP Router des Herstellers geht wohl auch nur nach FW-update aus dem januar 2014 überhaupt etwas... Klingt schon arg nach unausgereifter beta... Aber das ist ja Mode z.Z. Ich bastle auch derzeit an einem android-Mediaplayer (mit gigabit-LAN ) . Das ist die reinste Baustelle... aber: dank DVBViewer controller app geht das streamen vom recording service auf die Kiste mit HDTV in perfekter Qualität !! Gut.. hat auch fast 100,- € mehr gekostet und echtes zappen geht damit nicht. Aber ich gucke lieber als zu zappen... Danke Videofan Link to comment
nordkurve Posted February 11, 2014 Author Share Posted February 11, 2014 So habe jetzt endlich mal wieder Zeit gehabt mit dem Recording Service und sat ip etwas zu testen. Ergebnis: wenn der DLNA server nicht an ist wird der sat ip server in keinem Client angezeigt. Egal ob ich die anderen Server ausschalte oder eingeschaltet habe wird der satip server des recording Service nicht von meinem telestar client gefunden. Das Elgato App auf dem ipad findet ihn sobald ich den DLNA server anschalte immer, auch wenn ich die Ports der jeweiligen server aber ändere oder oder oder. In Verbindung mit eyetv auf dem mac kann ich bei satip den recording Service anwählen und er wird auch normal erkannt, hier ist mir jedoch zum ersten mal aufgefallen, das die verschlüsselten Sender bei satip nicht unverschlüsselt weitergereicht werden sondern vom recording Service nur durchgereicht werden und der client die Entschlüsselung übernehmen muss, obwohl eigentlich die Karte zur Entschlüsselung am recording Service hängt. Bei DLNA funktioniert dies, hier wird der Stream unverschlüsselt an den client weitergereicht. Bei der octopus net von Digital Devices funktioniert dies, zwar nur für einen satip Stream aber es funktioniert. warum funktioniert dies im recording Service bei satip nicht? Link to comment
Griga Posted February 12, 2014 Share Posted February 12, 2014 warum funktioniert dies im recording Service bei satip nicht? Entschlüsselung durch den Server erfordert die Übertragung zusätzlicher Daten, die der SAT>IP-Standard nicht spezifiziert. Es ist auch nicht zu erwarten, dass sich das in nächster Zeit ändern wird. Dazu kommen rechtliche Unsicherheiten. Deshalb gibt es z. Z. nur proprietäre Lösungen. Die vom RS angwandte Methode funktioniert nur mit Clients aus dem DVBViewer-Umfeld. Die Digital Devices-Methode erfordert Clients, die andere Parameter außerhalb des Standards unterstützen - um welche Software handelt es sich bei dir? Denkbar ist, dass sich die von Digital Devices eingeführte Parameterübergabe als de facto-Standard etabliert und sich daraus eine gewisse Einheitlichkeit ergibt. Wenn diverse SAT>IP-Clients die Methode unterstützen, wird auch eine Implementation im RS in Betracht gezogen werden. Deshalb meine Frage im vorherigen Absatz. Link to comment
dbraner Posted February 12, 2014 Share Posted February 12, 2014 Würde es nicht reichen, wenn der RS die Scrambling Bits im TS zurücksetzt? Ich nehme mal an, dass z.B. Elgato SAT>IP die auswertet während sie VLC ignoriert (dort funktioniert nämlich das Abspielen verschlüsselter Streams per SAT>IP vom RS). Link to comment
CiNcH Posted February 12, 2014 Share Posted February 12, 2014 Würde es nicht reichen, wenn der RS die Scrambling Bits im TS zurücksetzt? Dann sind die TSC-Bits zurückgesetzt und der Stream immer noch verschlüsselt. Was soll das bringen? TSC-Bits werden vom CAM zurückgesetzt, wenn das jeweilige Paket entschlüsselt werden konnte. Ich nehme mal an, dass z.B. Elgato SAT>IP die auswertet während sie VLC ignoriert (dort funktioniert nämlich das Abspielen verschlüsselter Streams per SAT>IP vom RS). Soweit ich weiß, wird im VLC eine m3u Kanalliste importiert, die die zur Entschlüsselung erforderlichen Parameter wie SID und PMT PID enthält. Diese werden dann an den RS übergeben. Die Elgato App macht das nicht. Die Parameter sind im SAT>IP Standard auch nicht spezifiziert. Die Elgato App filtert beim Scan bereits Kanäle heraus, die in der SDT als verschlüsselt markiert sind. Selbst wenn man die SDT beim Scan am RS manipulieren würde (was du wahrscheinlich mit dem Zurücksetzen der TSC-Bits erreichen wolltest), würde die Entschlüsselung nicht funktionieren, weil die benötigten Parameter beim Kanalwechsel nicht übergeben werden. Link to comment
Derrick Posted February 12, 2014 Share Posted February 12, 2014 Dann sind die TSC-Bits zurückgesetzt und der Stream immer noch verschlüsselt. Was soll das bringen? TSC-Bits werden vom CAM zurückgesetzt, wenn das jeweilige Paket entschlüsselt werden konnte. Genau. Zurücksetzen wäre wohl das schlimmste was man machen könnte, denn welche instanz soll die streams dann im weiteren verlauf noch als verschlüsselt erkennen? Ein CI-modul jedenfalls nicht. Nur eine sehr proprietäre lösung könnte damit was anfangen Link to comment
Recommended Posts