Client/Server Diskussion aus dem SoftHDDevice Thread

geronimo · 12. April 2012

Zitat

Abgetrennt vom Thread "softhddevice - nach 0.5.0 wie gehts weiter?"
Dirk

Hi,

Zitat

... und die multimediazeiten des VDR sind vorbei: wie Gerald schon sagt, dafür gibts xbmc!

Huch?!?

Also das sehe ich definitiv anders!
Mag ja sein, dass ich da wieder mal ganz alleine mit meiner Meinung stehe, aber XBMC kommt mir nicht auf die Platte. Ich wüsste auch garnicht wozu.
Bis auf mkv kann der VDR doch alles abspielen, was ich möchte.

Zitat

Einfach nur in einen vdr-lesbaren Container umpacken. Oder dem vdr andere Container beibringen.

ersteres halte ich akzeptabel für eine Übergangslösung, aber nicht als Ziel.
Letzteres ist dagegen auch mein Wunsch.

Ähnlich wie es jetzt schon mit dem dvdswitch-Plugin möglich ist, würde ich mir im VDR eine Aufnahme-Übersicht wünschen, die alle abspielbaren Medien anzeigt (ggf. mit einstellbarem Filter). Wenn ich dann einen Titel auswähle, wird der abgespielt - völlig egal, ob es ein Bild, nur Audio oder Video ist. Dies Abspielen sollte auch im Client-/Server-Betrieb funktionieren, sodass ich auf dem VDR z.B. auch mkv-Dateien lagern kann und die auf einem Client abspielen kann, der keinen Plattenzugriff zum VDR hat...
... oder ich steck ne SDCard von der Digicam in den VDR und möchte die Bilder anschauen.
Wie auch immer - für mich steht an erster Prio, dass es auch im Client-/Server-Betrieb und damit auch in allen anderen ZImmern funzt.
Bislang ist xineliboutput-Plugin der einzige Client, der so tut, wie ich es erwarte (auch wenn noch viele Wünsche offen sind).

Wenn softHDDevice den xineliboutput-Client ablösen könnte, hätte ich sicher nichts dagegen
Dazu darf es aber keine komplette vdr-installation am client erfordern. Nur ein binary, evtl. noch eine config-Datei, die bei nichtvorhandensein automatisch erzeugt wird - mehr sollte am Client nicht nötig sein.

Gruß Gero

Copperhead · 12. April 2012

Zitat von mini73

Oder dem vdr andere Container beibringen.

Etwas ähnliches hatte Udo Richter schonmal in der Mailinglist angesprochen.

Zitat von geronimo

Wenn softHDDevice den xineliboutput-Client ablösen könnte, hätte ich sicher nichts dagegen
Dazu darf es aber keine komplette vdr-installation am client erfordern. Nur ein binary, evtl. noch eine config-Datei, die bei nichtvorhandensein automatisch erzeugt wird - mehr sollte am Client nicht nötig sein.

Hoffentlich wird genau das nie passieren. Für diesen Zweck wurde streamdev erfunden.

geronimo · 13. April 2012

moin moin,

Zitat

Hoffentlich wird genau das nie passieren. Für diesen Zweck wurde streamdev erfunden.

Siehste und da sind wir schon wieder diametraler Ansicht
Für mich heißt die Frage nicht: ent oder weder, sondern sowohl alsauch.

Nach meinem Verständnis gibt es in einer Multi-Client-Umgebung eine VDR-Zentrale mit den TV-Karten, die aufnimmt und streamt.
Daneben gibt es beliebige Clients, die entweder VDR-Systeme oder "normale" Rechner sein können (also keine VDR-Systeme).

Streamdev mag schön und gut sein, solange es um 2 reine VDR-Systeme geht. In dieser Konstellation funktioniert es wohl auch schon mit softHDdevice.
Aber für mich zählt mein Desktop auch zu einem potentiellen Client und dort einen VDR zu installieren halte ich für ausgemachten Schwachsinn! Gleiches gilt für Netbooks, die temporär im Netz unterwegs sind. Auf jedem einen VDR installieren zu müssen, nur um einen Streaming-Client zu haben, das kann niemandes Ernst sein.
Insofern hoffe ich, dass irgendwann mal der xineliboutput-Client weiter entwickelt wird, oder ein besserer Nachfolger seinen Platz einnimmt.

