VDR 2.4.7 für Arch, vdr-projects.github.io, TravisCI und ein paar andere Gedanken

  • Hallo VDR Community,


    um folgenden Text kurz und knapp zusammenzufassen: Ich habe fast meinen ganzen Samstag damit verbracht VDR 2.4.7 für Arch Linux (im Kontext "vdr4arch") halbwegs zum Laufen zu bekommen. Eigentlich hätte es ein einfaches "Automatisch Versions-Nummern durch die PKGBUILDs jagen und neubauen" sein sollen, wenn da nicht unnötige Steine im Weg gelegen wären. Dazu aber später mehr.


    Nur das schon vorweg: Klaus hat alles richtig gemacht. Die neue VDR-Version ist top und alle Plugins kompilieren wie gehabt. Dickes :thumbup:für das GIT-Archiv und auch für das "Verteilen der Releases via GIT". Hätte nicht mehr für möglich gehalten das man sowas für das VDR-Projekt mal bekommt.


    Und um auch das Fazit noch in "knapp" vorwegzunehmen: Ich werde in Zukunft nicht mehr so viel Zeit für sowas übrig haben. Sehr viel meiner Zeit wird schon von Arbeit und Studium beansprucht und in der übrigen Zeit kann ich mir, gerade bei schönem Wetter, auch besseres vorstellen als stundenlang Buildscripte zu reparieren.

    Quellcodeverfügbarkeit, Patches, und andere unnötige Steine im Weg

    VDR ist kein großes Projekt und in der Zeit in der sehr viele vom "Live TV" zu "Streaming" migrieren ist es um so schwerer Nutzer und vor allem Entwickler zu halten.


    Entsprechend schädlich ist jede auch noch so kleine Hürde die vom Mitarbeiten abhält. Das sorgt nur dafür, dass neue Entwickler abgeschreckt werden oder bestehende irgendwann keinen Bock mehr haben.


    Leider gibt es im VDR-Kontext recht viele Steine im Weg. Viele Plugins sind lange ungepflegt. Das ist erstmal der "normale Lauf der Dinge". Weniger schön ist aber das für den "Weiterbetrieb" der Plugins nötige Patches dann "gefühlt überall" landen. Ich habe das Thema "projects.vdr-developer.org" mal so verstanden das hier ggf. ein neuer Entwickler leicht Zugriff bekommt und Plugins eben nicht "verwaisen". Das Verwalten von sowas aber einer einzigen Person aufzubürden war vermutlich von Anfang an keine gute Idee. An der Stelle mal vielen Dank an Tobi das er so viel Freizeit in das Thema gesteckt hat. Fakt ist aber: Commit-Rechte hat man schon vor Monaten faktisch nicht mehr bekommen und aktuell ist die Homepage komplett "down".


    Dieses "Gefühlt überall" hat in der Vergangenheit unnötig Zeit verbraten wenn es um Arch Linux geht. Bei Arch werden keine Kopien der Quellcode-Archive gehalten sondern es gibt im PKGBUILD eine Quell-URL und eine Prüfsumme. Ich will jetzt nicht alles aufzählen, aber fakt ist: Ein großes Portal wie GitHub oder GitLab ist deutlich weniger wahrscheinlich "down" wie das VDR-Portal oder projects.vdr-developer.org.


    Ich hab jetzt im Zuge des Upgrades auf VDR 2.4.7 einige Plugins auf https://github.com/vdr-projects umgezogen. Eigentlich hätte ich noch ein paar mehr umziehen müssen, aber noch ist ja Zugriff auf projects.vdr-developer.org/git möglich.


    Ich hab gute Lust alle Plugins die ich für Arch baue, und noch ausschließlich auf projects.vdr-developer.org liegen, auf https://github.com/vdr-projects zu übertragen. Optimum wäre wenn der Entwickler selbst das neue Repo als zweites "remote" einträgt. Andernfalls halte ich diese Mirrors selber aktuell. Ist einfacher als ständig die PKGBUILDs nachzuziehen und wenn projects.vdr-developer.org tatsächlich von heute auf morgen komplett "down" geht, dann ist der letzte Stand wenigstens gesichert.

    Fehlende Arbeitsteilung

    Betrifft sicher nicht nur mich sondern auch die Maintainer anderer Distributionen, aber ich kann direkt nur für Arch sprechen.


    Fakt ist wohl, dass Arch im VDR-Bereich ein ganz kleines Licht ist. VDR-Nutzer sind ohnehin langsam eine "Seltenheit" und Arch ist keine gute Einsteigerdistribution. Entsprechend entfallen von den VDR-Nutzern entsprechend wenige auf Arch.


    Trotzdem sieht man schon anhand der Signaturen das es einige Arch-Nutzer gibt. Und ganz ehrlich: Mich ärgert es jedes mal wenn so ein User dann in irgendeinem Plugin-Thread freudig verkündet das eine neue Version mit Arch funktioniert, ich die Arbeit, das PKGBUILD anzupassen, aber dann nochmal machen darf.


    Ich unterstütze gerne beim "Einlernen" in GIT, aber es ist wirklich keine Kunst einen Fork zu ziehen, da drauf dann einen eigenen "privaten Branch" mit "Extra-Patches" zu hauen und Plugin-Updates gelegentlich auf "master" zu übertragen um einen Pull-Request anzulegen. Die Arbeit ist dann ohnehin schon getan und ich müsste mich nicht um alles selber kümmern!

    TravisCI

    Ich will mich jetzt mal noch nicht allzu breit darüber auslassen weil erstmal noch ein Ticket offen ist, aber aktuell habe ich folgenden Text in dicken Lettern in meinem Travis-Profil:


    Builds have been temporarily disabled for public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance or alter your Consume paid credits for OSS setting.


    Rechnerisch sollte ich pro Monat 1000 Minuten Build-Zeit haben. Das wären 16 Stunden Kompilieren. So viel Zeit habe ich mit Sicherheit nicht gebraucht. Ich gehe deshalb erstmal von einem Fehler aus und warte auf die Antwort auf mein Ticket.


    Sollte sich hier keine Lösung ergeben, dann würde ich Travis komplett abschalten. Ab dann gibt es "Pakete" wieder nur über das "AUR" inklusive der passenden Helper.

  • Ich würde sagen "keine Antwort ist auch eine Antwort".


    Weil ich das starke Gefühl habe, dass die Anzahl der Nutzer der Binär-Pakete, die über Travis gebaut werden, kaum über meine Nutzer im direkten privaten Umfeld hinausgeht und ich selber absolut kein Gefühl dafür habe welche Plugins schon seit Jahren nur noch "der Form halber" am Leben erhalten werden, aber eigentlich doch keiner mehr nutzt, gilt für vdr4arch ab sofort:

    • Es wird nicht nochmal vorkommen das ich mir die Mühe mache jedes einzelne Plugin auf eine neue VDR-Version update. Plugins, die keiner in meiner Bekanntschaft direkt nutzt, werden bei egal wie kleinen Problemen dann einfach aus der repo-make.conf auskommentiert. Was nicht sofort und ohne jeglichen Aufwand gegen eine neue VDR-Version baut --> RAUS. Ein Updaten der "_vdrapi" erfolgt dann auch nicht und entsprechend wird es auch beim Bauen aus dem AUR zu einer Fehlermeldung kommen weil ein Plugin mit der neuen VDR-Version eben nicht mehr kompatibel ist. Die Liste der Plugins die ich und meine direkte Bekanntschaft nutzen umfasst folgende Liste, die ab jetzt die "Liste Plugins erster Prioritätsstufe" ist:
      • vnsiserver
      • live
      • epgsearch
      • epgborder
      • satip
      • (streamdev) nice to have
    • Es besteht für jeden die Möglichkeit fehlende Plugins selber nachzuziehen. Ein Pull-Request wird gerne gesehen. In einem überschaubaren Rahmen kann gerne auch via Issue um ein Update eins Plugins gefragt werden. Gleiches gilt für "Flag out of date" im AUR. Diese "Flags" sind einem Issue auf GitHub gleichgestellt. Plugins die aktiv angefragt werden trage ich auf eine "Plugins zweiter Prioritätsstufe"-Liste ein und versuche die bei VDR-Updates auch nachzuziehen, sofern das in einem überschaubaren Zeitfenster machbar ist. Plugins auf dieser Liste "zweiter Prioritätsstufe" können jederzeit wieder runterfliegen (bei entsprechenden Problemen) und kommen dann erst durch erneutes Nachfragen ("Flag out of date" oder Issue auf GitHub) wieder drauf.

    Ich hätte einige Ideen gehabt wie man das Pflegen der Plugins teilweise automatisieren könnte. Ein Python-Skript das für alle Plugins die auf GitHub oder GitLab liegen einen Versioncheck macht hätte ich faktisch fertig gehabt. Ebenfalls wäre es z.B. möglich gewesen bei einem ffmpeg-Update automatisch über einen Bot ein Issue auf GitHub anzulegen. Leider bedeutet nämlich ein ffmpeg-Update in aller Regel das alle Plugins, die darauf basieren, einen Rebuild brauchen. Diese ganzen Infos sind aber nur dann hilfreich wenn auch jemand Bock hat darauf basierend entsprechende Aktionen einzuleiten. Und eigentlich war, vor allem mit der Travis-Automatisierung, der Plan das für Arch keiner mehr selber bauen müsste. Wenn wenigstens ein oder zwei weitere Arch-Nutzer statt "selber kompilieren" ein Update über Pull-Request eingestellt hätten hätte man für alle Arch-Nutzer ein Binär Repo über drei Architekturen aktuell halten können. Das ist aber nichts was ich ganz alleine stemmen will.


    Ich selber fokusiere mich in nächster Zeit lieber auf VDR-Themen die ich selber auch aktiv nutze und spannend finde. Allen voran mein Python-Modul für SVDRP. Ich hab hier z.B. einen kleinen Python-Daemon der mir direkt aus einer externen Quelle EPG-Daten holt, die in Event-Objekte überträgt und dann mit einem einzigen Aufruf in mein Python-Modul in den VDR spielt. Also ganz ohne irgendein "xmltv2vdr" oder sonstwas dazwischen. Einfach direkt von Python in den VDR ohne irgendwelche EPG-Plugins.

  • Seit solchen Aussagen, die immer wieder mal im Umlauf waren, baue ich selbst:

    Für meinen eigenen Bedarf baue ich via "repo-make" mein eigenes Repository. Dies ist auch weiterhin der empfohlene Weg um ein Repository für den eigenen Bedarf zu erstellen.

    In Zukunft wird sich "VDR-Entwickler-Patch für Arch bereitstellen" von meiner Seite auf "ins VDR-GIT einchecken" beschränken.

    Über das VCS-Paket kann sich das dann jeder bei Bedarf selber neu kompilieren.


    Das PKGBUILD für "vdr" dagegen ist ab jetzt immer das aktuellste stabile Release. Über kleinere Patches kann man ggf. noch reden (nur Patches von Klaus! Eigentlich würde ich am liebsten auch MainMenuHooks loswerden. Weitere "nichtoffizielle" Patches aber auf garkeinen Fall!), aber dort werden keine Patches landen die irgendwelche Header verändern und somit ein Plugin-Neukompilieren erfordern.

    was dem eigenen Einsatzzweck als reines Backend mit Kodi als Frontend geschuldet ist, sieht man ja das kein einziges Ausgabeplugin in der obigen Liste ist.


    Ich nutze den VDR immer noch als VDR mit Bildausgabe sowie allem was dazu gehört mit speziellen Erweiterungen und einem gepatchten VDR sowie Plugins, diese baue ich zudem nicht als TAG Versionen sondern per COMMIT und das mitunter bei Änderungen mehrmals die Woche. Das ist immer noch annähernd der Weg wo damals dem geneigten Arch User mitgegeben wurde (siehe Zitate), deshalb versteh ich die aktuelle "Aufregung" dazu nicht da es meiner Meinung nach ein "hausgemachtes" Problem ist.


    Trotzdem Danke was bisher für arch im Bezug auf den VDR gemacht wurde.

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Zur ersten Aussage: Das ist ne Weile her. Mittlerweile nutze ich eigentlich auch die Travis-Builds. Aktuell bekomme ich aber nichts gebaut. Sieht so aus als liegt es an Mirrors. Mal morgen nochmal anstoßen.


    Zur zweiten: Ja, das stimmt so. Das "vdr-git"-Paket braucht aber mal ein Update. Mit den Änderungen von kls kann die "pkgver"-Funktion stark vereinfacht werden. Quelle ist auch nicht mehr "mein" GIT sondern direkt das von Klaus. Alle Plugin-Pakete sollte eigentlich mit "vdr-git" kompilierbar sein.

    was dem eigenen Einsatzzweck als reines Backend mit Kodi als Frontend geschuldet ist, sieht man ja das kein einziges Ausgabeplugin in der obigen Liste ist.

    Aktuell bin ich der einzige der noch regelmäßig aktiv an vdr4arch arbeitet und es ist nunmal fakt das "Fernsehen" bei mir und meiner direkten Verwandtschaft mittlerweile eine Priorität hat die ganz stark zu Null tendiert. TV-Anschluss habe ich nur noch am aktuellen "Zweitwohnsitz". Am "Erstwohnsitz" habe ich keinerlei TV-Anschluss und nutze auch keinen entsprechenden Online-Dienst. Ich nutze den VDR mit Kodi fast nur noch für "Sat-Radio" und habe zwei Suchtimer laufen die Kram aufnehmen den ich eigentlich einfacher über die Mediatheken bekommen könnte.


    Daraus folgt auch: Ich kann keine Ausgabe-Plugins testen. Ich kann checken ob die kompilieren, weiß dann aber auch nicht wann ein Rebuild wegen Library-Updates nötig wäre weil ich die Plugins selber gar nicht laufen lassen kann. Nein, ich werde mir hier kein Testsystem für "VDR-Ausgabe" hinstellen und ich werde meinen HTPC auch nicht so vergurken das da eine VDR-Ausgabe geht. Das Ding ist "Arbeitstier" und soll nach einem langen Tag am Abend ohne große Mucken Amazon-Prime, Twitch oder YouTube wiedergeben. Außerdem ist mir die Gefahr zu groß das ich jetzt wieder Aufwand treibe, oder gar Geld in die Hand nehme, nur das dann letztlich doch keiner die entsprechenden Plugin-Pakete nutzt. Schade um die Zeit.


    Um ernsthaft wieder "runden" Support für Ausgabe-Plugins möglich zu machen bräuchte es im Team wenigstens einen weiteren Helfer der das auch aktiv noch nutzt und so, nicht wie ich, rein nur auf "baut noch" prüft sondern auch mal ein Plugin wirklich laufen lassen kann. Solange das nicht der Fall ist, stimme ich dir voll und ganz zu: Weil im aktuell aktiven vdr4arch-Team keiner mehr die VDR-Ausgabe nutzt gibt es keinerlei Garantie das die tatsächlich funktioniert oder gar Plugins regelmäßig die "pkgrel" hochgezählt bekommen um bei Library-Updates einen Rebuild zu triggern.


    Zu Patches: Es hat seine Gründe warum hier bewusst auf das absolute Minimum gesetzt wurde. Einen Patch der "unbedingt sein muss" bitte mit Klaus diskutieren und irgendwie in den VDR direkt einbauen. Bei Plugins, die Patches brauchen, besteht immer die Gefahr das es irgendwann an einem fehlenden Patch scheitert. Solche Plugins würden dann recht schnell wieder rausfliegen.

  • Es hat seine Gründe warum hier bewusst auf das absolute Minimum gesetzt wurde.

    Kein Thema, es hat aber auch seine Gründe warum ich gerne einen gepatchden VDR nutze und in dem Fall von der Vorgabe abweiche und somit nicht mehr für den Standard um was es hier geht kompatibel bin.


    Vielleicht findet sich noch jemand, dem der Weg taugt, ist ja alles noch möglich ;)

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Sorry, dass ich mich so spät melde, habe den Thread erst jetzt gesehen.


    Vielen Dank an M-Reimer für den vdr4arch, ich nutze ihn fleißig auf meinem Headless VDR Server und demnächst hoffentlich auch wieder auf dem raspi4.


    Nachdem ich diverse andere Software automatisiert aus dem AUR baue, nutze ich auch die VDR Pakete, die von vdr4arch auf AUR hochgeladen werden. Im Moment fehlen dort ein paar Fixes (gcc 11), hältst Du das noch aktuell oder ist es besser, meinen Build-Mechanismus auf das vdr4arch repository im GitHub umstellen?

  • AUR habe ich selber nie für irgendeine Art von "automatischem Bauen" genutzt. Ich lade mir die PKGBUILDs von dort immer erst runter, lese da grob drüber und führe das erst dann aus.


    Auf dem GIT landen Updates definitiv schneller. Upload zum AUR ist aber nur ein Aufruf und läuft dann automatisch. Werde ich also schon weiter updaten, aber wird trotzdem immer mal wieder vergessen.


    Bitte aber meine Liste von Plugins "erster Prioritätsstufe" beachten. Bei der aktuellen Situation garantiere ich nur noch dafür halbwegs zeitnahe Updates. Für alles andere müssten dann und wann auch mal Pull-Requests kommen. Ich sehe nicht mehr ein auf Verdacht die komischsten Plugins aktuell zu halten wenn man die Anzahl der Nutzer ohnehin an einer Hand abzählen kann.

  • Hallo zusammen,


    bin zwar Arch-Nutzer, aber schon vor fast zwanzig Jahren, als ich auf den vdr gekommen bin, habe ich mich schnell von fertigen Binärlösungen verabschiedet und den vdr im Quellerzeichnis immer selbst gebaut.


    Nichtsdestotrotz war es meiner Erinnerung nach immer schwierig, für die gewünschten Plugins alle Patches von hier und dort zusammenzusammeln. Die PKGBUILDS auf AUR sind daher eine willkommende Quelle für mich, um diese Suche abzukürzen.


    Also:

    Ich würde es begrüßen wenn AUR eine Quelle bleibt, wo man transparent sieht, wie ein Paket noch baubar ist. Ein Binär-Repository für Archlinux wäre aus meiner Sicht verzichtbar.

  • Nichtsdestotrotz war es meiner Erinnerung nach immer schwierig, für die gewünschten Plugins alle Patches von hier und dort zusammenzusammeln. Die PKGBUILDS auf AUR sind daher eine willkommende Quelle für mich, um diese Suche abzukürzen.

    Mein Glückwunsch. Ich werde das in Zukunft aber auch nicht mehr machen. Was nicht baut fliegt raus. Es sei denn es ist ein Plugin auf der Prioritätsliste.


    Patches irgendwo im VDR-Portal "reinwerfen" IST MIST. Es gibt entsprechende Upstream-Projektseiten. Da und nur da hin gehören Patches.

  • Danke für die Glückwünsche. Wollte damit aber eigentlich zum Ausdruck bringen, dass die Arbeit jenseits von Binärpaketen, deren Downloadzugriffe wenn ich richtig lese den Aufwand nicht lohnen, nicht umsonst war.


    Aber wo geht die Reise jetzt hin:

    Im AUR wird man weiterhin die oben genannten fünf Plugins finden?

    Der Rest, bleibt oder fliegt raus? Oder wird eben aktualisiert, wenn jemand sich mit einem Patch etc meldet?


    Das wir alle vdr-Projekte top-gepflegt an einen Ort bekommen, scheint ja ein Wunsch zu bleiben. Aber irgendwie müssen wir ja die letzten Tage, wo man zwischen Mediatheken und Streaming-Diensten noch irgendeine Daseinsberechtigung für seinen vdr findet, in Würde gestalten.

  • Danke für die Glückwünsche. Wollte damit aber eigentlich zum Ausdruck bringen, dass die Arbeit jenseits von Binärpaketen, deren Downloadzugriffe wenn ich richtig lese den Aufwand nicht lohnen, nicht umsonst war.

    Ich nutze die Binärpakete selber und brauche die auch für einen Bekannten bei dem ich noch VDR laufen habe. Aber eben nur für die "Plugins Prio 1".


    Aber wo geht die Reise jetzt hin:

    Im AUR wird man weiterhin die oben genannten fünf Plugins finden?

    Der Rest, bleibt oder fliegt raus? Oder wird eben aktualisiert, wenn jemand sich mit einem Patch etc meldet?

    Letzteres. Nur noch auf "Zuruf" oder am allerliebsten direkt über Pull-Request.

    "Zuruf" dann entweder über Issue auf GitHub oder über "Flag as out of date" im AUR.


    Ich verlange einfach ein Grundmaß an Unterstützung von denjenigen die das Zeug auch nutzen. Und sei es nur ein Hinweis das etwas aktualisiert werden müsste. Damit fliegen Plugins, die keiner mehr braucht, nämlich ganz automatisch raus. Wenn sich niemand darum schert ob ein Plugin noch baut oder ob es aktuell ist, dann ist es auch den Aufwand nicht wert noch "am Leben erhalten" zu werden.


    Das wir alle vdr-Projekte top-gepflegt an einen Ort bekommen, scheint ja ein Wunsch zu bleiben.

    "an einem Ort" müsste ja garnicht sein. "An einem bekannten Ort" würde voll und ganz reichen. Dort dann aber auch halbwegs zuverlässig und wenn jemand einen Patch hat, dann bitte auch dorthin schicken und nicht irgendwo "reinwerfen" wo ihn dann nach X Monaten keiner mehr findet.

  • Plugins, die keiner mehr braucht


    Da würde mich mal eine Aufstellung interessieren.

  • S c...

    Lol

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Ich kann das mal aus der Perspektive von LibreELEC schildern.


    Wer es nicht kennt kurze Info:

    Eine Linux Distro die gerade genug Linux an Board hat um Kodi zu starten, ausgelegt auf super einfach Nutzung ohne jegliche Linux Ahnung. Wir sind sehr nahe am jeweils aktuellsten was es gibt, wir haben kein apt/yum oder ähnliches. VDR bieten wir als Addon an, anklicken, fertig. VDR wird nur als Server benutzt und kann über das Kodi interface auch bedient werden - im klassischen Jahr 2000 Feeling.


    Will mich nicht zu weit aus dem Fenster lehnen (ich hab keine Zahlen, ich geh mal von der Anzahl der Zielgruppe und insgesamten Nutzer aus) aber wir sind wahrscheinlich eine der größten Userbase von VDR.


    Keiner aus unserem Team nutzt VDR, gefühlt ist eh 3/4 zu Tvheadend gewechselt (Webinterface ist hier der Hauptgrund).

    Am Leben gehalten wird es trotzdem, das ganze zu updaten hat meistens keiner Lust weil immer irgendwas nicht geht.

    Gammel Plugin 1 und 2 geht nicht und das Liveplugin ist eh immer ganz vorne dabei das da wieder was nicht geht und irgendwer irgendwo im Forum von einem Patch redet der es möglich macht.

    Weniger schön ist aber das für den "Weiterbetrieb" der Plugins nötige Patches dann "gefühlt überall" landen.

    Logischerweise nur im Forum, das an Upstream zu schicken wäre ja quatsch würde ja nur allen helfen.

    Davon kann ich Lied singen, darauf hab/wir keinen Bock mehr, das hat bei uns auch dazu geführt.


    Was nicht baut fliegt raus



    Ich weiß nicht warum aber im VDR Öko System herrscht noch immer die Patch-Ausdrucker Mentalität.

    Github hat es so einfach gemacht, aber da machen "wir" ja nicht mit.


    Ich war auch Froh als es endlich ordentliche Sourcen von VDR gab und die Weiterentwicklung vom Core auch gut voranschreitet.

    https://github.com/vdr-projects ist ein Träumchen


    Aber ehrlich gesagt ist das alles egal wenn drumherum die wichtigen Plugins weggammeln. Ein blankes VDR ist relativ nutzlos.


    vnsiserver, satip, iptv und das böse plugin sind so was immer gehen muss sonst ist es für viele nicht nutzbar

    50% von denen sind quasi EOL, satip wird ja zum Glück noch weiterentwickelt - also unter dem Strich hängt alles an einer Person.


    Ein vernünftiges Webinterface gibts ja bis heute nicht, das die meisten VDR nur noch als Server laufen ist ja kein Geheimnis.


    Fazit für uns ist solange es baut alles gut, wenn es nicht mehr geht fliegts raus.

    Viel Energie steckt keiner mehr rein, es wird einem einfach zu schwer gemacht und wer selber Packet Maintainer ist weiß das man da mehr als genug zu tun hat auch ohne die Hindernisse.


    Das schlimme ist ja das es Hausgemacht Hindernisse sind die nicht sein müssten :(

  • Quote

    Github hat es so einfach gemacht, aber da machen "wir" ja nicht mit


    Ähm - nein. github macht es nur jemandem einfach, der anderen Probleme melden will, ohne selbst beizutragen. Und es macht denjenigen es einfach, die einfach mal das aktuellste schnell von github holen wollen, ohne die eigene wertvolle Zeit dabei zu verschwenden.


    Für alle andren Beteiligten (also, die welche an Problemen denn wirklich arbeiten...) ist das einfach nur anstrengend und zeitraubend.

  • Es ist sehr interessant, wie sehr in letzter Zeit auch die Interessen auseinander driften..


    vnsiserver << für mich nutzlos


    satip << jaaa, wie lange das wohl noch gut geht.

    Und was das gelobte github betrifft, kann man bei rofafor froh sein, wenn er in zwei Wochen überhaupt reagiert. Einen VDR hat er nicht mehr.

    Änderungen durch zu bekommen, die *notwendig* sind, ist extrem schwer, seit alles dort nur noch per github geht. Habe ich hier aufgegeben.


    iptv << würde ich seht gerne einsetzen, aber IMO zu teuer bei meinem jetzigen Internet Anbieter.

    Aber was die Zukunft des Plugins angeht, siehe satip.


    das böse plugin << brauch ich nicht, gibt ja auch andre Möglichkeiten.

  • Keiner aus unserem Team nutzt VDR, gefühlt ist eh 3/4 zu Tvheadend gewechselt (Webinterface ist hier der Hauptgrund).

    Hab ich ausprobiert und ich muss sagen: Ich finde das Webinterface von Tvheadend ziemlich Sch💩. Der einzige positive Grund für dieses Webinterface ist, dass es existiert und direkt vom Start weg da ist. Das war es aber auch. Aus Sicht eines Webentwicklers ist hier dringend "einmal neu machen" angesagt. Wird aber auch da niemand mehr machen. TV an sich hat gerade in der "technikaffinen" Zielgruppe viel an Boden verloren. Selber aufnehmen (und eventuell sogar noch schneiden) ist einfach ein Aufwand der einem von einem Streaming-Dienst abgenommen wird.

    Fazit für uns ist solange es baut alles gut, wenn es nicht mehr geht fliegts raus.

    Schön das auch mal von anderer Stelle so zu lesen.


    Und was das gelobte github betrifft, kann man bei rofafor froh sein, wenn er in zwei Wochen überhaupt reagiert. Einen VDR hat er nicht mehr.

    Änderungen durch zu bekommen, die *notwendig* sind, ist extrem schwer, seit alles dort nur noch per github geht. Habe ich hier aufgegeben.

    Die Frage ist: Was macht GitHub an der Stelle schlechter? Man kann sich ohne viel Verrenkung einen Fork ziehen, dort so viel committen wie man lustig ist und dann über einen Pull-Request nicht nur die eigenen Commits sondern auch direkt den eigenen Namen ins Upstream-Projekt bekommen. Viel besser und einfacher kann man es doch garnicht haben.


    Und wenn der ursprüngliche Autor längere Zeit (oder gar nicht) auf einen Pull-Request antwortet? Dann committe ich einfach lustig in meinem Fork weiter und irgendwann spricht sich dann schon rum (ggf. auch nach Ankündigung hier im Forum) das das Projekt eben jetzt in aktueller Version dort zu finden ist.


    Nicht anders habe ich es mit einigen Plugins gemacht die bei vdr4arch drin sind. Wenn ein Entwickler sich mehrere Jahre nicht um sein Projekt kümmert und die Patches, die nötig sind um es zu nutzen, sich schon an verschiedenen Stellen stapeln, dann gibt es doch keine Verpflichtung das Projekt vergammeln zu lassen. Die Lizenz unter der der Quellcode veröffentlicht wurde erlaubt sogar ganz ausdrücklich eine Anpassung und Erweiterung.

  • Quote

    Die Frage ist: Was macht GitHub an der Stelle schlechter? Man kann sich ohne viel Verrenkung einen Fork ziehen, dort so viel committen wie man lustig ist und dann über einen Pull-Request nicht nur die eigenen Commits sondern auch direkt den eigenen Namen ins Upstream-Projekt bekommen. Viel besser und einfacher kann man es doch garnicht haben.


    Ok. Ist wohl wirklich schwer zu begreifen, wenn man es versucht jemandem zu erklären, der es selbst nie versucht, weil er schon damit zu viel zu tun hat, fertigen Code zusammen zu suchen. *sorry*


    Man hat eigentlich nur zwei Möglichkeiten bei github, entweder man versucht ein Problem mit dem originalen Autor zu lösen oder man macht einen fork (und schon wieder gibt es einen der Myriaden weiteren forks, der genau ein Problem löst und aber keines der anderen existierenden Probleme). So wie softhd(xyz)


    Den von dir angepriesenen Pull Request lässt der Autor normalerweise erst einmal ohne Antwort für ein paar Wochen 'reifen', um dann erneut einem Steine in den Weg zu legen. Sehr schön zu sehen an den Pull requests des Satip Plugins oder beim Zusenden von Patches für femon in der Vergangenheit. Also nicht, dass das bei andren Plugins jetzt besser wäre.


    Irgendwann gibt man dann einfach auf und macht etwas sinnvolleres mit der eigenen knappen Zeit.

  • Ganz ehrlich: Wenn die Projekte faktisch ungepflegt sind, dann migriere die in deinen GitHub-Account und gut ist. Wenn der ursprüngliche Autor selber keinen VDR mehr hat kann ich mir auch nicht vorstellen das er bei einer freundlichen Mail mit der Bitte das Projekt "offiziell mit seinem Segen" übernehmen zu können ein "Nein" zurückschreibt.


    Genau dafür habe ich ja mal diese Liste angeregt: https://vdr-projects.github.io/

    Wo wer seine Projekte pflegt ist seine Sache. Man muss aber einfach mal irgendwo hinschreiben wo es aktuell und aktiv gepflegt wird, denn Entwickler kommen und gehen. Jeder verliert mal an einem Projekt das Interesse (erst Recht wenn es in der Freizeit entsteht) und ein anderer übernimmt ab einem gewissen Punkt.


    Und bei einem wirklich aktiv gepflegten Projekt ist ein Review eines Pull-Request jetzt erstmal nicht wirklich ungewöhnlich. Ich reiche die auch nur selten komplett ohne "Review" durch. Erst wenn ich mit der Anpassung zu sagen wir 90% zufrieden bin nehme ich den Pull-Request an, schiebe dann aber ein/zwei "Fix-Commits" nach um aus 90% die anzustrebenden 100% zu machen. Wenn ein Pull-Request aber z.B. komplett gegen meinen Coding-Style geht und ich durch Annehmen mehr Zeit ins Reparieren stecken muss als den Fix selber zu coden, dann werde ich immer erstmal Nachbesserung fordern.

  • Nichts gegen Reviews, die retten uns allen den Poppes; sehr schön zu sehen am Beispiel des Linux Kernels..


    Aber wenn ohne ersichtlichen Grund eine sinnvolle Änderung in winzige Stücken alle paar Tage eines aufgeweicht wird,

    die dann auch noch mehrmals so viel CPU und Speicher frisst für nix...


    Was die Bitte betrifft ein Projekt zu übernehmen; ja. Wie viele Projekte kann jemand übernehmen? Eines, zwei, drei..?