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

  • seahawk1986


    Muss mich korrigieren, Patch geht tatsächlich mit github, Dein Beispiel: https://github.com/horchi/vdr-…42cf144f36f327d9c46.patch


    Aber auch wieder try and error ...

    HowTo: APT pinning

  • Zu Github gibt es ein großes Wiki, da steht bestimmt auch irgendwo was über die diversen Link-Möglichkeiten. Ich weiß aber auch nicht wo. Bisher brauchte ich sowas nicht.


    Der Hauptvorteil liegt für mich immer noch darin, dass sich nicht ein einzelner um die Aktualisierung der Software wie Redmine, Datenbank usw. kümmern muss. Heutzutage sollte es jedem klar sein, dass man mit veralteter Software nicht mehr arbeiten sollte. Und dazu gehört auch das vdr-portal. Dass es hier immer noch kein https gibt, ist in Zeiten von Let's Encrypt schon etwas traurig. Und das liegt sicherlich auch daran, dass es eben alles an einer einzelnen Person hängt. Ich finde es toll, was genka und Tobi alles leisten, aber solche Lasten sollte man auf mehrere Schultern verteilen.


    Ansonsten haben beide Plattformen ihre Vor- und Nachteile. Bei ebenbürtigen Dingen kann man lange streiten und nie zu einer Lösung kommen.


    Ich persönlich gehöre nicht zu den Leuten, die Commits per Mausklick herunterladen müssen, ich füge das entsprechende Repository als remote hinzu, mach ein fetch und dann ggf. ein Merge, evtl. sogar ohne Commit, weil ich noch das ein oder andere anpassen muss. Deshalb sind mir die verschiedenen Links relativ egal. Aber die diversen diff-views bei Github sind für einen Überblick schon recht praktisch.


    Was mir noch nicht ganz klar ist, was du mit intuitivem Anmelden und Selbstverwaltung der ssh-keys meinst.


    Lars

  • Ich persönlich gehöre nicht zu den Leuten, die Commits per Mausklick herunterladen müssen

    Geht bedingt um's runterladen, sondern das man einfach rankommt ohne erst einen lokalen Clone haben zu müssen. Mir reichen meine ~50 lokalen GIT Repos für VDR & Plugins ...


    aber solche Lasten sollte man auf mehrere Schultern verteilen.

    Auf welche Schultern? Der Community (Nutzer) die so eine Plattform dringend haben wollen?

    HowTo: APT pinning

  • Und ich hoffe, dass die Anwesenheit des VDRs bei github neue Entwickler außerhalb des deutschsprachigen Raumes anziehen wird, damit sich der VDR auch dort einfacher verbreiten kann. Das beginnt schon damit, einen vernünftigen EPG bei vielen nicht-deutschen Sender zu erhalten.

  • sondern das man einfach rankommt ohne erst einen lokalen Clone haben zu müssen.


    Man kann jede x-beliebigen commit/hash/tag per simplen Mausklick bei github herunterladen - indem man auf die jeweilige Version geht und dann auf den "Clone or download" button drückt ;)
    Bietet dort zwar nur zip an aber das sollte im Normalfall nicht das größte Problem sein (wenn man in der url zip mit tar.gz tauscht bekommt man natürlich auch das).


    .patch / .diff geht auch bei pull requests oder bei branch compares (die auch über verschiedene gits hinweg funktioniert) inkl das man diese bequem herunterladen und bei sich sogar committen kann (curl -L http://github.com/.../commithash.patch | git am - )


    Issue/Bug tracker hat Github auch inkl Einbindung in Slack, Travis, Coverity, Bintray und was weiß ich denn. Alles Dinge um es den Benutzer so leicht wie möglich zu machen mit so wenig Aufwand wie nötig.
    Vor allem kann der normale Github Nutzer (also der in der Lage wäre etwas beizutragen) das alles bedienen und kennt sich aus. Und da kommen wir auch zum wesentlichen, was bieten sich für Vorteile aus einer eigenen gesonderten Git Repo ?


    klare Nachteile von vdr-developer:
    - die meisten werden dort keinen Account haben
    - keine Pull requests
    - keine Fork Übersicht
    - für die meisten eine unbekannte Oberfläche
    - wenig Transparent
    - verschwindet kleine Userzahl im Vergleich
    - international unbedeutend/unbekannt
    (Basics wie 2 Faktor Auth etc lass ich mal weg)


    Das war sicherlich teilweise vor 3-4 Jahren noch anders - das nützt aber Heute auch keinen etwas.


    Es bringt niemanden etwas auf Gedeih und Verderb eine Insellösung für Eingeweihte durchdrücken zu wollen, das bringt nichts. Man ist auf jeden Entwickler "angewiesen" da bringt es doch nichts sich extra noch abzuschotten und zu verstecken, lieber Fahnen raus und um Entwickler werben.
    Sicherlich ist Github nicht die ultimative Lösung, aber es ist die Lösung die mit Abstand populärsten ist.



    Außerdem, frage ich mich, ob es wirklich einen so großen Unterschied machen wird, wenn der öffentliche VDR Core git nur ein "Sammelcommit" mit den Änderungen der Developer Release hat, anstatt die einzelnen Commits die Klaus in sein RCS schreibt.


    Alle Devs die ich kenne winken schon ab wenn kein VCS vorhanden ist und man sich durch diffs quälen darf. Der Entwickler der kein VCS anbietet macht es evtl beitragenden Entwicklern absichtlich schwer bis unmöglich (je nach Kenntnisstand) irgendwas beizutragen. Warum absichtlich ? Weil es keinen wirklichen Grund gibt kein halbwegs aktuelles VCS einzusetzen - das kostet kein Geld und ist auch kein Zeitaufwand. Das heute veraltete CVS ist schon 25 Jahre alt, wenn wenigstens das genutzt wird sind die meisten schon halbwegs zufrieden (auch wenn die meisten mittlerweile nur noch git benutzen werden).


    Und nehmen wir mal an du suchst einen Fehler und willst wissen was diesen Fehler auslöst.
    Im Normalfall würde man einfach paar commits bauen und gucken ab welchen Commit der Fehler auftritt (git blame, git-bisect sind extrem mächtige tools für sowas). Das geht meist schnell und zeigt auch eindeutig was den Fehler auslöst. Wie macht man das ganze nun bei VDR?
    Fehler liegt zwischen 2.2.x und 2.3.x - das Diff ist "riesig" - was nun? Statt das man auch ohne wirkliche Ahnung problemlos einen Commit reverten kann und damit den Bug "beseitigen" bzw melden könnte passiert genau nichts. Der Aufwand ist viel zu groß und somit bleibt es. Wenn man sich in der Codebase nicht auskennt entsthet schnell richtig viel Aufwand.


    tl;tr
    VDR macht es jeden Entwickler absichtlich unnötig schwierig/unmöglich etwas beizutragen oder etwas zu fixen



    Tvheadend ist ein gutes Beispiel wie ein halbwegs funktionierendes Ökosystem aus sehen könnte, dort ist auch ein Hauptentwickler und viele die sich unregelmäßig um viel klein kram kümmern. Ähnlich könnte es auch bei VDR aussehen, aber evtl ist der Zug aber auch schon abgefahren.
    Wenn natürlich kein Interesse besteht die Situation zu verbessern ist das hier auch alles ziemlich sinnlos ;)

  • Also bei mir lebt VDR noch und tut, was er soll ;-).


    Momentan kämpfe ich lediglich mit der Stabilität meiner neuen Hardware (siehe hier), daher verzögert sich die Freigabe einer neuen Version...


    Klaus

  • Ich habe mich auch nochmal mit tvheadend beschäftigt, es hat für mich Vorteile im Bereich iptv (pipe), aber sonst ist es für mich keine Alternative zum vdr.


    vdr-User-# 755 to_h264 chk_r

  • Also,


    wenn ich mir https://tvheadend.org/projects/tvheadend/news anschaue, scheint tvheadend nicht so wirklich aktiv entwickelt zu werden.

    Natürlich sollten wir überlegen, was wir tun könnten, um die Situation bei VDR zu verbessern. Mein Wunsch:

    • URLs im Wiki einfügen / ändern können, um auf aktuelle Repositories zu verlinken
    • Ein Maintener für jedes wichtige Plugin, der zumindest Bugfixes (Patches) einpflegt. Die wichtigsten Plugins (ist natürlich Geschmacksache):
      • Ausgabe (VDPAU, Intel, AMD, RPI). Hier würde ich mir wirklich aktive Maintainer wünschen.
      • Epgsearch
      • live
      • skindesigner


    ~ Markus

    VDR1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 18.04, VDR 2.4x
    VDR2: ASUS P4B533, Celeron 2.4G, FF 1.5, Ubuntu 10.10, VDR 1.6 (SS2 Rev 2.6B)
    VDR Server: sheeva-plug

  • Hi,

    Softhdcuvid, live und epgsearch werden doch aktiv bearbeitet. Skindesigner ist tot.

    Bleiben nur Softhddevice und Vaapidevice...


    Just my 2cts

    Stefan

    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

  • Bei "Live" ist der letzte Commit 2017 gewesen und es sind Bugs offen bei denen auch Patches anhängen.

    Die Entwicklung von "Live" ist also zumindest ausgesetzt.


    Epgsearch scheint noch aktiv entwickelt zu werden.


    Ich würde direkt VNSIServer auf die Liste mit kritischen Plugins aufnehmen wollen. Bei mir ist VDR im Frontend lange Geschichte und bei allen Bekannten die ich noch unterstütze auch.

  • Hi,

    Ja live wird derzeit nur hier im Forum angepaßt, nicht im Repo... Wahrscheinlich weil keine Commitrechte....


    Mit freundlichen Grüßen Stefan

    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