Gruß Gero

Copperhead · 13. April 2012

Zitat von geronimo

Aber für mich zählt mein Desktop auch zu einem potentiellen Client und dort einen VDR zu installieren halte ich für ausgemachten Schwachsinn!

Natürlich ist das Schwachsinn. Du weißt aber schon, dass du streamdev-Streams auch mit jedem x-beliebigen anderen Player anzeigen kannst, oder?

Falls nicht, installiere dir mal temporär streamdev und rufe auf deinem Desktop folgenden Link in deinem Browser auf http://IPdesVDR:3000.

M-Reimer · 13. April 2012

Stimme Copperhead hier uneingeschränkt zu. Um mal eben einen beliebigen Rechner zu connecten halte ich das Xineliboutput-Plugin für weniger geeignet. Schon weil es ja eigentlich eine "Verlängerung" der VDR-Ausgabe ist. Man steuert also mit seinen Eingaben direkt den eigentlichen VDR. Wenn da gerade ein anderes Familienmitglied davor sitzt, ist das wohl eher nicht so gewollt.

Optimal als Ergänzung zu streamdev ist das live Plugin. Das kann in halbwegs aktueller Version sogar Aufnahmen streamen ohne das man dafür einen anderen Daemon (Samba oder wasweißich) benötigt. Vorteil der live/streamdev-Lösung: Man ist als Client eigenständig. Der eigentliche VDR kann also von jemand anders uneingeschränkt verwendet werden. Und, vom passenden Player-Plugin im Browser abgesehen, benötigt man auf dem Client auch keine spezielle Software.

seahawk1986 · 13. April 2012

Zitat von geronimo

Insofern hoffe ich, dass irgendwann mal der xineliboutput-Client weiter entwickelt wird, oder ein besserer Nachfolger seinen Platz einnimmt.

Für mich kommt genau da XBMC ins Spiel Es läuft auf allen gängigen Betriebssystemen und ist die IMHO noch am besten (Groß)elternkompatible Rundumlösung, die lediglich voraussetzt, dass man seinen Server sauber betreibt (und die VDR-Aufnahmen immer brav scheidet) und die Clients einmalig sinnvoll einrichtet...

TesaFilm · 13. April 2012

Obwohl mir die Diskussion hier zu sehr von der eigentlichen Frage abdriftet, geb ich da trotzdem meinen Senf zu.
Ich möchte ungern auf XBMC verzichten und brauche den ganzen Schnickschnack wie DVD-Wiedergabe im VDR nicht. VDR soll live-TV und Aufnahmen machen, mehr nicht. Auch brauch ich keinen VDR-Klient im XBMC, weil mir da bei SD das Bild im Vergleich zu SHD zu schlecht ist. Ich finde es halt schön durch meine Medien zu browsen und dazu die Beschreibungen und Cover zu haben. Jeder halt, wie er mag.
Für mich ist xinelibout seit einige Zeit nur noch nervig zu benutzen wegen immer wieder auftretenden merkwürdigkeiten, wie Artefakte nach ca. ner Minute und die schon notorischen tonaussetzer. Insofern bin ich absolut Happy das es SHD gibt. Kann ja sein das es ein auf meine Wohnung bezogenes Problem ist...

Was ich im SHD etwas vermisse aber auch als 'nice to have' sehe: verkleinertes TV-Bild im YAEPGHD, was bei xinelib 1a funktioniert.

CafeDelMar · 13. April 2012

Ich verstehe die Diskussion um streamdev vs. SHDD-Client nicht so ganz.
Streamdev ist wunderbar um Live-TV an andere vollwertige VDR-Clients oder auch an einen Desktop (z.B. mit VLC) zu bringen, eine Kontrolle des VDRs oder Anschauen von Aufnahmen ist hierüber nicht möglich.
Wenn zur Zeit niemand anderes den Server nutzt, ist ein Xineliboutput-Client (bzw. ein theoretischer SHDD-Client) doch eine tolle Möglichkeit _alles_ auf einfache Weise auf einem Desktop zu haben ohne Umwege über Netzwerkfreigaben und Web-Oberflächen.
Zudem ist es eine gute Möglichkeit sich das Bild einschließlich OSD eines ansonsten Headless-Server heranzuholen.
Hier schließt sich doch nichts aus und nichts ist besser oder schlechter?

