2.0 erreicht - wie geht es jetzt weiter?

Zitat von gda

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.

Klingt interessant ich seh nur nicht warum ich für diese Funktionalität auf dem nas einen VDR benötige wenn es nur um Aufnahmenverzeichnisse, -symlinks und deren Metadaten geht?

Find ich aber generell gut den Ansatz, prinzipiell würde es aber auch ein in avahi eigebettetes nfs tun wie ich es hier ohne vdr betreibe

Christian

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.

Alles anzeigen

Moin!

avahi wird sicherlich auch eine wichtige Komponente dabei sein, deshalb hab ich ja avahi4vdr geschrieben.
Da gibt es bloß noch ein paar Unstimmigkeiten im Zusammenspiel mit dbus2vdr. Beide Plugins benutzen eine Verbindung zum System-DBus-Daemon. Da scheint manchmal noch einiges schief zu gehen, muss ich noch untersuchen.

Lars.

Hach ist das hier jetzt der Thread in dem jeder mal seine Wünsche raushaut?

Ich hätte gerne:

Erststart-Dialoge (mit Sendersuchlauf und Satellit und DiseqC-Einstellung übers OSD)
Bouquet-Unterstützung (eventuell channels.conf automatisch alphabetisch sortieren und dann für jedes Bouquet eine weitere Liste mit diesen S19.2E-..-..- eindeutigen IDs)
Menüsortierung (Endlich Setup, MenuOrg und auch Mainmenuhooks los werden)
Verschieben und Umbenennen von Aufnahmen

Das dürfte dann auch so ziemlich alles sein, was sich an der Bedienung der nächsten VDR Version ändern sollte.

kls: Wenn du Interesse hast würde ich für den Erstartdialog mal einen Mockup machen. Schön übersichtlich mit Vergleichen zu anderen Systemen.

Irgendwie finde ich es auch ein wenig schäbig jetzt schon wieder Forderungen zu stellen. Wir sollten Klaus erstmal ein wenig in Ruhe lassen...
Auch wenn ich sehe, was hier für übertriebene Forderungen auftauchen, bin ich froh, dass Klaus da noch etwas selektiert.

Zitat von TheChief

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.

KLS hatte mal gemeint eine Möglichkeit einzubauen mehrere Skins zu benutzen. Dann könnte man Graphtft als eigenes Skin inplementieren. Das würde dann auch das Geschwindigkeits Problem über die Service Schnittstelle lösen. Wird Graphtft eigentlich noch gepflegt? Würde mir wünschen, dass das was angezeigt wird konfigurierbar ist also z.B. nur die Sender Info. Weil mehr brauche ich nicht und das OSD wird nicht ausgebremst.

Zitat von DLX

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.

Alles anzeigen

Abgesehen vom deaktivieren der Ausgabe macht der VDR das eh schon alles.
Bei druck auf Power wird die User inactivity auf null gesetzt d.h. der VDR weiß dass niemand vor der Glotze sitzt und schaltet aus wenn möglich (keine Aufnahmen, letzter Client disconnected)

Zitat von geronimo

Wie auch immer - ich halte das für keinen Widerspruch zum dem was ich schrieb. Wenn man den jetzigen VDR aufteilt in einzelne lauffähige Komponenten könnte das Aufnahme-Modul trotzdem ein Resourcen-Sharing betreiben, bzw. noch besser: es konnte in ein Resourcensharing eingebunden werden. Ähnlich wie die Konfiguration von div. Clients würde ich die Verwaltung der Resourcen auch von einem separaten Dienst steuern lassen.
In meinem beruflichen Umfeld hat es sich bewährt, lauffähige Komponenten mit kleinem Fokus zu erstellen. So ist das Gesamtsystem beliebig skalierbar. Dienste können mehrfach aufgesetzt werden, nur mit leicht unterschiedlichem Fokus. Das Prinzip übersetzt in den VDR-Kontext würde heißen, es gäbe einen Aufnahmedienst, der von einem Transponder aufnehmen kann. Bei einer Maschine startet der Timer-Manager den Aufnahmedienst für jede Aufnahme.
Wer jetzt das System skalieren will, könnte (im anderen Extrem) für jeden Transponder einen separaten Aufnahmedienst starten (hier können mehrere Maschinen ihre Dienste im Netz anmelden). Der Timer-Manager triggert dann nur noch die Aufnahmedienste der entsprechenden Transponder.

