Umfrage: Patches, die direkt in den VDR aufgenommen werden sollten

Sorry, aber diese Umfrage halte ich für überflüssig, denn jeder Patch ist wichtig wenn er für ein Feature oder Plugin das ich verwenden will notwendig ist.

Es währe meiner Meinung nach viel wichtiger die ganzen Patche irgendwo mal zentral zu verwalten, bzw. mal genau zu beschreiben, für was denn nun genau jeder einzelne Patch gut ist - und vor allem für welche VDR Version er gemacht ist.

Evtl. währe es ja möglich eine Site in PHP zu bauen, wo man sich sein individuelles Patchset selbst zusammenstellen kann......

BTW:
Kaus hat ja schon an anderer Stelle hier im Forum geschrieben, dass er nur das aufnimmt, was er für notwendig hält und er selbst auch getestet hat.

Wenn Klaus in der ML mit liest, dann weiß er auch von der Umfrage.

Da es nun angelaufen ist, warten wir doch einfach mal ab ...

Scheinbar wird aber von einigen nicht verstanden des es sich um Patches Handelt um die dies Umfrage geht.
Denn in der Liste tauchen einige Plugins auf welche definitiv keine Patches benötigen.

Hier mal ein paar Statements von Klaus:

http://linuxtv.org/pipermail/vdr/2009-January/019185.html

"Public roadmaps and TODO lists are for those who want to live with
stress, caused by people's expectations and disappointment when a new
version doesn't contain all the features listed on the roadmap.
VDR is my hobby - I don't need stress there ;-)"

Interpretation: "Mir doch egal was Ihr wollt"

http://vdr-portal.de/board/thr…?postid=794417#post786459

"Ganz einfach: an der Zeit!
Bevor ich sowas übernehme muß ich mich erstmal selber genau damit auseinandersetzen.
Und momentan setze ich mich halt mit TS-Recording, HDTV und dergleichen auseinander
Was danach kommt, kann ich noch nicht sagen. Aber ich schau' mir halt bevorzugt solche Dinge an, die mir auch selber wichtig sind..."

Man beachte vor allem den letzten Satz!

http://linuxtv.org/pipermail/vdr/2009-February/019652.html

"I know that concurrent SVDRP sessions are "wished" and that there
are several things to consider when implementing them. However,
as you stated correctly, this has low priority to me. Currently
I'm working on making VDR fully HD capable, so any patches that
might be posted for other things would either take time off the
HD topic, or just be ignored altogether right now..."

Auch hier der letzte Satz - für mich höchst motivierend einen Patch für den VDR zu schreiben, damit dieser dann vor sich hinstaubt oder jahrelang nebenher gepflegt werden muss..

Generell muss mir mal jemand erklären warum VDR scheinbar das einzige mir bekannte OpenSource-Projekt ist das so ziemlich niemand ohne externe Patches verwendet die VDR erst überhaupt bequem und sinnvoll verwendbar machen (Stichworte: epgsearch, extrecmenu).

Auf der anderen Seite Danke ich allen Plugin-Entwicklern, die nicht die gleiche Einstellung an den Tag legen und nur das hineinprogrammieren was sie selber wollen, sondern offen für Erweiterungen und Anregungen anderer sind.

Und wenn man sich zeitlich mit etwas überhoben hat sollte man IMHO überlegen ob ein Aufspalten der Entwicklungstätigkeit nicht sinnvoller wäre.

Gruß

Joe_D

Dann mach doch selbst einen VDR-fork wenn du so unzufieden bist!

Ich kann auch ohne Patches gut leben! epgsearch braucht keinen Pach... mann kann mit Pach nur den VDR-EPG Eintrag durch den von epgsearch ersetzen!

73

Zitat

Originally posted by Joe_D
"Public roadmaps and TODO lists are for those who want to live with
stress, caused by people's expectations and disappointment when a new
version doesn't contain all the features listed on the roadmap.
VDR is my hobby - I don't need stress there ;-)"

Interpretation: "Mir doch egal was Ihr wollt"

Sowas aber auch, Klaus ist doch tatsächlich nicht bereit, seine gesamte Freizeit zu opfern, damit jeder sein Wunschfeature kriegt. Schlimm, schlimm...

Klaus macht halt die Sachen in der Reihenfolge, wie er sie für richtig hält, und in dem Tempo, das er bereit ist, zu investieren. Da es sein Projekt, sein Hobby ist, ist das auch ok so. Ist ja nicht so, dass die Community Klaus dafür bezahlen würde, dass er VDR weiter entwickelt, dann könnte die Community auch Forderungen stellen.