CafeDelMar

geronimo · 13. April 2012

Zitat

Du weißt aber schon, dass du streamdev-Streams auch mit jedem x-beliebigen anderen Player anzeigen kannst

Nö wußte ich nicht.

Als ich meine Client-/Server-Umgebung aufgesetzt habe (ist schon ein paar Tage her), hatte ich einiges ausprobiert, was im Wicky so beschrieben ist. Abgesehen davon, dass streamdev bei mir nur Abstürze produzierte, war xineliboutput letztlich das Einzige, was so tat, wie ich es erwartet hatte.

Das zeigt mal wieder: Unwissenheit ist die größte Dummheit

Zitat

Um mal eben einen beliebigen Rechner zu connecten halte ich das Xineliboutput-Plugin für weniger geeignet. Schon weil es ja eigentlich eine "Verlängerung" der VDR-Ausgabe ist.

Aber das ist doch genau das, was ich von einem Client erwarte.
Mit dem Client will ich mal eben die Timer kontrollieren und wenn mir danach ist, auch eine Aufnahme, oder die Nachrichten anschauen, ohne mich aufs Sofa zu legen

Zitat

Optimal als Ergänzung zu streamdev ist das live Plugin.

Ok, ich seh schon - muss mal wieder eine Experimentier-Runde einlegen

Zitat

Für mich kommt genau da XBMC ins Spiel

Huch??? - Xbmc als Client auf dem Desktop?
In 1000 kalten Wintern nicht!

Mein Media-Center für nicht VDR-Medien heißt Krusader + xine
Leider zu dem Preis, dass ich entfernte Verzeichnisse per nfs einbinden muss - aber das ist halbwegs akzeptabel.

Zitat

Wenn zur Zeit niemand anderes den Server nutzt, ist ein Xineliboutput-Client (bzw. ein theoretischer SHDD-Client) doch eine tolle Möglichkeit _alles_ auf einfache Weise auf einem Desktop zu haben ohne Umwege über Netzwerkfreigaben und Web-Oberflächen.
Zudem ist es eine gute Möglichkeit sich das Bild einschließlich OSD eines ansonsten Headless-Server heranzuholen.

Hier schließt sich doch nichts aus und nichts ist besser oder schlechter?

Danke! - scheinbar bin ich doch nicht allein mit meiner Ansicht

Gruß Gero

M-Reimer · 13. April 2012

Zitat von CafeDelMar

Ich verstehe die Diskussion um streamdev vs. SHDD-Client nicht so ganz.
Streamdev ist wunderbar um Live-TV an andere vollwertige VDR-Clients oder auch an einen Desktop (z.B. mit VLC) zu bringen, eine Kontrolle des VDRs oder Anschauen von Aufnahmen ist hierüber nicht möglich.

Mit dem Live-Plugin sehr wohl und einen Browser hat wohl wirklich jeder heutige PC. Auch Aufnahmen können über das Live-Plugin gestreamt werden.

Zitat

Zudem ist es eine gute Möglichkeit sich das Bild einschließlich OSD eines ansonsten Headless-Server heranzuholen.

http://vdr-wiki.de/wiki/index.php/Remoteosd-plugin

Wer xineliboutput mag, inklusive dessen Netzwerkschicht zwischen VDR und Ausgabe, der kann dieses ja auch in Zukunft verwenden. Softhddevice ist ein VDR-Ausgabeplugin. Nicht mehr und nicht weniger. Und ich hoffe das bleibt auch so.

Gerade beim Einsatzfall "Server kontrollieren" erschließt sich mir nicht, warum es dort dann Softhddevice braucht, wenn für den gewünschten Zweck doch Xineliboutput wunderbar tut? Ist doch dann ein klarer Fall von "gibt's schon" oder "Das Rad muss kein zweites Mal erfunden werden".

geronimo · 13. April 2012

Zitat

Softhddevice ist ein VDR-Ausgabeplugin. Nicht mehr und nicht weniger. Und ich hoffe das bleibt auch so.

