Features neue RS- und kommende DVBViewer-Version

[dbraner]

Heute mal keine Frage oder Problem sondern eine Bitte:

 

Wenn ich mir die Änderungen in der 1.20 des RS anschaue und die Hinweise "für kommende DVBViewer Version" scheinen sich hier einige große funktionale Änderungen bzw. Erweiterungen anzudeuten.

 

Daher die Bitte, mal ausnahmsweise neben der Auflistung der neuen Funktionen eine etwas ausführlichere Beschreibung bei der Ankündigung mitzuliefern. Gerade für Einsteiger ist das sonst kaum noch zu überblicken, was sich geändert hat, welche Konsequenzen die Änderungen haben und was die neuen Funktionen wirklich bringen.

 

Beispiel: RS stellt von Unicast aus RTSP um. Schön das zu wissen. Und jetzt? Was habe ich jetzt mehr an Funktion? Was wird dadurch besser? Was muss ich beachten?

[mague]

SAT>IP ist, soweit ich es verstehe, ein Protokoll mit zwei Schichten. Das Uni- oder Multicast ist dann die Datenschicht und die zweite Schicht dient zur Kontrolle. Das macht der DVBV und der RS zur Zeit ueber die http api.

 

Ich glaube nicht das sich sehr viel aendert. Man kann halt auf dem RS Rechner Sofortausnahmen machen. Mittelfristig wird sich der Zugriff auf die hardware evtl. verbessern. SAT>IP scheint einfach eine bessere Basis fuer die Zukunft da ein Standart.

Edited August 30, 2012 by mague

[nuts]

http://www.ses.com/satip

Dazu gibt es ein paar Erweiterungen, die den DVBViewer betreffen (z.B. CI Handling am Server und nicht am Client wie SES das vorsieht).

 

http://de.wikipedia.org/wiki/Real-Time_Streaming_Protocol

 

Mittelfristig ändert sich die Datenübertragung vom Server zum Client.

Über UDP ists etwas schlanker, das System flexibler - z.B. soll damit auch Transedit irgendwann mal über den Client möglich sein, Sat>IP Hardware für den DVBViewer usw.

 

Bei der UDP Variante ist zu beachten, dass im Netzwerk die Übertragung nicht vom Router/Firewall o.a. gestört wird.

Sonst klappt das eigentlich schon sehr gut. Auf die neue DVBViewer Version muss natürlich noch gewartet werden. Bis jetzt gibts ja kein RTSP Device.

Edited August 30, 2012 by nuts

[Portisch]

SAT>IP scheint einfach eine bessere Basis fuer die Zukunft da ein Standart.

 

Sehe ich auch so!

Schlimm gesagt bietet es Ausweichmöglichkeiten zum DVBViewer als Client.

Fertige Hardware (SAT>IP Clients) ist im kommen.

Wenn nicht sogar in naher Zukunft die SAT>IP Clients direkt im TV umgesetzt werden.

 

Meine Idee wäre ja diese Config:

Raspberry Pi + OpenELEC

 

Wenn nun mein alter LCD-TV auch HDMI CEC (Steuerung des RaspberryPi durch die TV Fernbedienung) könnte wäre es schon bestellt!

 

OpenELEC(XBMC) kann aber auch noch kein SAT>IP - noch nicht...

Edited August 30, 2012 by Portisch

[Tjod]

Die größte wahrnehmbare Änderung dürfte sein das man die Installationsanleitung für den RS auf die Hälfte zusammen streichen kann wenn es die neue DVBViewer Version gibt.

Um den DVBViewer zu konfigurieren IP auswählen > Benutzername und Passwort eingeben > Test > Weiter > Fertig

[dbraner]

Es ist ja sehr nett und sicher gut gemeint dass Ihr hier jetzt einzelne neue Features aufzählt.

 

Ich hatte mit meinem Post aber etwas anderes im Sinn: Wenn das nächste DVBViewer Release rauskommt, wird es wieder eine Mitteilung im im Forum "Ankündigungen" geben, in dem auch stichwortartig die Neuigkeiten genannt werden. Es wäre schön, wenn diese Release Notes etwas ausführlicher ausfallen könnten, damit auch normalsterbliche User verstehen, was eine Funktion bedeutet bzw. welche Möglichkeiten sich eröffnen.

 

Ihr schreibt hier "mit SAT>IP kann man auch andere Clients" benutzen. Genau das meine ich. In der Ankündigung steht in diesem Fall üblicherweise "der RS unterstützte jetzt SAT>IP". Ja und nun? Ist ja toll. Kann ich damit jetzt bunte Blümchen einblenden, mein persönliches Wohlbefinden steigern oder ... ?

 