Zitat

"Aber ich schau' mir halt bevorzugt solche Dinge an, die mir auch selber wichtig sind..."

Man beachte vor allem den letzten Satz!

Und? Ist er ein Programmier-Sklave, der sich nach unseren Wünschen zu richten hat?

Zitat

"Currently I'm working on making VDR fully HD capable, so any patches that
might be posted for other things would either take time off the
HD topic, or just be ignored altogether right now..."

Auch hier der letzte Satz - für mich höchst motivierend einen Patch für den VDR zu schreiben, damit dieser dann vor sich hinstaubt oder jahrelang nebenher gepflegt werden muss..

Klaus will zu erst HD fertig entwickeln - etwas, das er auf Druck der Community überhaupt erst begonnen hat - und sich danach erst mit anderen Erweiterungswünschen beschäftigen. Dir wäre es demnach lieber, er würde alles gleichzeitig anfangen und nichts zu Ende bringen?

Außerdem: Die Motivation, einen Patch zu schreiben, sollte wohl eher der Wunsch nach einer Verbesserung sein. Für mich war die hinzu gewonnene Funktion jedenfalls immer wichtiger, als die Frage, ob der Patch schnell oder erst später oder überhaupt in VDR integriert wird.

Insgesamt bin ich für eine sehr vorsichtige Integration von Patches in VDR. Der gründliche Review der Patches durch Klaus vor der Aufnahme sichert letztlich die Qualität von VDR. Und nicht jede neue Idee erweist sich letztlich als der goldene Wurf, für den sie ursprünglich mal gehalten wurde. So mancher Patch ist auch wieder in Vergessenheit geraten, oder durch bessere Lösungen ersetzt worden. Ist so etwas erst mal Teil des VDR, wird man es nicht mehr los.
Beispiel: Unterstützung für mehrere /video-Verzeichnisse. Die vorhandene Lösung hat reichlich Schwächen und hätte so heute kaum eine Chance, nochmal akzeptiert zu werden. Als separater Patch wäre sie wohl schon längst durch bessere Lösungen verdrängt worden.

Es muss auch nicht jede Funktion, die irgend wer brauchen kann, in VDR fest integriert werden. Das führt letztlich nur zu einem Feature-überladenen Monster. Ein Beispiel für so eine Fehlentwicklung ist meiner Meinung nach epgsearch: Ich nutze wohl nicht mal 10% der Funktionen von epgsearch. (Übrigens auch nicht den VDR Patch von epgsearch.)
Ohne gedrucktes Handbuch neben der Fernbedienung (die englische Doku bringt es auf ca. 60 Seiten) würde ich die meisten wohl auch gar nicht finden. Der Quelltext von epgsearch ist mit 41K-Zeilen fast so groß, wie der von VDR (aktuell 48K-Zeilen). Ich möchte epgsearch nicht mehr missen, aber eine einfache Version, die automatisch Timer nach Stichworten anlegt, und manuelles Suchen erlaubt, würde mir auch reichen. ( winni: Tut mir leid, dass ich so direkt sein muss, ist nicht als Kritik gemeint.)

Mein VDR hat übrigens aktuell 11 Patches drin, davon sind gerade mal 6 öffentlich verfügbar, und 3 haben es in die obige Liste geschafft. So viel zur absoluten Notwendigkeit all dieser Patches, und dazu, dass jeder Patch für jeden nötig ist.

Gruß,

Udo

oe6jwf

Zitat

Dann mach doch selbst einen VDR-fork wenn du so unzufieden bist!

Das habe ich quasi schon. Bei mir läuft ein VDR basierend auf den Paketen von E-Tobi, wegen manch' fehlendem Feature und dem Verwenden von CVS-Versionen mancher Plugins habe ich vor einiger Zeit umgestellt auf eine komplett selbst kompilierte Version.

Urig

Zitat

Klaus ist doch tatsächlich nicht bereit, seine gesamte Freizeit zu opfern

Und? Ich auch nicht und trotzdem gehe ich bei meinem Plugin auf Wünsche anderer ein die ich z.B. selber gar nicht brauche. Alles eine Frage der Einstellung und des Zeitmanagements. Klar kann man das vom Umfang nicht mit dem VDR vergleichen, aber ich habe mein Plugin z.B. gleich von Anfang an zu einem Community-Projekt gemacht. Wenn es mir zuviel wird können andere Teile beisteuern oder auch das Plugin weiterführen (wenn ich z.B. Gedenke bei VDR1.6.x zu bleiben).

Zitat

Ist ja nicht so, dass die Community Klaus dafür bezahlen würde, dass er VDR weiter entwickelt