Hm, das ist ein Standpunkt, mit dem ich mich anfreunden könnte.

Bleibt für mich nur die Frage, was müsste man tun, um die Netzwerkschicht des xineliboutput-Client mit dem softHDdevice als Ausgabe zu verheiraten.

Wie wäre der Aufwand für ein solches Unterfangen einzuschätzen?
Wieviel VDR-Code müsste extrahiert werden, um das softHDdevice zum Laufen zu bekommen?
Hätte jemand daran Interesse?
Sollen wir dafür einen neuen Fred aufmachen?

Auf meinem Desktop gibt es scheinbar mehrere Anwendungen, die die vdpau-Einstellungen verstellen. Machmal läuft xineliboutput mit vdpau richtig flüssig und dann habe ich wieder eine Diashow, bzw. aktuell nur noch einen Absturz.
Das bedeutet, dass mein größter Wunsch eine geführte Konfiguration der vdpau-Parameter erlaubt, bei der die Werte nicht nur technisch, sondern auch semantisch überprüft werden.
Will sagen, dass es einen Hinweis gibt, wenn man unsinnige Einstellungen hat, die zum Absturz führen können.

Gruß Gero

M-Reimer · 13. April 2012

Zitat von CafeDelMar

Remote-OSD war bei mir leider immer krückig und kaum brauchbar.

Ist aber von der Idee her eigentlich genial. Sollte also ggf. mal überarbeitet werden.

Zitat

Warum so krass fordernd, dass SHDD so bleiben soll? Ist doch nur ein Feature, was Du nicht verwenden musst.

Weil SHDD (so sehe ich das) letztlich eben für jede gedacht ist, die einfach nur mit dem VDR auf Grafikkarte ausgeben wollen. IMHO ist gerade das direkte Ausgeben mit ein Grund, warum die Umschaltzeiten mit SHDD so schnell sind. Es gibt bereits Lösungen mit getrenntem Frontend. Macht es da wirklich Sinn noch eine solche Lösung zu schaffen? Gibt es schon und ggf. sollten die Interessenten an einer solchen Lösung lieber an der Weiterentwicklung von existierenden Lösungen mitwirken.

Genau genommen gibt es deren mindestens zwei und gerade auf dem Desktop ist das Xine-Plugin möglicherweise sogar noch besser.

Irgendwie kommt mir hier unfreiwillig der hier in den Sinn:
http://www.tim-bormann.de/linux-ist-nicht-windows/

Zitat

Motorräder <=> Autos: Beides sind Fahrzeuge, die Sie über Straßen von A nach B bringen. Aber sie haben unterschiedliche Formen, unterschiedliche Größen, besitzen andere Steuerelemente und sie funktionieren auf völlig verschiedene Weisen. Man kann sie nicht beliebig austauschen. Sie haben andere uses und unterschiedliche Stärken&Schwächen. Sie sollten das zweckmäßigere wählen und nicht einfach irgendeines und von ihm erwarten, dass es alles machen kann, was das andere könnte.

Auch wenn es nicht direkt passt, ist die Situation ähnlich. Die Front "getrenntes Frontend" fordert, dass das Tool "direkte Ausgabe" doch bitte ein getrenntes Frontend haben soll.

Copperhead · 13. April 2012

Zitat von geronimo

Bleibt für mich nur die Frage, was müsste man tun, um die Netzwerkschicht des xineliboutput-Client mit dem softHDdevice als Ausgabe zu verheiraten.
Wie wäre der Aufwand für ein solches Unterfangen einzuschätzen?
Wieviel VDR-Code müsste extrahiert werden, um das softHDdevice zum Laufen zu bekommen?
Hätte jemand daran Interesse?
Sollen wir dafür einen neuen Fred aufmachen?

Damit könnte ich mich anfreunden.

fnu · 13. April 2012

Zitat von geronimo

Bleibt für mich nur die Frage, was müsste man tun, um die Netzwerkschicht des xineliboutput-Client mit dem softHDdevice als Ausgabe zu verheiraten.

Aber das gibt es doch schon, vdr-plugin-xine @ xine-ui ... ?