In meinem beruflichen Umfeld hat sich eine zentrale Datenbank als Triggerbasis bewährt (ich habe das Prinzip auch bei VdrAssistant so umgesetzt). So können Dienste als Automaten laufen und die Synchronisation der Prozesse erfolgt über Statusfelder in den Datenbanktabellen. Zusätzlich lassen sich einzelne Prozesse auch auf unterschiedliche Rechner verteilen.
Eine Aufnahme über mehrere Prozesse und Rechner könnte so ablaufen:

• epgsearch erstellt einen Timer
• der Aufnahmedienst für den Transponder des Timers ändert zum Aktivierungszeitpunkt den Status des Timers und erstellt ein Aufnahmeobjekt mit Status "in Arbeit". Daneben wird die Aufnahme auf Platte gespült. Wenn der Aufnahmedienst fertig hat, wird der Status von Timer und Aufnahmeobjekt weiter geschrieben
• ein Werbungssuchdienst könnte sich die erste fertige Aufnahme krallen (Status weiterschreiben) und nach Werbeblöcken suchen. Nach Erstellung der Schnittmarken wird der Status der Aufnahme fortgeschrieben.
• ein Serien-Verwaltungsdienst könnte die Aufnahme nach einer passenden Namensregel umbenennen, nach zusätzlichen Informationen bei den netten Indern anfragen, etc.
• ein Archivierungsdienst könnte jetzt die Aufnahme auf einen anderen Rechner verschieben ... (natürlich auch wieder unter Veränderung des Status)

Diese Dienste könnten alle auf einer Maschine laufen oder alle auf unterschiedlichen Maschinen. Natürlich könnten manche Dienste auch mehrfach gestartet werden, um parallele Arbeiten zu verrichten. Jeder Dienst sieht nur die Objekte mit seinem Eingangsstatus.

Da bin ich aber froh dass kls der Entwickler ist.

Zitat von DLX

Abgesehen vom deaktivieren der Ausgabe macht der VDR das eh schon alles.

Da hat der VDR je nix mit zu tun. softdevice deaktivert die Ausgabe so wie man es erwartet. Und softhddevice könnte man das detachen AFAIK auch leicht beibringen.

Im Prinzip macht der VDR das schon richtig, der User meldet sich mit dem Druck auf "power" ab und das wars für den User. Der VDR weis dann schon wann er den PC ausschalten muss und wann nicht.
Das einzige was aktuell nicht klappt ist das der User sich mit "power" wieder anmeldet. Das ist aktuell etwas inkonsequent. Ist der PC aus muss man "power" drücken, ist er an dann "back". Wobei der User den PC Status (an oder aus) im Zweifel gar nicht erkennt.

cu

Zitat von Keine_Ahnung

Das einzige was aktuell nicht klappt ist das der User sich mit "power" wieder anmeldet. Das ist aktuell etwas inkonsequent. Ist der PC aus muss man "power" drücken, ist er an dann "back". Wobei der User den PC Status (an oder aus) im Zweifel gar nicht erkennt.

Das ist ein Fehler auf der Fernbedienung.
Die von meinem AV-Receiver hat einen Aus- und einen Ein-Knopf...

"Toggle"-Knöpfe sind immer doof, weil man nicht genau sagen kann, was passiert. Das Ergebnis ist immer von irgendeinem externen Zustand abhängig.

Lars.

Zitat von Copperhead

kls: Wenn du Interesse hast würde ich für den Erstartdialog mal einen Mockup machen. Schön übersichtlich mit Vergleichen zu anderen Systemen.

Das kannst du gerne machen, aber ich verspreche nichts ;-).

Zitat

Irgendwie finde ich es auch ein wenig schäbig jetzt schon wieder Forderungen zu stellen. Wir sollten Klaus erstmal ein wenig in Ruhe lassen...

Ich hatte eigentlich auch gehofft, erstmal ein bisschen zur Ruhe kommen zu können und mir in Ruhe zu überlegen, womit ich mich als nächstes beschäftigen möchte...

Zitat

