2.0 erreicht - wie geht es jetzt weiter?

VDR endlich richtig netzwerkfähig machen, so dass er von sich aus eine Multimediaclient-Server Umgebung wird. So richtig mit zentraler Verwaltung der Ressourcen wie DVB-Empfänger, Timer, Aufnahmen auf verschiedenen Rechnern... zentral an allen Fernsehern nutzbar.

Es wird vmtl. nie eine öffentliche Diskussion über Features geben, das ist doch gleich ein Shitstorm ...

Aber ich bringe nochmal was in Erinnerung was ich vor über einem Jahr auf der Mailingliste geschrieben habe, tatsächlich einigen Anklang fand und eine Antwort auf ziemlich krude Vorstellungen einiger Entwickler war:

Zitat

Hi there,

following the discussion regarding Client/Server the last couple of day, I'm honestly horrified.

What I did realize where super complex ideas, hacks, bottomline a solution from developers for developers. I got the imagination some want to keep out normal users, inventing VDR to death, because only a few users are able to handle it.

Since Apple pretty much come with a TV solution this year, expectations of users will change in terms of GUI & usability. And not only Apple, even Ubuntu does invent in the same direction on their UbuntuTV.

There's no need to copy these solutions, but the need to be prepared to these fast changing expectations. We should think about the details of VDR, a good and stable solution, which I love to use since over 10 years now.

I don't have any issues to run a complete VDR on Client and Server, the binary is small, so what.

My dream of a Client/Server VDR solution is:

- 1+n VDRs do find themselfs seemless w/o user interaction within a network
- 1+n VDRs do elect/define a principle, which become the leader of the pack, preferably that one with (the most) DVB devices
- The principle becomes the central point of VDR operation
- Timers set on whether Client/Server VDR, is handled by the principle centrally
- Recordings are also handled centrally on the principle, the clients do have seemless access to it
- It doesn't matter if the clients do have their own disks
- But if needed principle can use this addional disk space on clients and each client does also have seemless access
- DVB devices can be added and removed dynamically to each of the VDRs, but principle stay responsible for all DVB devices within network
- Plugins can be added/removed dynamically via OSD or a Web-Interface
- The VDR pack or rather the principle can be controlled/programmed by a cloud service from all over the world.
- Setting up one of these VDRs may only be possible for experienced user, but es soon as they're up and running, you're little children could handle them.

Just my vision for a smart client/server VDR solution.

Cheers
fnu

Alles anzeigen

Gut von Apple gibt es bis heute kein TV-Gerät, aber die Bedienung der kleinen schwarzen Boxen ist trotzdem Baby-einfach (3 Tasten + Steuerkreuz) und das Konzept von UbuntuTV ist auch nicht ohne.

Regards
fnu

Hey Geronimo,

setzt du nun VDR ein oder nicht. In deinem andern Post von heute 6:30 erklärst du noch lang und breit wie du deine daten von einem VDR zum nächsten trägst per "Floppy-Weitwurf" und hier willst dus nicht mehr gewesen sein. Hab ich da ein Jahrhundert verpennt?

Nix für ungut
msv

Zitat von fnu

Es wird vmtl. nie eine öffentliche Diskussion über Features geben, das ist doch gleich ein Shitstorm ...

Also, wenn ich mich recht erinnere, gab es zur 1.7 auch eine Diskussion, ob da lieber HD oder ich-weiß-nicht-mehr-was gemacht werden sollte.
Jetzt ist sicherlich ich-weiß-nicht-mehr-was dran und Klaus hat ganz sicher auch seine eigenen Vorstellungen.
Aber, ich denke mal, es spricht nichts dagegen, wenn wir, die User, mal ein wenig unsere Vorstellungen und Wünsche diskutieren. Das kann zu neuen Ideen führen.

Ich jedenfalls sehe auch die Client/Server Trennung ganz vorn dabei.
Ich habe einen 24/7 Server auf dem auch ein VDR läuft. Dass es da keinen Client braucht, ist das geringste Problem. Aber ich habe auch etliche Rechner, die eigentlich nur einen Client benötigen. Die wollen die Aufnahmen wiedergeben und TV von den DVB-Karten im Server.
Bisher habe ich dafür eine Mischung aus VDR, XBMC und Videoplayern laufen. Ein VDR Client, der, wie fnu schon schreibt, seinen Server von allein findet und TV und Aufnahmen bereitstellt, wäre für mich, das was noch fehlt.