Ich finde es reicht aus das es xineliboutput & xine mit den abgetrennten Frontends gibt. Ein "integriertes" Ausgabe-Plugin wie es SoftHDDevice darstellt gab es für HD bisher nicht, umso mehr freue ich mich über die exzellente Umsetzung und SoftHDDevice sollte nicht das Schicksal der anderen beiden Ausgaben erleiden.

Obwohl das Umschalten mit einer der letzen GIT Versionen wieder "schlechter" wurde und ich auf einmal wieder einen leicht asynchronen Ton habe, alles Sachen die schon längst geklärt waren, habe ich für die geforderten Lösungen/Erweiterungen teilweise noch nichtmal ein Problem ... weiß auch nicht ob man auf jedes Einzelschicksal eingehen muß ...

Aber das Thema Medienplayer scheint ja ein brisantes zu sein, entweder einen einbauen oder das mplayer-Plugin so aufhübschen, das es damit aus einem Guß läuft.

Regards
fnu

geronimo · 13. April 2012

Zitat von fnu

Aber das gibt es doch schon, vdr-plugin-xine @ xine-ui ... ?

Nicht wirklich.

Der Desktop ist für mich ne Arbeitsmaschine, die laufen muss. Zeit die ich in OS-Pflege stecken muss, ist unproduktive Zeit und somit lästig und teuer.
Deshalb gibt es für mich nur debian stable und einen vdr-client zu haben ist von den Desktop-Prios eher nice2have.

Xine selbst zu übersetzen um die aktuelle xinelib zu verwenden verletzt zuviel von debian stable - ist also kein gangbarer Weg (für mich).
Mit dem was es bei debian stable gibt, ist xine nicht als vdr-client verwendbar. Das was für xineliboutput übersetzt werden muss ist überschaubar und kann auf einer /usr/local Partition isoliert und jederzeit wieder deaktiviert werden. Der Rest des Systems ist also unbeeinflusst davon.
Deshalb schrieb ich ja, xineliboutput ist die einzige Variante, die in meiner Situation meine Erwartungen erfüllen kann.

Was ich dagegen als völlig daneben empfinde ist, dass xineliboutput Frontend-Einstellungen im VDR ablegen will. Das mag sinnvoll erscheinen, wenn Backend und Frontend auf der gleichen Maschine laufen, aber bei unterschiedlichen Maschinen ist das völlig Gaga. Man stelle sich vor, ich hätte einen Client mit vdpau und einen anderen mit ATI-Hardware
Man kann für xineliboutput-Client zwar eine lokale Text-Datei erstellen, aus der Werte für die Ausgabe-Einstellungen gelesen werden - leider werden die aktiven Werte nicht über die Datei bestimmt, sondern vom VDR-Backend überschrieben - ich habe noch nicht rausgefunden, wer noch alles bei den Einstellungen mit rumfingert ...
Somit ist keine Konfiguration unterschiedlicher Ausgabe-Devices für unterschiedliche Clients möglich.

In dem Kontext finde ich es auch verkehrt, die Anpassung von 4:3 auf 16:9 oder umgekehrt in den VDR zu packen.
In diesem Fall rede ich vom VDR als dem Unterbau, der nicht das Ausgabedevice ist.
Die Zoom-Anpassung sollte für jedes Ausgabedevice unterschiedlich abgelegt werden können - ist also eine Client-Einstellung.
Nur wenn Backend und Ausgabedevice auf der gleichen Maschine laufen sollte die Einstellung auf der VDR-Maschine abgelegt werden. Aber selbst dann bleibt es immer noch eine Ausgabe-Einstellung (Client-Einstellung).

Was mir beim xineliboutput-Client am meisten fehlt, ist die Möglichkeit, das Ausgabe-Device zu konfigurieren. Und zwar für warmduschende Mausschubser per GUI und nicht per Texteditor. Dann sollten natürlich für gut befundene Werte lokal ab gelegt werden, sodass sie beim nächsten Start wieder genauso geladen werden können.
Eine Beeinflussung durch das Backend sollte völlig ausgeschlossen werden können.