Auch wenn ich sehe, was hier für übertriebene Forderungen auftauchen, bin ich froh, dass Klaus da noch etwas selektiert.

Ich hab' nur so am Rande mitgelesen und werde mich hier auch weitgehend raushalten. Aber manches ist schon wirklich abenteuerlich

Klaus

Zitat von kls

Ich hatte eigentlich auch gehofft, erstmal ein bisschen zur Ruhe kommen zu können und mir in Ruhe zu überlegen, womit ich mich als nächstes beschäftigen möchte...

Eben, den ein oder anderen Grat an 2.0.0 abfeilen und den Sommer geniessen, jetzt müssen erstmal das Gros der Plugins auf 2.0.0 stable-Level gleichziehen.

Würden da mal nur alle so effizient arbeiten wie der gute rofafor, er ist Deiner Idee mit den Plugin-Versionen gefolgt ...

Zitat

Verschieben und Umbenennen von Aufnahmen

Es wundert mich dass ich dies hier desoefteren lese, das geht doch bereits via extrecmenu Plugin.
Wozu sollte man Core Features einbauen, sofern es auch via Plugin geht ?

Zitat von gda

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.

Da hat es mal eine geniale Idee zu gegeben, alle Aufnahmen ins INet zu announcen und somit ein MEGA Filmarchiv aufzubauen. Will man einen Film sehen lädt man sich den von irgendeinem Client übers Netz. Erfordert aber eine mächtige Datenbankanbindung, die passende Verwaltung und selbstverständlich nur legale freetv Aufzeichnungen. Das wäre doch ein vdr 10.0 wert. Damit wäre uns der ultimative Hass der Film und Fernsehinsdustrie sicher

Funktionen gibt es immer welche die mehr oder weniger wichtig sind und fehlen. Was ist essentiell und was gehört sich als Plugin? Alleine das schon ist eine unlösbare Frage. Was aber sicherlich Sinn macht, Pluginschnittstellen zu erweitern und patches noch weiter zu reduzieren. Da fällt mir auf Anhieb die FB Baustelle ein (starre Tastenbelegungen und die integration ansich) oder der verachtete "Livebuffer" (den Klaus aber irgendwan in 2.x mal in kleiner Form ermöglichen wollte, ich musste es doch noch mal schreiben )

Interessant fände ich es, wenn Klaus eine Art Feature / To Do Liste hätte die man sehen dürfte. Das würde mache immer wieder von vorne beginnende Diskussion erübrigen.

Aber erstmal sei Dir eine ordentliche Portion Urlaub vergönnt

Zitat von geronimo

Jetzt gibt es endlich ne tolle Forums-SW mit funktionierender Ignorierliste und Klaus hat Adminrechte - was fehlt noch um eine geordnete Diskussion zustande zu bringen?

WO ???

Falls du hier meinst, hier hat er in diesem Bereich Modrechte und keine Adminrechte.

Irgendwie verstehe ich den Thread auch nicht wirklich!

1. Klaus ist der Entwickler von VDR und somit sollte so ein Thread von ihm kommen (wenn er das will)
2. birgt er einfach nur die Gefahr, das gute und schlechte Ideen durcheinander gewürfelt werden und am ende einiges auf der Strecke bleibt.

Ich denke das es auch für Klaus wesentlich einfacherer ist, wenn "Feature-Requests" in seperaten Threads gestartet werden und er diese Themenbezogen beantworten kann.
So kann er Anhand der aktivität im Thread auch leichter erkennen, ob und wie sehr ein Feature gefragt ist.

Copperhead
Diesen Vorschlag hatte Klaus schon! Wenn er das möchte, wird es kommen.

Zitat von Torsten73

Aber erstmal sei Dir eine ordentliche Portion Urlaub vergönnt

FULL ACK

Zitat von CKone

Klingt interessant ich seh nur nicht warum ich für diese Funktionalität auf dem nas einen VDR benötige wenn es nur um Aufnahmenverzeichnisse, -symlinks und deren Metadaten geht?

Komisch wie du das aus dem was ich geschrieben habe heraus liest. Nicht eine dieser Funktionalitäten über die ich geschrieben habe benötigt einen VDR. Außerdem habe ich einen NAS überhaupt nicht im Fokus. Dafür braucht doch nichts getan werden. Es geht mir eben um VDRs die im Gegensatz zu einem NAS nicht ständig an sind.

Für Anwender mit nur einem VDR, oder einem VDR und einem NAS ändert sich gar nichts, aber für Anwender mit mehr als einem VDR stehen dann alle Resourcen aller VDRs automatisch zur Verfügung ohne eine Zeile in einer Konfigurations-Datei, oder einem Klick in unserem Web-Frontend. Aber ich sehe schon, es war ein Fehler darüber zu schreiben.

Gerald

Zitat von geronimo

Ich denke, die Zahl der Anwender mit echtem C/S Bedarf dürfte deutlich höher sein. Kann aber sein, dass ich da falsch liege.

Das würde mein Vorschlag ja automatisch mit abdecken. Ein Client ist für mich ein VDR mit Softhddevice und dem Streamdev-Client-Plugin. Ein anderer VDR mit der "Rescource" Streamdev-Server-Plugin wird geweckt und liefert das Bild, oder eben die Aufnahmen.
Der einzige "Konfigurations-Schritt" der nötig wäre ist, beide VDRs müssten mal zeitgleich an sein.

Zitat von geronimo

Hm, das ist eine überaus interessante Idee, allerdings sehe ich deren Einsatz eher bei handverlesenen Powerusern.
Weiß nicht wieviele Anwender mehrere VDRs parallel mit Aufnahme-Devices betreiben.

Na ja, es ist ja kein Geheimnis, dass mir das was die Masse will nicht sonderlich wichtig ist. Die meisten Anforderungen die der gewöhnliche VDR-User hat, sind entweder banal, deshalb langweilig und keine Herausforderung, oder extrem Aufwendig mit nicht nachvollziehbarem Nutzen.
Außerdem habe ich schon einen Job bei dem ich das programmiere was andere wollen. Der reicht mir. Nichts für ungut :D.

Gerald

Bei allen Feature und Änderungswünschen darf auch nicht vergessen werden, dass der VDR Core ein Hobby One Man Project ist. Warum sollte man Funktionen integrieren, die sich mit Plugins genausogut lösen lassen und wofür es Leute gibt, die sich bereits darum kümmern?

Desto mehr Aufwand bleibt bei Klaus hängen und das halte ich für unfair. Das kann einer alleine irgendwann gar nicht mehr schaffen, solange es keine Community Entwicklung ist.

Und da dies noch hoffentlich lange Zeit außer Frage steht, finde ich es gut wie es ist. ich denke da nur ungerne an Neutrino zurück und was daraus geworden ist. Da haben viele gute Leute das Handtuch geworfen, weil in der Gemeinschaft oft es noch schwerer ist zu einem gemeinsamen Nenner zu kommen.

Zitat von gda

Das würde mein Vorschlag ja automatisch mit abdecken. Ein Client ist für mich ein VDR mit Softhddevice und dem Streamdev-Client-Plugin. Ein anderer VDR mit der "Rescource" Streamdev-Server-Plugin wird geweckt und liefert das Bild, oder eben die Aufnahmen.
Der einzige "Konfigurations-Schritt" der nötig wäre ist, beide VDRs müssten mal zeitgleich an sein.

Das ist zu unzuverlässig, es hat sich über die Jahre bewährt dass eine Instanz im Netz die Oberhoheit hat. Das kann ein richtiger Server sein, eine "fette" Maschine, die soviel wie möglich der benötigten Hardware selbst hat - muss es aber nicht. Die Aufsicht über die im Netz zur Verfügung stehenden Ressourcen kann ebenso etwas wie RaspberryPi ausführen, aber eine Instanz sollte Chef sein.

Deshalb gefällt mir das Grundkonzept von LinuxMCE erstmal gut, die Unterteilung in:
LinuxMCE Core Computer
LinuxMCE Media Director Computers
LinuxMCE Orbiters (Fancy remotes)

Zitat von Torsten73

Bei allen Feature und Änderungswünschen darf auch nicht vergessen werden, dass der VDR Core ein Hobby One Man Project ist. Warum sollte man Funktionen integrieren, die sich mit Plugins genausogut lösen lassen und wofür es Leute gibt, die sich bereits darum kümmern?

FullACK.

Albert