Man muss sich einfach mal in die Situation eines Normal-Benutzers reindenken, der kein Software-, TV- oder Streaming-Spezialist ist und auch nicht die Muse hat, tagelang rumzutüfteln. Der möchte einfach die Software in all ihrer Funktionsvielfalt optimal nutzen. Und das kann er nur, wenn er die Features versteht.

[LocalHolgi]

Oh mann, das nervt - ich habe den Eindruck mancheinem muss man alles direkt vor den Poppes karren und ausführlich erklären. Bis jetzt waren die Changelogs doch ausführlich und ich denke mal ein Grund warum die neue Version noch nicht veröffentlicht wurde ist genau das. Da muss man noch auf Deutsch und Englisch etwas schreiben, damit auch der letzte nicht rumnölt weil wieder alles nur in Englisch erklärt wird. Ich meine es kann doch nicht so schwer sein die Google zu nutzen und sich mal wegen Sat>IP zu belesen.

[BALOU]

Versteh nicht wie man eine Frage zu größeren Änderungen als Nerverei bezeichnen kann.

Das LocalHolgi googeln kann wissen wir nun aber wirklich helfen wird das auch keinem.

Leider ist mein Post genauso sinnvoll,konnte ich mir aber nicht verkneifen.

Edited August 30, 2012 by BALOU

[guenti51]

Nun, im Endeffekt geht es doch darum, daß etwas verkauft werden soll.

Ein Unternehmer sollte auch unternehmerisch denken und den Kunden bei seiner Kaufentscheidung

positiv beeinflussen, indem er ihn von den Nutzen seines Produktes überzeugt.

Das Zauberwort heisst hier KUNDENNUTZEN !

 

http://de.wikipedia.org/wiki/Kundennutzen

 

Mit einer fragwürdigen Beschreibung wird das schwerer zu erreichen sein.

Und wenn man Kunden als nervend empfindet ...

[dbraner]

Oh mann, das nervt ... sein die Google zu nutzen

 

Vielen Dank für Deinen konstruktiven Beitrag, den ich Deinem Rat folgend sogleich mit Google ins Englische übersetzt habe:

 

Oh man, that sucks - I feel many a need to barrow everything right in front of the Poppe and explain in detail. Until now, the changelogs but were extensively and I guess one of the reasons why the new version has not been released is just that, since you have yet to write something in German and English, so that the last non rumnölt again because everything is explained in English . I mean it can not be that hard to use the Google and even to well-read because satellite> IP.

 

und gleich nochmal zurück nach deutsch:

 

Oh Mann, saugt das - ich fühle mich viele das Bedürfnis, barrow alles direkt vor der Poppe und erklären im Detail. Bis jetzt wurden die Changelogs waren aber ausgiebig und ich denke, einer der Gründe, warum die neue Version nicht freigegeben wurde ist nur, dass, da Sie noch etwas in deutscher und englischer Sprache zu schreiben, haben, so dass der letzte nicht rumnölt wieder, weil alles erklärt in englischer Sprache. Ich meine, es kann nicht so schwer sein, die Google und sogar gut zu lesen, weil satellite> IP verwenden.

 

Was lernen wir daraus? Ein Text wird durch eine Google-Übersetzung nicht gehaltvoller und erst recht nicht verständlicher.

[dgdg]

Das Zauberwort heisst hier KUNDENNUTZEN !

 

Naja, Marketing ist sicher nicht die große Stärke des DVBViewer-Teams. Viele technische Features erschliessen sich einem nicht oder man versteht erst nach Jahren wozu irgendeine Funktion mit kryptischer Bezeichnung eigentlich gut ist. Ich stelle mir gerade vor, dass man bei jeder Werbung erstmal googelen muss, um zu verstehen, was eigentlich damit gemeint ist und wozu man das braucht.

 