Deshalb habe ich Interesse an einem "neuen" / erweiterten Client. Wenn ich es richtig mitgelesen habe, kann softHDdevice die vdpau-Einstellungen ohne fremde Einflüsse vornehmen. Noch ein Grund, Interesse an softHDdevice auch als Client-Ausgabe-Device zu haben
Da softHDdevice allgemein den größten Zuspruch erhält, wäre es natürlich interessant, das Ausgabe-Device mit einem konfigurierbaren Client zu verheiraten.
Ich hätte durchaus Lust und Laune, mich an so einem Client zu beteiligen, aber die Konfiguration eines VDPau-Devices bekomme ich ohne Johns nicht gebacken.

Zitat

... weiß auch nicht ob man auf jedes Einzelschicksal eingehen muß

Kein Thema!
Wenn ich mit meiner Ansicht alleine bin, werde ich auch alleine eine Lösung dafür finden.
Hätte ja sein können, dass ich nicht alleine bin ...

Zitat

Aber das Thema Medienplayer scheint ja ein brisantes zu sein, entweder einen einbauen oder das mplayer-Plugin so aufhübschen, das es damit aus einem Guß läuft

Hier würde es mich freuen, wenn der Medienplayer so gestaltet würde, dass es eine Backend-Funktionalität ist.
Das Ausgabedevice gibt aus, was es als stream bekommt. Woher der Stream kommt, sollte das Ausgabedevice nicht interessieren.
Deshalb schrieb ich ja, dass ich mir eine Aufnahmeliste ala dvdswitch wünsche, bei der alle spielbaren Medien aufgeführt werden.

Gruß Gero

steffen_b · 13. April 2012

Naja Medienplayer ist hier eh falsch in diesem Thread. Wenn man irgendwie das OSD zum mitmachen überredet werden kann wenn man sowas wie mplayer verwendet ist es toll. Wenn man die Fähigkeiten des SHD verwenden kann um das wie eine Aufnahme abzuspielen wäre das auch cool. Bei letzterem würde ich hoffen das da jemand bei geht - das wäre eine gute Ergänzung. Ein mediaplayer ala sxfe sucks.

johns · 13. April 2012

Die Funktionen die ich ins Plugin eingebaut habe, waren ursprünglich für einen TV-Klient gedacht.

Zitat von geronimo

Bleibt für mich nur die Frage, was müsste man tun, um die Netzwerkschicht des xineliboutput-Client mit dem softHDdevice als Ausgabe zu verheiraten.

Wie wäre der Aufwand für ein solches Unterfangen einzuschätzen?

Das will man nicht. VDR parsed den TV-Stream. Das xineliboutput Plugin parsed den TV-Stream noch einmal und baut daraus wiederum Video Packete, die werden dann per Socket (Netzwerk) an den Klient geschickt, dieser parsed wiederum die Packete.
Irgendwie wird hier alles doppelt bzw. dreifach gemacht. Ein einfacheres Interface wäre hier besser.
Ich weiß nicht ob xvdr (von XBMC) hier eine bessere Figur, der Vorgänger war einfacher und hat dadurch auch schneller umgeschaltet.
Was sehr schnell ist, ist das streamdev Protokoll, Bisher ist mir eine leichte Verzögerung von einem Audio-Packet, was ca 100ms entspricht aufgefallen. Bei xvdr + streamdev fehlt aber der Zugriff auf das OSD.

Zitat

Wieviel VDR-Code müsste extrahiert werden, um das softHDdevice zum Laufen zu bekommen?

Eigentlich nichts. Bzw. das hat ja das xineliboutput Plugin schon gemacht. Man müsste das Protokoll den Empfang aus dem Klient kopieren.

Zitat

Hätte jemand daran Interesse?

Sollen wir dafür einen neuen Fred aufmachen?

Auf meinem Desktop gibt es scheinbar mehrere Anwendungen, die die vdpau-Einstellungen verstellen. Machmal läuft xineliboutput mit vdpau richtig flüssig und dann habe ich wieder eine Diashow, bzw. aktuell nur noch einen Absturz.
Das bedeutet, dass mein größter Wunsch eine geführte Konfiguration der vdpau-Parameter erlaubt, bei der die Werte nicht nur technisch, sondern auch semantisch überprüft werden.
Will sagen, dass es einen Hinweis gibt, wenn man unsinnige Einstellungen hat, die zum Absturz führen können.