Und? Ich werde doch für das was ich programmiere auch nicht bezahlt.

Zitat

Und? Ist er ein Programmier-Sklave, der sich nach unseren Wünschen zu richten hat?

Wäre es, wenn es anders wäre so schlimm? Ist meine Einstellung (oder z.B. die von winni) auf andere einzugehen nun schlechter?

Zitat

Es muss auch nicht jede Funktion, die irgend wer brauchen kann, in VDR fest integriert werden

Das stimmt, es wäre aber eben mal anzudenken wie man generell solche Probleme lösen kann: Die Plugin-Idee ist doch schonmal eine gute Sache, nur greift diese IMHO zu kurz. Warum gibt es z.B. nur eine Ein-/Ausgabegeräte-Klasse (ja ich weiss das Klaus mit einer FF-Karte angefangen hat)? Warum gibt es keine getrennten Eingabe- und Ausgabegeräte-Klassen. Seit Erscheinen von Softdevices und IPTV/WebTV und sonstigen Ein- und Ausgabemöglichkeiten wäre dies eine Erleichterung für die Entwickler. Wenn ich da an mein eigenes infosatepg-Plugin denke wie bescheuert das Handling von Devices bei einem Budget-Only-System ist. Da existieren 2 vollwertige Devices wovon keines ein Vollwertiges ist (Xineliboutput/Budgetkarte). Das eine ist eben nur Output und das andere eben nur Input und es ist noch nichtmal softwaremäßig erkennbar um was es sich handelt (man kann es nur vermuten, die Basisklasse ist nicht darauf ausgelegt). Ebenso stiefmütterlich ist das EPG-Handling. Das Faktum, das SenderEPG zumeist nur Müll ist und das viele Benutzer Ihr eigenes EPG aus verschiedenen Quellen holen kann man doch nicht Ignorieren. Doch bis heute gibt es keine Funktionalität das SenderEPG abzuschalten (ausser diesem üblen NoEPG-Patch).

Ich wollte nur aufzeigen das es eben grundlegende Dinge gibt, die generell zu einer Verbesserung der Erweiterbarkeit des VDR beitragen würden und die auch die Entwicklungslast von Klaus schmälern könnten. Aber dazu müsste das Grundgerüst Differenzierter (Geräte/EPG/OSD/Dateiablage) und die Plugin-Struktur mächtiger sein.

Gruß

Joe_D

So eine offizielle Abkoppelung vom offiziellen vdr wäre nicht schlecht. Klaus macht sein eigenes Ding, eine unterschiederliche Anzahl an Entwicklern arbeiten an einem Vdr-fork. Sollte Klaus ein neues Release bringen, versucht man die Änderungen in den fork zu mergen, damit es mindestens dasselbe kann. Wenn der Fork alle Unzulänglichkeiten, die zb Joe_d genannt hat, des alten Systems beseitigt hat, darf Klaus nach eingehendem Test entscheiden ob er den Fork als sein vdr weiterführt.

was heisst da darf?

ich als entwickler würde das ganze als ideenpool ansehen von dem ich sachen übernehmen oder abkupfern würde.. je nachdem wie mir eine änderung gefällt...

73

Zitat

Original von Joe_D
Die Plugin-Idee ist doch schonmal eine gute Sache, nur greift diese IMHO zu kurz. Warum gibt es z.B. nur eine Ein-/Ausgabegeräte-Klasse (ja ich weiss das Klaus mit einer FF-Karte angefangen hat)? Warum gibt es keine getrennten Eingabe- und Ausgabegeräte-Klassen. Seit Erscheinen von Softdevices und IPTV/WebTV und sonstigen Ein- und Ausgabemöglichkeiten wäre dies eine Erleichterung für die Entwickler.

In der Mailingliste stand, dass kls das Ausgabe device evt. in ein Plugin auslagern will.

mfg Thomas

Genauso eingeschränkt sind für devices nicht nur die Plugin Schnittstelle, auch leider die channels.conf und die source types.

Und die mehrfach angefragte Integration eines der fertigen Patches (die nicht einmal Nebenwirkungen haben!) wird wohl niemals erfolgen. Womit jeder der so ein Plugin nutzen möchte den VDR selbst patchen MUSS. Damit ist die Plugin-Schnittstelle nicht sehr viel wert.

Ich zumindest habe die Hoffnung aufgegeben, dass sich daran jemals etwas ändern wird.