Faudeer

Hi,

wenn ich mich recht erinnere, dann war für VDR > 2.0 IPTV als große Änderung irgendwie in der Diskussion. Erinnere mich an irgendeinen Post von Klaus der diesen Schluß nahegelegt hatte. Aber ich kann dem was fnu oben geschrieben hat grundsätzlich anschließen. Nicht unwichtig ist auch zu sehen wie sich die Technikwelt bei den Home Usern während der 5 Jahre Entwicklung der 1.7 verändert hat. 2008 waren Smartphones und Tablets noch exotisch, die Cloud noch unbekannt und Remote Zugriff auf das Heimnetzwerk nur was für Nerds. Mit einer Fritzbox kann das heute jeder ambitionierte Anwender hinbekommen. Streaming, Client/Server, upnp und all die anderen Funktionen sind ja durchaus via Plugins da, aber nach wie vor nicht ganz trivial zu installieren.

Aus meiner Sicht wäre es sinnvoll, das der Core VDR für die Konfiguration und Bedienung eine einfache Weboberfläche hat in der die Basiskonfiguration auch zur Laufzeit geändert werden kann, das würde auch die von fnu angesprochenen Automatismen zum gegenseitigen auffinden anderer VDRs im Netz einfacher beherrschbar machen.

Wir werden sehen was Klaus für Vorstellungen hat und erstmal freue ich mich über die 2.0.

bye
Sven

Zitat von fnu

Aber ich bringe nochmal was in Erinnerung was ich vor über einem Jahr auf der Mailingliste geschrieben habe, tatsächlich einigen Anklang fand und eine Antwort auf ziemlich krude Vorstellungen einiger Entwickler war:

Im Prinzip fehlt nur eine gescheite Netzwerk Schnittstelle. Dann kannst du dies, was du willst. alles auslagern.
Entweder man macht eine neue. Zur Not nimmt man den D-BUS Schrott.
Oder man macht svdrp Mehrbenutzer fähig.

Damit kann man z.b. die WEB Oberfläche extrern auslagern.
EPG, Timer und Aufnahmen zentral verwalten, dies macht aber ein externes Programm.

Eigenständige Clients können dann auf diese Schnittstelle zugreifen.

Als Anmerkung einen reiner VDR Client ist nicht viel Arbeit, die Größte davon ist das OSD.

Johns

Erstmal könnten so generelle Dinge aufgenommen werden, die zum Besipiel der MainMenuHooks-Patch. Desweiteren könnte die API in soweit erweitert werden, dass beispielsweise der graphtft-Patch überflüssig wird. War da nicht auch mal was im Gespräch? Ansonsten wünsch ich mir noch das editieren und verschieben von Aufnahmen.

Zitat von johns

Oder man macht svdrp Mehrbenutzer fähig.

Und wenn man schon dabei ist, dann svdrp direkt einen eigenen Thread spendieren, der unabhängig vom Main-Thread laufen kann.

Wenns um Server/Client geht, würde ich mir noch ein wirklich durchdachtes "der letzte macht das Licht aus" Konzept wünschen.

Folgende Situation:
Wohnzimmer = Server und "Client", dient also auch aktiv zum Fernsehen
reiner Client im Schalfzimmer
+ je nach bedarf Notebooks / Desktoprechner / Tap für Toilette / Badewanne / Arbeitszimmer / Balkon

Der Client im SZ sendet ein Shutdown, wenn er aus gemacht wird, und wenn man glück hat, kommt im WZ auch im OSD eine Aufforderung eine Taste zu drücken, wenn man nicht will, dass der Rechner aus geht.

Soweit ich bisher drüber nach gedacht habe, sollte das eigentlich garnicht nötig sein.
Im Moment ist es ja so, dass der VDR einfach weiter läuft, wenn man auf der Fernbedienung aus "Aus" drückt und eine Aufnahme läuft. Im OSD steht, "wird später ausgeschaltet". Man könnte ja jetzt die Ausgabe deaktivieren. An der laufende/deaktivierten Ausgabe könnte man dann erkennen, ob noch jemand vor dem Fernseher sitzt und guckt, oder nicht. Je nachdem kann der "Server" dann in den Standby geschickt werden, wenn kein Client mehr an ist.
Beim starten des Server könnte man bei einem Timer die Ausgabe deaktiviert lassen, und bei einem starten durch die Fernbedienung die Ausgabe natürlich wieder aktivieren. schwierig wird es zu erkennen, ob der Server von einem Client, oder der Fernbedienung gestartet wurde.

Im Moment passiert es oft, dass der ausgehende SZ-Client das Fernsehen im WZ aus macht, obwohl noch einer davor sitzt, weil die OSD-Meldung aus bleibt.

Sind nur Ideen, aber vielleicht denkt einer der Entwickler das mal vollkommen durch. Würde für eine Server-Client-Lösung in meinen Augen dazu gehören. Nicht jeder hat einen Stand-Alone-Server im Keller, sondern nutzt den Wohnzimmer-HTPC als Server.

Das deaktiveren der Ausgabe hätte auch den Vorteil, dass man Strom spart, weil die Grafikkarte ja nix mehr machen muss.

War denn nicht auch mal über Bouquetverwaltung die Rede?

DLX

Die Probleme die du beschreibst kommen genau daher weil VDR nicht wirklich netzwerkfähig ist, sondern alles in der Richtung nur dran gebastelt wurde.

Client/Server bedeutet für diesen Zweck nicht automatisch dass irgendwo ein dicker Server mit vielen Festplatten und DVB-Karten stehen muss der 24 Stunden durchlaufen muss. Aber ein Rechner muss alles verwalten und den einzelnen Stationen zuteilen was der Benutzer gerade benötigt.

Wie wäre es mit einem neuen Prefix für das VDR-Core Unterforum?

[Feature Request]

Dann ist auch gleich die dazu passende Diskussion richtig einsortiert.

halbfertiger

Das ist mir schon klar. Ich wollte auch nicht motzen oder so. Sondern für die Server/Client-Entwicklung nur Denkanstöße liefern. Wenn keiner sagt, was ihm auffällt, dann weiß es auch kein Anderer, wenn er nicht grade das gleiche Szenario selber hat.

Und nur weil eine Trennung von Server und Client angestrebt wird, heißt dass ja nicht, das dieses Problem dann gelöst wird. Was passiert denn, wenn ich Server und Client auf einer Maschine habe und in der Oberfläche auf Sleep gehe? Wird nur der Clientdienst beendet? das würde zu einem 24/7-Server passen. In meinem Fall müsste der Dienst auch beendet werden, aber anschließend halt eine Routine, die schaut, ob der Server weiter laufen muss oder nicht.

Ich wollts halt erwähnt haben, damit es irgendeiner auf der Agenda hat. Ich würde mich die Platze ärgern, wenn der Umbau stattfindet und sowas (in meinen Augen) entscheidendes nicht 100%ig umgesetzt wird. Und hinterher kommt so eine Aussage:"Hätteste mal früher was gesagt..."

Zitat von DLX

Was passiert denn, wenn ich Server und Client auf einer Maschine habe und in der Oberfläche auf Sleep gehe? Wird nur der Clientdienst beendet? das würde zu einem 24/7-Server passen. In meinem Fall müsste der Dienst auch beendet werden, aber anschließend halt eine Routine, die schaut, ob der Server weiter laufen muss oder nicht.

Daher finde ich es am besten so etwas möglichst außerhalb des VDRs zu lösen. Das wird eigentlich immer eine Individuallösung werden... den VDR dafür zu erweitern ist bei der Inkonsistenz der Linux-Distributionen IMHO schwer möglich, sonst hätte ich mir schon längst Shutdown-Inhibits für systemd gewünscht, wenn sich dr VDR außer Stande sieht herunterzufahren weil der Nutzer aktiv ist, Timer laufen usw. ... aber das lässt sich ja alles mit Plugins und ein bisschen Skripterei lösen

Zitat von seahawk1986