Der Adobe Flashplayer killt hier den kompletten Rechner regelmässig. Ansonsten wüsste ich nichts was VDPAU durcheinander bringen könnte.
Du hast nicht zufällig eine GT 520 und den Effekt auf Servus TV HD?
Das Einzige was durch falsche Einstellung passieren kann, ist das die Darstellung zulangsam wird und dann tüchtig Frames gedroppt werden.
Deshalb würde ich dies noch gern in die Anzeige oder OSD bekommen.

Johns

mini73 · 14. April 2012

Moin!

Soweit ich weiß, hat Klaus angekündigt, zumindest mal über Client/Server nachzudenken.
Bis jetzt ist es nämlich so, dass der vdr nur ein OSD zur Zeit darstellen kann. Deshalb ist es momentan eigentlich nicht vernünftig möglich, ein lokales OSD darzustellen, das vom Server gefüttert wird. Das geht nur mit einem eigenen Programm, das sich irgendwie die Infos für ein OSD vom Server holt (restfulapi usw.).
Das ist dann aber nicht das OSD (inkl. Skins usw.) vom Server.

Ich hoffe, ich konnte mich verständlich ausdrücken...

Lars.

geronimo · 14. April 2012

Zitat

Soweit ich weiß, hat Klaus angekündigt, zumindest mal über Client/Server nachzudenken.

Hm, so wie ich das verstanden habe, steht das Thema bereits auf der Todo-Liste für nach 2.0
In der ML bat er, die Diskussionen über das was nach 2.0 ist zurück zu stellen.
Weiß jetzt nicht, ob das "nur" für die ML galt, oder ob er generell nicht drüber reden will ...

Zitat

Bis jetzt ist es nämlich so, dass der vdr nur ein OSD zur Zeit darstellen kann. Deshalb ist es momentan eigentlich nicht vernünftig möglich, ein lokales OSD darzustellen, das vom Server gefüttert wird.

Dann konnte ich mich wohl nicht richtig ausdrücken.

Ich hätte gerne, dass das Ausgabe-Device ein OSD darstellen kann, egal woher es kommt.
Im 1-Maschinen-Betrieb könnte das OSD vom vdr alleine kommen, im richtigen Client-/Server-Betrieb würde es vom Client-Unterbau kommen und nicht vom vdr gespeist werden. In dieser Betriebsart gäbe es dann 2 OSDs, eines vom vdr und eines lokal. Schließlich sind die Einstellungen des Ausgabedevices für mich auch lokale Daten.
Wenn man(n) den Client-Unterbau neu machen würde, könnte man sicher auch zwischen vdr-OSD und lokalem OSD unterscheiden.

Ich weiß nicht, wie das derzeitige OSD gerendert wird.
Rendert das der VDR bereits in den Videostream rein, oder bekommt das Ausgabe-Device die OSD-Daten auf einem separaten Kanal?
Wenn man vdr und Ausgabedevice auf 2 unterschiedlichen Rechnern betreibt, braucht man dann neben der Netzwerkverbindung für die Streamdaten noch eine separate Verbindung für das OSD?
Falls dem so wäre, ließe sich ein lokales OSD sicher mit restful-Daten mischen und als eines darstellen. Wäre sicher machbar, dass die lokale Konfiguration nur ein Menüpunkt im OSD des VDR ist, sodass das OSD trotzdem aus einem Guss erscheint.

Gruß Gero

Keine_Ahnung · 14. April 2012

Hm, gibts doch schon, XBMC oder Vompclient Lokales OSD, Mediaplayer... da gehts dann doch hin.

Zitat von geronimo

im richtigen Client-/Server-Betrieb würde es vom Client-Unterbau kommen und nicht vom vdr gespeist werden. In dieser Betriebsart gäbe es dann 2 OSDs, eines vom vdr und eines lokal.

Wie willst du an das VDR OSD rankommen? Geht doch nicht.

Wie sollten erst mal definieren was Client/Server meint. Meint es
a) Einen Server die mehrere Clients bedient
b) Einen VDR der in der Mitte durchgeschnitten und per Netzwerk verbunden wird (D.h. nur ein Client (zur Zeit) zum headless Serverpart).

cu

Client/Server Diskussion aus dem SoftHDDevice Thread

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema