https://github.com/vdr-projects/ teilweise wiederbelebt

  • Ich werde künftig Änderungen auch auf GitHub veröffentlichen: https://github.com/reufer/rpihddevice

    Ist eingetragen.


    Hier ist mal ein Beispiel wie das aussehen könnte bei komplett ungepflegten Plugins: https://github.com/vdr-projects/vdr-plugin-bgprocess


    Ursprungsstand (war ein Tarball) importiert. Patches von yaVDR rauf und neues Release getaggt, dass das Kind auch einen Namen hat :P


    Das das Makefile alt ist, habe ich als Issue angelegt. Wenn jemand Bock hat, gerne einen Pull-Request erstellen.

  • Status aktuell: "projects.vdr-developer.org" ist vorerst wohl "down".


    Problem ist, dass Arch generell aus externen Quellen baut. "Debian-basierte" haben da nicht so gravierende Probleme, da auf Launchpad immer eine Kopie der Quellen liegt. Alles was auf projects.vdr-developer.org gehostet ist/war kann für Arch also aktuell nicht gebaut werden.


    Weil es alphabetisch als nächstes dran ist habe ich mal "burn" auf vdr-projects umgezogen. Ich nutze das zwar nicht selber, aber es wäre auch schade wenn es "verschwindet". Bei "archive.org" findet man einige der Quellcode-Pakete noch und die yaVDR-Patches hab ich auch direkt drauf gepackt. Also außer der "genisofs"-Patch. War es nicht so das auch Debian mittlerweile zu cdrtools zurückgekehrt ist nachdem die ihren Fork in den Sand gesetzt haben? Wenn das jemand noch nutzt und sich berufen fühlt: https://github.com/vdr-projects/vdr-plugin-burn/issues/1

  • Da ich das 'control' Plugin zum Fernsteuern des VDR via telnet Port 2002 nach all den Jahren immer noch benutze, habe ich dem Plugin mit meinem Stand mal eine neue Heimat gegeben. Funzt mit 2.4.6 immer noch problemlos.



    https://github.com/wirbel-at-vdr-portal/vdr-plugin-control

  • Ich hab das früher auch benutzt, nehme jetzt dafür remote.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich habs auf meinem Testsystem installiert, funktioniert und sieht besser aus als remote, beide tun, was sie sollen.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • eepg und gamepad hab ich auch mal übertragen.


    Bei länger ungepflegten Plugins (vor allem wenn Patches nötig sind) muss man nicht lange überlegen aber bei offensichtlich gepflegten müssten die Maintainer mal überlegen wie sie weiter verfahren wollen. Ich kann gerne auf vdr-projects ein Repo anlegen, aber eine Pflicht gibt es dafür natürlich nicht.


    Ich würde das Ausfallen von "projects.vdr-developer.org" jetzt einfach mal als "Warnschuss" werten. Der GIT-Server geht zwar noch und wenn Releases getaggt wurden bekommt man sie über die GIT-Weboberfläche auch noch, aber wer weiß wie es weiter geht.


    Mir geht es da aktuell vor allem um epgsearch, welches ja noch auf projects.vdr-developer.org liegt. Keine Ahnung wie der VDR-Nickname des Maintainers ist.

    Weiterhin dürfte epg2vdr und der "vdr-epg-daemon" nach wie vor gepflegt sein. Hier ist wohl horchi zuständig.

  • M-Reimer : Ich finde es cool dass sich jemand dem Thema angenommen hat. Auch an die anderen. Top!!!


    Ich selbst nutze den vdr seit Mitte der 90iger Jahre.....

    Mein VDR läuft soweit und habe nur von Zeit zu Zeit als was wo nach ich suche....

    Naja, jedenfalls bin ich keine wirklich Hilfe, da ich nit mit C unterwegs bin..... (Java, python,....)

    finde es aber top, dass es euch weiterhin gibt.

    Vielleicht steuere ich irgendwann mal was sinnvolles bei, schließlich

    bin ich weiterhin ein Fan und Verfechter für den VDR..... und kann irgendwann mal was der community geben...


    Danke and Euch... für das Zusammenstellen und weiterpflegen auf GitHub....

  • Ich bin eigentlich leidenschaftslos, ob epgsearch bei vdr-developer oder unter vdr-projects liegt. Mich nerven nur etwas Seiten, die behaupten, mirror von etwas zu sein und jahrelang keinen Pull machen. Solange im ungepflegten vdr-wiki noch der Verweis auf vdr-developer steht und das git dort funktioniert, werde ich es da aktuell halten.

    Ich betrachte es aber auch nicht als großen Aufwand - bei entsprechender Berechtigungserteilung - das Repos auf vdr-projects aktuell zu halten.

    vdr-2.6.0
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.10 ,AsRock J4105, CIne CT-V7 DVB-C

  • Hi,

    Vdr-developer ist aber ja nicht mehr nutzbar. Da kommt ja nur ein interner Fehler.

    Mfg 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

  • Ich bin eigentlich leidenschaftslos, ob epgsearch bei vdr-developer oder unter vdr-projects liegt. Mich nerven nur etwas Seiten, die behaupten, mirror von etwas zu sein und jahrelang keinen Pull machen. Solange im ungepflegten vdr-wiki noch der Verweis auf vdr-developer steht und das git dort funktioniert, werde ich es da aktuell halten.

    Ich betrachte es aber auch nicht als großen Aufwand - bei entsprechender Berechtigungserteilung - das Repos auf vdr-projects aktuell zu halten.

    Einladung ist raus. Ich stelle das auf vdr-project.github.io später noch um, lasse aber auf "Active Maintainer". Du hast "Maintain"-Rechte. Das sollte reichen das du auch selber weitere Beitragende eintragen könntest falls das in Zukunft sinnvoll wird.

  • Moin,

    ich hab diese vdr-projects hier mal wieder reichlich spät mitgekriegt...


    Meine Beiträge für die Liste wären:


    https://github.com/madmartin/vdr-clock


    undelete plugin: https://github.com/madmartin/vdr-plugin-undelete

    Das habe ich mal nach github übertragen, es ist nicht wirklich unmaintained, der Author ist Petri Hintukainen (macht auch https://sourceforge.net/projects/xineliboutput/) aber die Source ist http://phivdr.dyndns.org/ - da klingeln bei mir alle Alarmglocken, solche Websites können jederzeit verschwindwn.

    Und ich werde es noch ein bisschen hübscher machen.


    cinebar plugin:

    https://github.com/madmartin/vdr-cinebars ist etwas nachbearbeitet gegenüber https://github.com/vdr-projects/vdr-plugin-cinebars


    Und dann pflege ich noch https://github.com/madmartin/noad weiter, kein echtes Plugin, aber ein Addon. Die Sourcen davon sind schon vor Jahren verschwunden, und ich benutze es immer noch lieber als vdr-markad.


    Vielleicht ergänzt Du die Liste noch um eine Rubrik VDR Addons?


    Gegen eine Aufnahme in die vdr-plugin Organisation habe ich auch nichts einzuwenden, da pflege ich gerne mit.


    Grüsse

    Martin

  • Das habe ich mal nach github übertragen, es ist nicht wirklich unmaintained, der Author ist Petri Hintukainen (macht auch https://sourceforge.net/projects/xineliboutput/) aber die Source ist http://phivdr.dyndns.org/ - da klingeln bei mir alle Alarmglocken, solche Websites können jederzeit verschwindwn.

    @phintuka pflegt seine VDR Plugins schon immer, d.h. viele, viele, viele Jahre auf Sourceforge, u.a. xineliboutput, suspendoutput, undelete oder autotimer. Das wird dort nicht verschwinden, auch nicht von seinem Server, daher finde ich Deinen Ansatz und Vorgehen doch recht anmassend. Github bzw. Gitlab sind nicht die einzige Wahrheit, SF war z.B. lange vorher da ...


    Wenn Du undelete fork'en möchtest, ok, aber es gibt soweit ich das sehe kein Grund hier einen auf Retter zu machen. Der original Autor ist bekannt, immer noch erreichbar und kümmert sich um die Plugins.


    Zumal es einen undelete Patch von kamel5 für VDR selbst gibt, 👍, der hier wirklich gut funktioniert: VDR-2.4.X und Undelete

    HowTo: APT pinning

    The post was edited 2 times, last by fnu ().

  • Hallo fnu ,

    Deine Aufregung über die Plugins von "phintuka" würde ich ja verstehen wenn sie tatsächlich auf sf.net zu finden wären. Das einzige was ich da aber finde ist das vdr-xineliboutput und xine selbst, an dem Petri arbeitet. Kein autotimer, suspendoutput, undelete.

    Siehe hier: https://sourceforge.net/u/phintuka/profile/

    Also sehe ich weiterhin nur seinen Home-Webserver. Und von solchen Webservern haben wir doch alle schon viele einfach so verschwinden sehen.


    Wenn es also zwei undelete-Plugins gibt, warum ist dann keines bei https://vdr-projects.github.io/ erwähnt - die Zeile "undelete" steht auf "TBD". Sollte also wohl mal beides dort eingetragen werden.

  • Also sehe ich weiterhin nur seinen Home-Webserver. Und von solchen Webservern haben wir doch alle schon viele einfach so verschwinden sehen.

    Nun, den Server kenne ich seit vielen Jahren, war immer erreichbar. Weiß also nicht was Deine Story ist, bloß weil Dir die dyndns Anbindung nicht gefällt. Er hätte auch (s)eine TLD drüber legen können, ohne das man dies dann überhaupt erkennt.


    phintuka ist so ein sehr erfahrener langjähriger Entwickler (s. VDR/CONTRIBUTORS), der kennt ganz sicher gitxxx, will es aber offensichtlich darüber nicht zur Verfügung stellen. xineliboutput war z.B. eines der ersten Softausgabe Plugins, IIRC 2004, und wird bis heute gepflegt.


    Nochmal, Du willst das undelete Plugin fork'en, feel free, aber es ist dann Dein Fork und als solcher auch zu kennzeichnen. Der orig. Author/Maintainer ist noch aktiv und stellt es anderes zur Verfügung (use-as-is) ... es gibt also aktuell nichts zu retten.


    Wenn es also zwei undelete-Plugins gibt, warum ist dann keines bei https://vdr-projects.github.io/ erwähnt - die Zeile "undelete" steht auf "TBD". Sollte also wohl mal beides dort eingetragen werden.

    Na, vmtl. weil keiner was eingetragen hat. Aber es ist auch kein Pflicht dort was einzutragen, wie es auch keine Pflicht ist, sein Projekt via gitxxx zur Verfügung zu stellen ... aber die Diskussion gab es bereits vor Jahren.

    HowTo: APT pinning