Dann könnten sich ja vielleicht ein paar Pluginentwickler (die sollten ja wissen was nötig ist) zusammensetzen und eine verbesserte Pluginschnittstelle entwerfen und als Patch implementieren.
Somit wären durch diesen einen (größeren) Patch viele der Pluginspezifischen kleineren nicht mehr nötig und einige Plugins vielleicht erst möglich.

Also ähnlich dem MainMenuHook wo man sich ja auch auf eine einheitliche Schnittstelle geeinigt hat - nur umfassender/grundlegender.

Monroe

Monroe

Zitat

...eine verbesserte Pluginschnittstelle entwerfen und als Patch implementieren.

Der wie all die anderen Patches ewig und drei Tage mitgezogen werden muss weil anderes wichtiger ist und es deshalb nicht in die Sourcen schafft?

Es geht auch nicht so sehr um die Pluginschnittstelle. Die ist schon ganz ok. Es geht um "CORE-Features". Also z.B. im Bereich OSD, EPG, Dateiablage. Das müsste alles viel flexibler sein. Was natürlich erstmal zu einem Bruch führt, ähnlich wie die Einführung von gettext.

Im EPG-Bereich könnte ich mir z.B. vorstellen die Plugin-Schnittstelle so zu erweitern das der EIT-Filter aus dem Core rausfliegt in ein Plugin das dann eben vdr-plugin-dvbepg heisst. Ebenso das OSD. Einfach komplett mit text2skin machen. Das erhöht zwar den ersten Installationsaufwand - aber später ist dann alles komfortabel anpassbar. (Ich suche heute noch nach einer Möglichkeit wie ich dem STTNG-Skin Bilderanzeige beibringe - wohl nur dadurch STTNG per Hand in text2skin zu wandeln?)

Ideen gäbe es viele. Und auch viele viele Hände die dazutun würden die Lösungen umzusetzen (inklusive mir). Aber siehe meine Zitate in meinem Beitrag weiter oben... So muss ich es leider wie wirbel halten

Gruß

Joe_D

Zitat

Original von oe6jwf
Dann mach doch selbst einen VDR-fork wenn du so unzufieden bist!

Das ist doch das Schöne an OS! Wenns dir nicht passt, machs selbst...

Läuft doch aktuell gerade so, diese ganze Patch Geschichte ist ja quasi ein VDR-fork.
Und jeder der was implementieren will baut seinen eigenen. Und ein (oder mehere fleissige) basteln die ganzen forks wieder in einen zusammenn und es gibt den ext-Patch (bin immer noch dabei rauszufinden was die ganzen Patches da drin eigendlich tun ).

Wobei die Plugins eigendlich auch keine richtigen Plugins sind (nach meinen Verständnis), nur um es einwenig komplezierter zu machen

Plugins sollten eigendlich über ne definierte Schnittstelle auf das Hauptprogramm zugreifen. Aber irgendwie braucht man ja für jede neue VDR Version erstmal die ganzen Plugin Patches die man hier im Forum zusammensuchen muß.
Das kenne ich aus meiner Windows Heimat auch anderst. Da ist ein Plugin ne DLL die man irgendwo hinkopiert und das läuft.
Und solange sich die Schnittstellen nicht ändern (oder alle vom Plugin benötigten Dinge in der Hauptprogrammschnittstelle drin sind) läuft da jede Pluginversion mit jeder Hauptprogrammversion.
Fände ich auch beim VDR sehr viel sinnvoller, gerade da viele Plugins nicht mehr gepflegt werden.

Kenne mich da mit Linux nicht wirklich aus. Aber gibts da nicht auch sowas wie DLLs?

cu

Die Anzahl der nur mit patch laufenden plugins ist imho ziemlich klein!

dlls gibts schon.. so-files sind sowas... und genau das sind die plugins auch... so wie's sein soll...

Und das was du da beschreibts ist beim VDR auch so...

Das die Plugin-Schnittstelle nicht das non-plus-ultra ist habe ich schon öfter gelesen...nur ist mir persönlich lieber, dass der VDR-core weiter in dieser qualität entwickelt wird als das da jetzt auf einmal an einer ganz anderen baustelle gepfuscht wird...

ein fork sind die patches auf jeden fall nicht... Das was die reelbox leute gemacht haben, das ist ein fork! und es steht jedem frei auch sowas aufzuziehen wenn ihm etwas nicht passt...

73

Warten wir doch einfach mal das Ergebnis dieser Umfrage ab. Wenn ich dann die HD-Sachen fertig habe, schaue ich mir mal die ganzen extrem wichtigen Patches an, ohne die VDR nicht verwendbar ist

Vielleicht gelingt es mir dann ja endlich mal, mit VDR zuverlässig aufzunehmen und wiederzugeben...

Klaus