Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

  • Ich würde auf einen Tippfehler bei der URL der englischen Anleitung tippen. In der deutschen Version stimmt es: https://github.com/VDR4Arch/vd…DE)#installation-vdr4arch

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit VDR4Arch geht es klar weiter. An den Binärpaketen hänge ich alleine und das Wetter ist in letzter Zeit auch zu gut, um da viel am PC zu verbringen.


    Der Fokus hat sich minimal verschoben. Direkte Ausgabe des VDRs ist von den beiden Hauptentwicklern nicht mehr getestet. Wenn Probleme aufkommen, wird klar versucht diese zu lösen, aber testen muss jemand anderes.
    VDR-Entwicklerversionen bekommen keinen wirklichen Support mehr. Klaus hat da zuviel mit den Plugins kaputt gemacht, da blicke ich nicht mehr durch und viel zu viele der Plugins sind nur über Community-Patches am Leben gehalten.


    Binärpakete wird es nur noch für x86_64 geben. Das hängt mit der Entscheidung von Arch Linux zusammen, dass i686 nicht mehr unterstützt wird. Ich selbst werden das kompilieren schon vor dem offiziellen Aus einstellen.
    Binärpakete für ARM kommen von mir ebenfalls keine mehr. Außer eine der ARM Architekturen wird von Arch Linux direkt unterstützt. Die Abspaltung Arch Linux ARM supporte ich nicht mehr, wegen persönlichen Differenzen mit dem Hauptentwickler.


    Zu deinen Fragen direkt:


    Wie seahawk1986 bereits geschrieben hat, hat sich der Pfad etwas verschoben. Das war im englischen Wiki nicht angepasst, ist es jetzt aber.
    Ebenso hat sich der Pfad des Repositories verschoben. Das ist aber beides schon vor über einem Jahr passiert.
    Und nein. die AUR Pakete sind noch weniger auf aktuellem Stand, als die Binärpakete. Wenn du wirklich schneller sein, willst als ich mit dem kompilieren der Pakete, dann solltest du die PKGBUILDs aus dem Git Repository nehmen.


    Ich hoffe das erklärt das meiste. Es geht weiter. Etwas langsamer, aber es geht weiter.

  • viel zu viele der Plugins sind nur über Community-Patches am Leben gehalten

    Das ist sicher kein Makel an den Plugins, da jeder GIT Commit nix anderes als ein Patch ist, oder? Und als ob die Community nur Mist liefern würde ...


    Regards
    fnu

    HowTo: APT pinning

  • Meiner Meinung nach ist das wesentliche Problem bei dem Thema eigentlich, dass es je nach Plugin schwierig geworden ist, noch zu wissen, wo es nun die nötigen Sources und/oder Patches zu finden gibt.


    Als Beispiel kann man da mal wieder softhddevice nennen. Es gibt, soweit ich mich erinnere, nun schon mindestens 3 separate Abspaltungen. Eine davon das "Original". Hier wäre es überfällig alles mal wieder zusammenzuführen. Am besten natürlich wieder auf das "offizielle" GIT auf projects.vdr-developer.org.


    Es ist mit viel Aufwand verbunden immer alles zusammenzufinden, was nötig ist, damit wieder alles nötige mit einer VDR-Entwicklerversion geht.


    Hier wäre es wirklich wünschenswert, wenn wir hier etwas "Zuarbeit" von Nutzern bekommen könnten, die noch VDR "Standalone" nutzen. Bei mir ist der VDR nurnoch "headless" im Einsatz. An Plugins nutze ich nurnoch Vnsiserver, Live, Epgsearch und Xineliboutput um vom Desktop aus schneiden zu können. Ich werde auch weiterhin PKGBUILDs anpassen, aber eben bevorzugt das, was ich selber nutze.

  • Jedem Commit hinterherrennen ist nicht Sinn der Sache.

    Nun, aber das sehe ich durchaus als essentielle Aufgabe eine Distro Maintainers ...


    Regards
    fnu

    HowTo: APT pinning

  • Als Beispiel kann man da mal wieder softhddevice nennen. Es gibt, soweit ich mich erinnere, nun schon mindestens 3 separate Abspaltungen. Eine davon das "Original". Hier wäre es überfällig alles mal wieder zusammenzuführen. Am besten natürlich wieder auf das "offizielle" GIT auf projects.vdr-developer.org.


    Da ich künftig wohl auch vermehrt softhddevice verwenden werde wäre ich da auch sehr dafür ;-).


    Klaus

  • Nun, Erstens hat rofafor zwei Abspaltungen zusammengeführt, pesintta & HEVC. Soweit ich weiß entsprechen sich pesintta und rofafor wieder, VDPAU Stand johns plus VPP/VAAPI.


    Zweitens hat Antti (pesintta) IIRC schon 2014 um die Übernahme der VPP/VAAPI Erweiterungen durch johns gebeten, das hängt bis heute in der Luft.


    Drittens, der OpenGL OSD Teil kann nicht in VPP/VAAPI (pesintta/rofafor) übernommen werden, weil der nur für VDPAU umgesetzt ist, müsste also nach VPP/VAAPI portiert werden.


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Nun, aber das sehe ich durchaus als essentielle Aufgabe eine Distro Maintainers ...


    Aus Maintainer Sicht muss ich sagen das ich wenig Lust habe längst aufgegebene Plugins am Leben zu erhalten durch zusammengeklaubte Patches.


    Leider haben viele keine Lust oder die Möglichkeit die Patches in die jeweilige Repo zu schieben (wenn es denn eine gibt) geschweige denn gibt es eine Zentrale Anlaufstelle wo man aktuelle Sourcen findet. Somit endet man mit einem Ökosystem was so langsam wegfault und nur noch durch dezentrale Patches hoffentlich funktioniert. Nächster Knackpunkt ist das es einem schwer gemacht wird überhaupt etwas beizutragen zu können. Die so hilfreichen drive by pull requests sind im VDR Land ja leider quasi nicht vorhanden, es hat schon einen Grund warum Github so beliebt ist. Dennoch VDR findet auf Github so gut wie nicht statt, das kann man nun mögen oder nicht - Fakt ist aber auch das man somit freiwillig auf die größte Ansammlung an Devs verzichtet und damit auch auf die einfach Möglichkeit das Fremde etwas beitragen können. Fast alle Defs die ich kenne haben schon keine Lust mehr wenn es über eine Mailingliste geht, der Aufwand ist da meist zu groß und man ist es doch lieber gleich sein.



    Im Vergleich mit den reinen VDR Distros sind wir noch in der glücklichen Lage nicht so viele Plugins (14) zu benötigen und VDR nur als headless server zu betreiben, sonst würde es wahrscheinlich bei uns nie mehr ein VDR Core update geben. Einzig durch die kürzliche Bewegung bei live und epgsearch kann ich ein Update überhaupt in Erwägung ziehen und selbst da muss ich schon den epgfixer entfernen weil es dafür nichts gibt.


    Wenn man bei VDR4Arch guckt sieht es recht aussichtslos aus das man alles übernehmen kann. Ich hab jetzt schon Kopfschmerzen wenn wir auf gcc 7 updaten was da alles kaputt geht und das bei den paar Plugins die wir haben.


    Mittlerweile bei ich der Einstellung was nicht mehr gepflegt wird fliegt raus (wenn es kaputt geht) - wenn das rauswerfen des Plugins nicht geht weil es dringend benötigt wird fällt damit jegliches Update des Gesamtpaketes aus.
    Das ist die einzig sinnvolle Lösung für uns auch wenn das bedeutet das es keine Updates mehr gibt.



    ps: ich laste diese Entwicklung keinen hier Persönlich an oder mache ihn "verantwortlich" - das ist lediglich eine Feststellung zur jetzigen Situation

  • Ich finde es auch besser, wenn es pro Plugin ein, besser zwei Personen gibt, die den Code im vollen Umfang verstehen und das Übernehmen der Patches koordinieren. Es tut keinem Programm gut, wenn es wild an vielen Stellen angepasst wird, nur damit es kompiliert. Da gehört noch einiges mehr dazu. Und weil ich bei epgsearch und live nicht weiterkam, hab ich ja epg2timer angefangen, weil das etwas ist, was ich warten kann und was das tut, was ich brauche. Und gerüchteweise soll ja auch ein webosd unterwegs sein, es kann also gut sein, dass es für live auch bald eine neue Alternative gibt. Und wenn nicht, werde ich sicherlich irgendwann eine kleine Alternative anfangen, die meinen Bedürfnissen genügt.


    Manchmal ist es besser, von vorne anzufangen.


    Lars

  • Na ja, man sollte schon erwarten können, dass ein maintainer nicht beim ersten winzigen Problem schulterzuckend aufgibt, wenn wegen einer neuen GCC Version ein Sourcecode nicht beim ersten Anlauf kompiliert.


    >> geschweige denn gibt es eine Zentrale Anlaufstelle wo man aktuelle Sourcen findet
    Dafür haben wir seit Jahren eine wiki, in der zu (fast..) allen Plugins und Tools rund um VDR Links zum Sourcecode, bekannten Bug, Patches und Installation/Benutzung enthält.
    Die ist eben ganz genau so aktuell wie die Community dazu beisteuert.


    Was git anbetrifft, ohne jemanden der das koordiniert, wird ein Stück Software dadurch kein Stück besser.

  • Dennoch VDR findet auf Github so gut wie nicht statt, das kann man nun mögen oder nicht - Fakt ist aber auch das man somit freiwillig auf die größte Ansammlung an Devs verzichtet und damit auch auf die einfach Möglichkeit das Fremde etwas beitragen können.


    Gibt es einen speziellen Grund dafür, warum wir vdr und die plugins nicht gesammelt auf github zentral organisieren? Ich meine damit Gründe, ausser dass sich jemand finden muss, der das macht? So ala team-vdr?
    https://github.com/vdr hat wohl 2011 irgendwer mal angelegt.


    Gruß Andreas

  • Dafür haben wir seit Jahren eine wiki, in der zu (fast..) allen Plugins und Tools rund um VDR Links zum Sourcecode, bekannten Bug, Patches und Installation/Benutzung enthält.


    Sorry, aber das Argument kann ich ganz und gar nicht so stehen lassen. Das Wiki ist überfrachtet mit veralteten und teilweise sogar falschen Informationen und jedesmal, wenn ich darauf hinweise, dass irgendwas gemäß Wiki nicht funktioniert, heisst's "vergiss' das Wiki, mach' X Y" (gilt übrigens nicht nur für VDR, sondern auch für das sehr umfangreiche EasyVDR-Wiki). Und weil sooo viele Plugins ständig wechselnde extra Patches und zum Teil zusätzliche Patches für den VDR-Core benötigen, ist es in der Tat eine Sysiphus-Arbeit, wenn man mal ein Update machen will (hab' ich grad hinter mir von 2.0.6 auf 2.2.0), daher werde ich wohl auch nicht an 2.3.x rangehen und auf 2.4 warten von dem was ich über API-Änderungen bei 2.3 mitbekommen habe. Und weil die Situation so ist wie sie ist, falle ich als Tester auch wieder raus...


    Grüße,
    j.

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

  • >> Das Wiki ist überfrachtet mit veralteten und teilweise sogar falschen Informationen


    Gib mal Beispiele.

  • Gibt es einen speziellen Grund dafür, warum wir vdr und die plugins nicht gesammelt auf github zentral organisieren?


    Dafür gibt es doch projects.vdr-developer.org. Da gibt es auch Wikis, Issues usw. Sicherlich kann man da nicht so einfach Merge/Pull Requests stellen, aber die müssen ja nicht immer per Weboberfläche zusammen geklickt werden. Das geht ja auch problemlos auf der Kommandozeile mit Repositories bei unterschiedlichen git-Hostern.


    Und ich würde meine Plugins sicherlich nicht unter einen Account stellen, wo verschiedenste Leute Zugriff haben. Über die offiziellen Sourcen meiner Plugins habe ich gerne die alleinige Kontrolle. Und das widerspricht sich nicht damit, dass ich natürlich gerne Patches von anderen Leuten bekomme.


    Lars.

  • Die Idee mit Github fände ich gut. VDR-Developer ist heute nicht mehr zeitgemäß. Alle Plugins (oder zumindest viele) in einer Github Organization transferierieren, bei älteren nötigenfalls auch ohne Zustimmung. Die Bedenken von mini73 verstehe ich schon, aber nur weil ein Repository unter einer bestimmten Organization gelistet ist, heißt das noch lange nicht, dass jeder auf das Repository pushen kann.


    Da gibt es Rechteverwaltung und es stehen eben ein paar wenige über den einzelnen Maintainern, die bei Bedarf (zum Beispiel bei Nichtreagieren auf ein Issue in einem festgelegten Zeitraum) eingreifen können und neue Contributor hinzufügen oder theoretisch Issues direkt bearbeiten könnten.


    VDR-Developer ist zu schwerfällig. Man ist heute einfach zu verwöhnt von Github. Oder von mir aus auch Gitlab oder Bitbucket. Ist ja alles ähnlich.


    Ich wäre sogar bereit mich oben an die Spitze dieser Github Organization zu stellen. Vorausgesetzt ich bin da oben an der Spitze nicht alleine.

  • Gib mal Beispiele.


    Bitte sehr: wir hatten erst letztens den Thread über das GraphLCD-Plugin hier. Der Artikel im Wiki läßt z. B. das AlphaCool-USB-Display völlig unerwähnt, obwohl es viele einsetzen und es eigentlich Plug'n'Play zu installieren geht, geschweige denn wie eben dieses zu installieren ist. Ist ja auch kein Wunder, da "Letztes Update 02/2011". Außerdem gibt's FREETYPE2 schon lange nicht mehr und man muss stattdessen libfreetype6 installieren (um mal einen Fehler im Wiki zu benennen).
    Weitere Beispiele wären EPGSearch, GraphTFT und PermaShift, um mal die Wichtigsten zu nennen. Ohne mein "Kochbuch" würde ich es heute glaube ich nicht mehr hinbekommen einen neuen VDR mit den Plugins von Grund auf zu bauen...


    Ehrlich gesagt bin ich diese Diskussion leid. Jedesmal wenn ein Neuling hier einschlägt wird ihm erstmal RTFM! an den Kopf geworfen. Nur blöd, wenn TFM unbrauchbar ist. Ich kenne genug andere Wikis die wesentlich besser gepflegt sind, berücksichtige aber auch, dass VDR+Plugins extremst umfangreich sind.


    Grüße,
    j.

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

  • Ein Wiki lebt vom Mitmachen und letztlich kann jeder, der Fehler findet, diese auch direkt korrigieren.


    Die große Frage ist doch, wie man mit ungepflegten Plugins in Zukunft umgehen will.


    Ich hatte "projects.vdr-developer.org" mal so verstanden, dass man dort ein Plugin weiterpflegen kann, wenn der ursprüngliche Entwickler "nicht mehr aufzutreiben ist". Also sollte im Prinzip sowas wie eine Art "direkte Übernahme ohne Zustimmung" nach akzeptabler Wartezeit möglich sein. Keine Ahnung wie es letztlich gehandhabt wird. Siehe "Live-Plugin" wo aktuell ein Fork bei Github steht.


    Aber auch ein Fork zu Github ist ja erstmal kein Problem wenn es denn eine zentrale Anlaufstelle geben würde, wo man die aktuelle Quelle für die neueste Version finden kann. Hier könnte man ja durchaus das Wiki hernehmen, müsste dann aber eigentlich zumindest für die wichtigsten Plugins parallel das englische Wiki auch aktuell halten. Wenn dann ein Plugin, das bisher noch bei projects.vdr-developer.org war, von einem neuen Entwickler auf Github weitergepflegt wird, dann würde man das dort nur umschreiben.


    Prinzipiell könnte man so sogar softhddevice wieder auf ein einziges Git-Repo bekommen. OpenGL-OSD kommt einfach in einen eigenen Branch.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!