den VDR dafür zu erweitern ist bei der Inkonsistenz der Linux-Distributionen IMHO schwer möglich,

Wenn der VDR die Funktion von sich aus mit bringt und anhand seiner eigenen Schnittstellen überwacht, sollte die Distri egal sein. Prozesse abfrage und was sonst noch außerhalb des VDR notwendig wäre, ist(sollte) in jeder Distri enthalten(sein).

Natürlich kann man das auch mit Scripten und Plugins lösen, aber wie oben beschrieben, exsistieren die jetztigen Probleme ja nur, weil es so gelöst ist

Neben bisher gesagtem: Menüverwaltung ala menuorg - stand auch mal auf der Liste.
Und was mir aktuelle aufgefallen ist: die Prüfung auf den nächsten freien Kanal von der Performance verbessern. Hier wartet man teilweise 10s+ bis "der VDR" sich wieder bewegt.

Meine Gedanken gehen da in eine völlig andere Rechnung. Vollkommen weg vom klassischen Client/Server. Bei mir sollen alle VDRs völlig gleich konfiguriert sein und keiner eine Sonderrolle übernehmen.

Alle VDRs stellen Ressourcen zur Verfügung. Das sind z.B.:
- Aufnahmekapazität, also freie Tuner zu einer bestimmten Zeit. (Clients ohne Tuner haben dann eben Null Kapazität)
- Timer
- Aufnahmen

Eine der Ideen ist jetzt, dass die VDRs ihre Resourcen austauschen und die Timer optimal verteilen. Hat der VDR auf dem der Timer erstellt wurde einen Timer-Konflikt, dann kann er den Timer einem anderen VDR übergeben, den er bei Bedarf auch wecken kann.

Aktuell bastele ich gerade an einer anderen Baustelle. Verteilte Aufnahmen. Dazu werden die Meta-Informationen der Aufnahmen zwischen den VDRs verteilt. Meta-Informationen sind, neben den Titeln der Aufnahme, die Info-Datei und symlinks zu den .ts-Dateien.
Diese Aufnahmen tauchen dann gleichberechtigt mit den lokalen Aufnahmen, im Aufnahme Menü auf.

Wird eine dieser Aufnahmen ausgewählt, dann wird per AutoFS versucht, das NFS-Laufwerk mit den .ts-Dateien zu mounten. Sollte dieser VDR mit den Aufnahmen ausgeschaltet sein, dann wird er per WOL geweckt.
Nachdem die Wiedergabe der Aufnahme beendet wurde wird nach einem kurzen Timeout ein unmount gemacht und der VDR kann sich wieder schlafen legen. Mini73 hat bereits code erstellt, der automatisch ermittelt welche VDRs sich wie wecken lassen.

Der Austausch der Meta-Informationen erfolgt beim Boot eines VDRs, oder nach Beenden einer Aufnahme, mit allen gerade aktiven VDRs, außerdem ist es noch möglich, dass sich alle VDRs mal kurz in der Nacht synchen.

Etwas Code dafür existiert schon, mal sehen ob das praktikabel ist.

Generell bin ich der Meinung, dass der VDR nicht Netzwerk-fähig sein muss. Es reicht, wenn für alle Resourcen Schnittstellen zur Verfügung stehen. Die Krönung wäre allerdings ein DBUS-Interface.

Gerald

Zitat von fnu

Es wird vmtl. nie eine öffentliche Diskussion über Features geben, das ist doch gleich ein Shitstorm ...

Zitat von Faudeer

Also, wenn ich mich recht erinnere, gab es zur 1.7 auch eine Diskussion, ob da lieber HD oder ich-weiß-nicht-mehr-was gemacht werden sollte.

Zitat von geronimo

Hm, also das kann ich nicht nachvollziehen.

Oha, muß man jetzt auch noch Smiley gekennzeichnete Ironie erklären, oder was? Wobei ich mich damit nur auf entsprechende Formulierungen von Klaus bezog ...

Was ich aber ernst meinte sind die "kruden komplexen Entwickler Vorstellung", die hier leider schon wieder bei einigen durchlinsen. Es hat sich noch nie jemand beschwert wenn was einfach und schlicht ist ...

Regards
fnu