Aber sowas gehört nicht ins Changelog sondern in ein Strategiepapier oder eine Roadmap (gibt's natürlich nicht).

 

Ganz unabhängig davon ist SAT>IP eine feine Sache und ich finde es gut, dass der DVBViewer so weit wie möglich auf Standards setzt. Aber besser fände ich es, wenn erstmal die uPnP-Server-Funktionen fertig gemacht worden wären, statt wieder eine neue Baustelle aufzumachen.

 

Viele, viele Features, aber die meisten sind nicht fertig.

Edited August 30, 2012 by dgdg

[masterandy]

Nun ja...jetzt gebe ich noch meinen Senf dazu, bevor der Thread geschlossen wird wegen allzu langer Grundsatzdiskussion. Fakt ist eins, der fehlende Kundenservice und eine nicht vorhandene gute FAQ für Dummies ist echt das größte Handicap des DVBViewer´s. Grunsätzlich ist aber eine einfachere Installation des RS zu befürworten. Auch eine bessere Integration und einfachere Integration des DVBViewer Clients wäre einer der nächsten folgenden logischen Schritte und würde Herrn Hackbarth neue Kunden erschließen.

Vielleicht sollte man wirklich mal über eine bessere für Laien erschliessbare Roadmap nachdenken. Leider hat der DVBViewer ab der 4.x Version an Übersichtlichkeit bei Plugins, OSD Skins bzw Intergration neuer Features an Übersichtlichkeit mächtig verloren.

Auch die Versions Politik lässt einen gewissen Hang zum Überperfektionismus erkennen ( Wieviel Versionen braucht man noch bis zu Version 5?), statt umzudenken und lieber bessere und einfachere Schnittstellen zu liefern.Es seien da nur Bluray, Standby und die vom Entwicklerteam gehassten Favoriten genannt.

Das witzigste an der Produktpolitik des DVBViewers ist immer das Features die am Anfang total abgelehnt wurden, später dann doch in den DVBViewer integriert wurden. Eine Sache die sich mir nie erschliessen wird.

[Goggo16]

"Gut Ding will Weile haben."

 

Abgesehen davon muss man nicht mit aller Gewalt jedes vorhandene [neue] Feature mit aller Gewalt benutzen wollen, es sei denn man findet Gefallen daran und/oder braucht es sogar.

 

... just my two cents ...

Edited August 30, 2012 by Goggo16

[masterandy]

"Gut Ding will Weile haben."

 

Abgesehen davon muss man nicht mit aller Gewalt jedes vorhandene [neue] Feature mit aller Gewalt benutzen wollen, es sei denn man findet Gefallen daran und/oder braucht es sogar.

 

... just my two cents ...

 

...man sollte sich aber auch nicht verzetteln...;-)

[LocalHolgi]

Ich bin mir sicher das man sich hier definitiv nicht verzettelt, ich denke eher das man in der Entwicklung langfristig den Schwerpunkt auf eine Serverlösung legt, um diese dann irgendwann als eigenständiges Produkt zu vermarkten. Warum? Nun der Recordingservice kann weit mehr als alles was auch nur im Ansatz in dieser Richtung existiert. Er ist ein vollständiger UPNP/DLNA Server der nun auch noch als allererstes Produkt auf dem Markt Sat>IP anbietet und zentral Aufnahmen erstellen kann. So eine Lösung ist, gleich was diese mal kosten sollte mit Abstand die günstigste Variante für Hotels, Firmen und sonstige Kunden die ernsthaft Video und Radio über Netzwerk an mehrere verschiedene Endgeräte übertragen wollen.

 

Ich wage außerdem zu bezweifeln das die meisten Nutzer auch nur im Ansatz alles was man hier in und um den DVBViewer herum angeboten bekommt überhaupt nutzt. Wer verwendet denn die Suchfunktion im Service um automatisiert Serien und Filme aufzuzeichnen? Oder streamt via WLAN TV an den Fernseher bzw. das Radio im Schlafzimmer?

 

Das Zauberwort heisst hier KUNDENNUTZEN !

 

http://de.wikipedia....ki/Kundennutzen

 

Arg da krieg ich Plaque, das Hauptproblem vom DVBViewer ist die "Updates inklusive"-Strategie. Das schafft nur eine Zielgruppe die gierig, frei nach dem Motto "Geiz ist geil" permanent ningeln und nach neuen Funktionen schreien, ohne aber den Gedanken daran zu verschwenden das eine Entwicklung auch Geld kostet. Ich würde auf kurz oder lang die derzeitige Lösung in ein nur Minor-Updates inklusive ändern. Das man das nach über 10 Jahren Entwicklung noch nicht getan hat ist löblich, aber einige Threads hier zeigen ja das das definitv nix bringt.

[dbraner]

Bevor die Diskussion jetzt völlig abdriftet: ich wollte hier keinesfalls die Integration zu vieler Features kritisieren. Mir geht es nur um eine verständliche Darstellung für einen Normaluser, gerade wenn eine Funktion neu eingeführt wird.

 

Bisher hatten die Entwickler ein gutes Gespür für Dinge, die sagen wir mal angesagt sind. Da gehört SAT >Ip eindeutig dazu. Nur muss man dem User auch die Vorzüge verkaufen. Ich kenne allein 2 Leute, die es nur mit meinem Support geschafft haben, den DVBViewer vernünftig zu konfigurieren bzw. all die schönen Features zu nutzen.

 

Ich kann auch mit der bisherigen knappen Form der Releasenotes einigermaßen leben. Ich glaube nicht, dass das für den Großteil der Nutzer gilt.

[dbraner]

 

Ich wage außerdem zu bezweifeln das die meisten Nutzer auch nur im Ansatz alles was man hier in und um den DVBViewer herum angeboten bekommt überhaupt nutzt. Wer verwendet denn die Suchfunktion im Service um automatisiert Serien und Filme aufzuzeichnen? Oder streamt via WLAN TV an den Fernseher bzw. das Radio im Schlafzimmer?

.

 

Weil die Nutzer gar nicht wissen, dass es diese Funktion gibt? Das meine och ja gerade.

[masterandy]

Bevor die Diskussion jetzt völlig abdriftet: ich wollte hier keinesfalls die Integration zu vieler Features kritisieren. Mir geht es nur um eine verständliche Darstellung für einen Normaluser, gerade wenn eine Funktion neu eingeführt wird.

 

Bisher hatten die Entwickler ein gutes Gespür für Dinge, die sagen wir mal angesagt sind. Da gehört SAT >Ip eindeutig dazu. Nur muss man dem User auch die Vorzüge verkaufen. Ich kenne allein 2 Leute, die es nur mit meinem Support geschafft haben, den DVBViewer vernünftig zu konfigurieren bzw. all die schönen Features zu nutzen.

 

Ich kann auch mit der bisherigen knappen Form der Releasenotes einigermaßen leben. Ich glaube nicht, dass das für den Großteil der Nutzer gilt.

 

Keiner will die Entwickler kritisieren. Das Marketing bzw. das Handling der Releasenotes ist der Kritikpunkt. Erst wird von seiten der Entwickler negativ auf einen Vorschlag reagiert und dann wird das Feature doch integriert. Das macht das Ganze nicht unbedingt glaubhaft und wird für den Normaluser undurchsichtig. Eine klare Linie gegenüber dem "Normaluser" wäre wünschenswerter.

Edited August 30, 2012 by masterandy

[hackbart]

Das Problem ist das es schlichtweg an Zeit fehlt alles vollständig zu dokumentieren. Das ganze muss in Englisch und in Deutsch geschrieben werden und da Anleitungen eh von kaum jemanden wirklich gelesen werden sehe ich auch keinen Sinn da viel Zeit zu investieren. Sieht man mal davon ab das der DVBViewer viel Zeit kostet, es kommt ja auch noch die OEM dazu und etliche Subprojekte die gepflegt werden müssen. Von den Emails und Telefonaten mal völlig abgesehen.

Christian

PS: Schon halb 10 und ich bin immer noch im Büro - seit heute morgen.

[masterandy]

Das ist halt das Los eines jeden Unternehmers, das mit der langen Arbeitszeit.Und ich denke das nicht wenige die Anleitungen lesen. Leider habe ich momentan das Gefühl das der DVBViewer entwicklungstechnisch hinter dem Recordingservice hinterher hängt. Die Zusammenarbeit gerade in der Bedienung des OSD ist nicht unbedingt optimal.

[Tjod]

Wer der Meinung ist das gute erklängen wichtig sind, kann gerne Entsprechende Artikel im Wiki verfassen.

Und damit jetzt keiner mit dem Argument kommt dass er ja nicht genug dafür weiß, jeder der was fürs Wiki schreiben möchte aber Wissenslücken hat kann mich gerne auch per PM anschreiben oder ein Topic hier im Forum auf machen.

Dem erkläre ich das gerne so dass derjenige dass versteht.

Und bevor jetzt jemand schreibt dann kann ich gleich einen Wiki Artikel dazu schreiben, Nein! zumindest bei mir liegen zwischen einer Erklärung die für eine Person reicht und einem möglichst allgemeinverständlichen ausformulierten Wiki Artikel im normal Fall ein paar Stunden an Arbeit.

 

Ich denke nicht das Zeit mit Erklärungen verschwendet werden sollte wo es nicht nötig ist.

 

Mit der Nächten Version ändert sich für die meisten Nutzer wahrscheinlich nichts merklich. Und ändern muss erst mal auch niemand was.

Und für die die auf RTSP umstellen wollen wird es schon eine kurze Erklärung geben wie man den Wizard aufruft.

 

Und anstatt hier die Zeit mit jammern zu verbringen sollte ihr euch lieber überlegen wie kann ich persönlich die Entwickler unterstützen, so das die sich auf das weiter entwickeln konzentrieren können und nicht die meiste Zeit mit dem drumherum beschäftigt sind.

 

Und zu den ganzen Kommentaren zu Kundennutzen usw. Jeder der den DVBViewer einmal erworben hat ist in den allermeisten fällen kein Kunde mehr. Kunde sind nur Person die Planen den DVBViewer zu Kaufen. Wenn ihr als Kunde wahrgenommen werden wollt müsst ihr Kostenpflichtige Updates fordern. Und bis ihr die dann gekauft habt seit ihr wieder Kunden und könnt sagen was gemacht werden muss damit ihr für das Update Geld ausgebt.

Ein Kunde ist eine Person oder eine Institution, die ein offensichtliches Interesse am Vertragsschluss zum Zwecke des Erwerbs eines Produkts oder einer Dienstleistung gegenüber einem Unternehmen oder einer Institution zeigt.

http://de.wikipedia.org/wiki/Kunde

 

Solange ihr für die Entwickler nicht den Anreiz bietet, dass ihr ihnen für Verbesserung denen für den Aufwand angemessenen Betrag zahlt, bleibt nur durch Entlastungen dafür zu sorgen das mehr Zeit für die von euch gewünschten Funktionen zur Verfügung steht.

[stargate2k]

Hi,

 

"Wer verwendet denn die Suchfunktion im Service um automatisiert Serien und Filme aufzuzeichnen?"

 

was für ne Suchfunktion ? meinst du die normale Aufnahmefunktion ?

 

mfg stargate

[VinoRosso]

Nun der Recordingservice kann weit mehr als alles was auch nur im Ansatz in dieser Richtung existiert.

 

Mittlerweile gibts genug Alternativen zum RecordingService die ähliches leisten noch dazu verschiedene Frontends unterstützen...

 

Der Zug das richtig zu vermarkten ist schon abgefahren.... mal wieder zu spät...

 

 

[pyro]

Die sind aber nicht mal eben eingerichtet,der RS ist recht einfach gehalten und schnell zu verstehen

 

Sat-IP könnte echt was werden,freue mich drauf.

[Tjod]

was für ne Suchfunktion ? meinst du die normale Aufnahmefunktion ?

http://de.DVBViewer.tv/wiki/Webinterface_-_EPG_Suche#Suchvorgaben

[dgdg]

Ich hatte mir das Thema SAT>IP gestern nur mal auf die Schnelle bei Wikipedia eingezogen und dachte: Super. Genau das, was ich brauche und mit RS und DVBViewer auch schon lange mache - nur eben Standard.

 

Jetzt habe ich nochmal nachgelesen und verstanden, dass das überhaupt kein Standard ist, sondern eine propritäre Geschichte von Astra. Produkte sind zur IFA angekündigt - heisst es gibt vielleicht ein paar Entwicklungsmuster von ein paar Firmen, die mal schauen wolle, ob das ein Markt wird.

 

Aber ob sich das durchsetzt und ob wirklich Endgeräte auf den Markt kommen, weiss im Moment niemand.

 

Wenn SAT>IP für die Kommunikation des DVBViewer mit dem RS hilfreich ist - von mir aus. Aber sonst wird man als Anwender wohl erstmal keine großartigen Vorteile haben.

 

Und ist das eigentlich das gleiche wie IPTV, oder ist das wieder was anderes?

Edited August 31, 2012 by dgdg

[Tjod]

Bei IPTV sind die Sender immer Fest einer IP und Port Kombination zugeordnet. Das heißt ein Server kann immer nur so viele Sender insgesamt anbieten wie er auch gleichzeitig empfangen kann. Und ein Client kann nur zwischen den Sendern umschalten die der Server anbietet.

 

So was ist mit Multicast angedacht. Aber das ist weniger was für Endanwender. Da man ziemlich viele TV-Karten braucht und auch entsprechende Netzwerk Hardware, die mit großen Datenmengen per Multicast umgehen kann.

[Lars_MQ]

Wenn SAT>IP für die Kommunikation des DVBViewer mit dem RS hilfreich ist - von mir aus. Aber sonst wird man als Anwender wohl erstmal keine großartigen Vorteile haben.

Das ist tatsächlich sehr hilfreich und wir arbeiten auch mit SES (=ASTRA) zusammen, um diesen standard zu pushen.

Der hintergrund gedanke, sprich die RTSP/RTP7RTCP schiene wird auf jeden fall die Unicast schiene des RS ablösen und dabei so kompatibel wie möglich zu SAT>IP bleiben.

 

Und ist das eigentlich das gleiche wie IPTV, oder ist das wieder was anderes?

IPTV ist ein Multicast system. Das heisst es wird eine bestimmte anzahl von sendern angeboten und beliebt viele clients können sie empfangen.

 

SAT>IP definiert sowohl eine Multicast streaming variante, als auch eine on demand (unicast) variante.

 

Der Unterschied:

Multicast ist für die (private) wald und wiesen netzwerk technik unbedingt nicht geeignet, sondern eher etwas für professionelle technik, die IGMPv3 unterstützt. Es werden in diesem Modus permanent x sender ins netzwerk übertragen und beliebig viele Empfänger können diese streams empfangen.

 

Der unicast Modus ist vergleichbar mit unserem alten unicast devices. Resourcen (->DVB-Devices) und Daten werden nur bei bedarf belegt bzw übertragen.

 

Insgesamt lässt sich sagen: Die Änderungen mit SAT>IP bzw RTSP wirken sich nicht grossartig aus, wenn das ganze wie zuvor (-> Unicast) eingesetzt wird.

 

Die IPTV variante wird wesentlich teurer und das betrifft nicht nur die hardware...

[dgdg]

Das ist tatsächlich sehr hilfreich und wir arbeiten auch mit SES (=ASTRA) zusammen, um diesen standard zu pushen.

Der hintergrund gedanke, sprich die RTSP/RTP7RTCP schiene wird auf jeden fall die Unicast schiene des RS ablösen und dabei so kompatibel wie möglich zu SAT>IP bleiben.

 

Und über eine Zusammenarbeit mit Astra winkt dann natürlich wieder das eine oder andere OEM-Geschäft für euch.

Völlig legitim, denn das sorgt ja auch dafür, dass die DVBViewer-Entwicklung weitergeht.

 

Schade nur, wenn dabei das uPnP-Thema zurückstehen muss oder vielleicht sogar ganz hinten runterfällt. Denn das ist das, worauf hier sicher viele warten (DVBViewer als DLNA-Client und Controller). Dafür gibt es passende Server und Clients in Massen. Jedes popelige Internetradio, jeder Internetrouter und jedes Lowcost-NAS unterstützt das inzwischen mehr oder weniger gut.

 

Andererseits ist der DVBViewer in erster Linie eine TV-Software und kein Multimedia-Client. Was die Priorisierung eines TV-Protokolls wie SAT>IP gegenüber uPnP erklärt.

 

Aber genau über diese strategischen Überlegungen wüsste man eben gerne mehr - womit wir wieder beim eigentlichen Thema von dbraner wären.

 

Wir sind ja hier alle nicht nur Beta-Tester für die OEM-Kundschaft sondern investieren auch viel Zeit, um den DVBViewer sinnvoll einsetzen zu können.

Also ab und zu mal ne Info, wo die Reise (gerade) hingeht, wäre schon fair.

Edited September 1, 2012 by dgdg

[Lars_MQ]

Schade nur, wenn dabei das uPnP-Thema zurückstehen muss oder vielleicht sogar ganz hinten runterfällt. Denn das ist das, worauf hier sicher viele warten (DVBViewer als DLNA-Client und Controller). Dafür gibt es passende Server und Clients in Massen. Jedes popelige Internetradio, jeder Internetrouter und jedes Lowcost-NAS unterstützt das inzwischen mehr oder weniger gut.

Das problem ist nicht wirklich der DVBViewer, sondern Directshow.

Der viewer kann den UPnP kram schon länger, ich binde das nur nicht ein, weil das mega chaos gibt.

 

Bei UPnP ist nämlich directshow dafür verantwortlich, die Medien zu erkennen und wieder zu geben.

 

Und wie die erfahrung zeigt, wird das bei den meisten schief gehen wegen fehlender codecs/splitter und ich habe den stress, weil DVBViewer ist ja schuld...

[Goggo16]

Hi,

 

uPnP hat doch (wenn ich mich nicht taeusche) einen entscheidenden Nachteil: Es kann kein Live-TV.

 

Mit dem Sat>IP koennte ich mir vorstellen, dass der RS und auch der neue DVBViewer kuenftig ganz ohne eigene TV-Hardware (Sat-Karten, Sat-Sticks, etc) wird auskommen können. Die werden den (ich nenne es mal) Sat->IP-Umsetzer direkt ansprechen, um auf einen bestimmten Sat-Kanal zu tunen. Den Rest macht dann der Sat->IP-Umsetzer.

 

Eigentlich wäre so ein Ding doch so ähnlich wie Sat-USB-Sticks, nur das man sozusagen den USB-Anschluss durch einen Netzwerkanschluss ersetzt hat.

 

 

Wird im RS die uPNP-Funktion mal dem Beta-Stadium entwachsen sein, dann kann ich mir durchaus vorstellen, dass der RS einem uPNP-Server überlegen sein könnte - besonders weil er eben auch LiveTV kann.

 

... just my two cents.

 

Grüße

 

Goggo

Edited September 1, 2012 by Goggo16

[dgdg]

uPnP hat doch (wenn ich mich nicht taeusche) einen entscheidenden Nachteil: Es kann kein Live-TV.

Doch, kann es. Mit einem ganz normalen uPnP-Client (Hardware oder Andoid-App) kann ich auf dem RS einen TV-Kanal anwählen und Live-TV schauen.

Aber ob ich mit SAT>IP an meine Mediensammlung rankomme, da habe ich so meine Zweifel.

 

 

Mit dem Sat>IP koennte ich mir vorstellen, dass der RS und auch der neue DVBViewer kuenftig ganz ohne eigene TV-Hardware (Sat-Karten, Sat-Sticks, etc) wird auskommen können. Die werden den (ich nenne es mal) Sat->IP-Umsetzer direkt ansprechen, um auf einen bestimmten Sat-Kanal zu tunen. Den Rest macht dann der Sat->IP-Umsetzer.

Mal schauen, wann man die kaufen kann. Aber das ist gar nicht das Problem, denn die SAT>IP-Umsetzung wird ja der RS machen.

 

Das Problem sind die Clients. Ich will ja gerade weg vom DVBViewer und von den aufwändigen und anfälligen Windows-HTPC in jedem Zimmer. Da sollen kleine schnuggelige uPnP-Clients hin. Die Bedienung und das EPG könnte man super über Android Phones oder (wenn es sein muss) über iPhone machen. Dann muss man das nicht dem uPnP-Client beibringen und man braucht kein Opernglass mehr um bei kleineren Bildschirmen das EPG zu lesen. Auch das Fernbedienungswirrwarr hätte ein Ende und man braucht keine Zusatzdisplays mehr zum Radiohören. Android Phones gibt es ab 99 Euro.

 

Aber genau bei der uPnP-Weiterentwicklung und bei der API im RS um mit Apps anzudocken, geht es nicht weiter. Daraus schließe ich, das dieses Konzept nicht gewünscht ist. Und ich denke, dass das auch daran liegt, dass damit bei den OEM-Kunden nichts zu holen ist. Denn für die Hardwarehersteller ist das nicht sehr lukrativ, wenn sie komplett austauschbar werden.

 

Bei Feten steuere ich die Musik inzwischen komplett übers Android Phone (Remotecontrol für Winamp).

Und mit den uPnP-Client schicke ich Musik aus der Sammlung vom uPnP-Server aus auf irgendeines meiner Internetradios, weil die alle uPnP können (Play-to-Funktion).

 

Das sind die Funktionen, wo Freunde und Bekannte erst ungläubig nachfragen und dann blass werden vor Neid. ;-)

 

Und genau das hatte Lars für Videos über uPnP in Aussicht gestellt. SAT>IP lässt sich da erstmal überhaupt nicht integrieren weil es wiederum andere Clients braucht. Also tolle neue Technik aber überhaupt kein Fortschritt für den Anwender.

[Goggo16]

Hi dgdg,

 

mit dem "Nachteil von uPnP - kann kein LiveTV" meinte ich andere uPNP-Server ausser dem RS.

 

 

die SAT>IP-Umsetzung wird ja der RS machen.

 

Ahhh, OK. Ich hatte mir das bislang anders vorgestellt.

 

Ich hatte mir mal auf der Aastra-Seite das kleine Video dazu angesehen. Da war dargestellt, dass der Sat->IP-Umsetzer quasi wie ein Sat-Verteiler unterm Dach anzusehen ist, oder diesen quasi sogar ersetzt. Von dort gehen eben keine Koax-Strippen mehr weg, sondern (ein ?) LAN-Kabel. Und diese Umsetzer unterstützen eben dieses RTSP-Protokoll (oder so ähnlich), über welches dann mit dem RS/DVBViewer die Verbindung aufgebaut werden kann.

 

Wenn nun der RS bzw. DVBViewer (neu) zum Sat->IP-Umsetzer, ist das eine andere Sache. Dann wäre die PC-Box mit den Sat-Karten und RS sozusagen der Umsetzer. Auch OK.

 

Wobei mir eigentlich die erste Lösung besser gefallen würde, da dann im Haus keine Koax-Kabel mehr gezogen werden müssen. Die Ultra-Vorstellung wäre ja, dass aus dem LNB nur noch ein LAN-Kabel rauskommt. ("Aber habe ich das nicht irgendwo auch schon mal gesehen, zumindest konzeptionell?"

 

Grüße

 

Goggo

[playboy]

" Wobei mir eigentlich die erste Lösung besser gefallen würde, da dann im Haus keine Koax-Kabel mehr gezogen werden müssen. Die Ultra-Vorstellung wäre ja, dass aus dem LNB nur noch ein LAN-Kabel rauskommt. ("Aber habe ich das nicht irgendwo auch schon mal gesehen, zumindest konzeptionell?"

 

mit Sicherheit nicht, aber was Du meinen könntest, wäre die Ausführung wo der LNB-Ausgang als Lichtleiterkabel konfektioniert ist, aber das ist eine andere Baustelle.

[Schlonzo]

Sogenannte IP-LNBs sind von Astra/SES durchaus angedacht:

 

SATIP-Fragen-und-Antworten.pdf

[Lars_MQ]

Man sollte sich vor augen halten, das SES bei SAT>IP das CI/CAM beim Client nicht beim "Server" vorsieht...

 

Das lässt sich zwar im DVBViewer mit den DD CI Modulen (http://shop.digital-devices.de/epages/62357162.sf/de_DE/?ObjectPath=/Shops/62357162/Products/092024) lösen, sobald ich dazu komme, die sachen umzusetzen und an die virtuelle hardware zu koppeln. Aber das schränkt das ganze natürlich etwas ein...

[dbraner]

Bei IPTV sind die Sender immer Fest einer IP und Port Kombination zugeordnet. Das heißt ein Server kann immer nur so viele Sender insgesamt anbieten wie er auch gleichzeitig empfangen kann. Und ein Client kann nur zwischen den Sendern umschalten die der Server anbietet.

 

So was ist mit Multicast angedacht. Aber das ist weniger was für Endanwender. Da man ziemlich viele TV-Karten braucht und auch entsprechende Netzwerk Hardware, die mit großen Datenmengen per Multicast umgehen kann.

 

Oje, das mit dem IPTV und dem Multicast solltest Du noch mal googeln. Multicast ist gerade dafür gedacht, Bandbreite / Datenmenge zu sparen, indem er Datenstrom an jedem Netzwerkknoten repliziert wird.

 

Beim klassischen Streaming gibt es eine dedizierte Verbindung zwischen Client und Server. Dadurch wächst die benötigte Bandbreite proportional zur Anzahl der Clients.

 

Um diesen Nachteil des Streamings etwas abzumildern, setzt man neuerdings auf CDNs (Content Delivery Networks). Das ist im Prinzip verteiltes Streaming über spezielle Netzwerk-Devices. Die eigentlichen Server versorgen die CDN-Komponenten mit den Streams, die wiederum die Clients versorgen.

 

Alles zusammen (Multicast, Streaming, CDNs) könnte man als IPTV bezeichnen. Ist eben nichts anderes als die Verteilung des TV-Signals über ein IP-Netz.

[Lars_MQ]

Du hast das grundprinzip von IPTV nicht verstanden.

 

Multicast/IPTV:

Der server sendet eine FESTE anzahl von vorgebenen sendern.

Stell Dir das als hotelsystem vor. es werden 25 sender eingespeist. diese 25 Sender können von beliebig vielen clients empfangen werden.

Durch eine entsprechende Netzwerk infrastruktur mit igmpv3 routern wird die bandbreiten in den einzelnen netzwerksegmenten im rahmen gehalten. Wobei das backbone dennoch die bandbreite für die 25 sender liefern muss. Der Server muss natürlich entsprechend viele empfangseinheiten vorhalten.

 

Unicast/TV on Demand

Hier fordern die clients beliebige sender an. Sofern die hardware resourcen bereit stehen (DVB-Tuner) bekommt jeder client einen eigenen stream. Das ist natürlich bandbreiten intensiver aber man kann im ideal fall ALLE verfügbaren sender eines SAT tunen.

Dieses System ist für haushaltsinstallationen mit einer übersichtlichen anzahl von clients sicherlich wesentlich besser, da zum einen die netzwerkinfrastruktur viel simpler ist und zum anderen die erforderlichen DVB resourcen auf dem server dynamisch zugewiesen werden können.

 

 

CDNs sind nett, haben mit sicherheit aber ganz und gar nichts mit LIVETV zu tun.

[Tjod]

@dbraner ich weiß wie Multicast funktioniert und Lars hat ja schon versucht dir die Problematik zu erklären.

Mein Kommentar bezog sich darauf dass die Billig Router die bei den allermeisten zu hause stehen mit Multicast Probleme haben.

Mache unterstützen dass überhaupt nicht und andere unterstützen dass zwar, aber schaffen da nur ein 1/10 von der Datenmenge die sie bei Unicast Verbindungen verkraften ohne dass die Pakete beschädigen oder hängen sich nach nicht mal einer Stunde auf und es hilft nur noch ein Reset.

 

Und wie du CDNs beim Streamen von Live TV einsetzen willst würde mich echt mal interessieren.

Und komm mir jetzt nicht mit Anycast und mehrere Server mit TV-Karten drin. Dann kannst du dass in einem LAN gleich einfach aufteilen. Außerdem geht Anycast mit den Billigroutern auch nicht

[marni]

Man sollte sich vor augen halten, das SES bei SAT>IP das CI/CAM beim Client nicht beim "Server" vorsieht...

 

Und da fängt es dann wieder an die Kunden zu nerven...