Posts by md_berlin

    Ich hab für mich mal eine Übersicht erstellt und zumindest schonmal die "offensichtlich aktiven" gemirrort: https://vdr-projects.github.io/migration

    Ich werde das, so wie es Zeit und Lust zulässt, noch auf "ältere" Projekte ausweiten.


    Alle Mirrors finden sich hier: https://github.com/vdr-projects

    Ich finde das sehr lobenswert!


    Gerne erstelle ich auch ein paar mirrors mit Repos, die ich für wichtig halte.

    Im übrigen bin ich durchaus dafür jedes Plugin etc. zu "retten", wer will jetzt schon beurteilen ob der Code nicht irgendwann von jemand wiederbelebt wird oder vielleicht wichtige Anregungen / Code-Schnipsel liefert.

    Heißt also im Klartext: ich würde mich auch am "mirrorn" der Repos beteiligen, die mir persönlich weniger wichtig sind-

    Hi,

    mein Angebot der Mitarbeit steht auch noch.

    Die Idee von privatem Hosting finde ich allerdings nicht mehr so toll, seit ich vor nunmehr zwei Jahren einen Freund und Arbeitskollegen ohne Vorwarnung verloren habe und das IT-Chaos für die Hinterbliebenen mit bereinigt habe.

    Daher finde ich das Engagement von M-Reimer für https://github.com/vdr-projects/ so sinnvoll und lobenswert. Man sieht ja wie die Community um vdr zerfällt, duch Änderungen der Lebensumstände, Nicht-mehr-Nutzung durch andere Technik ("ich guck nur noch Streaming"), sonstiger Verlust von Interesse oder gar nicht vorhersehbares Ableben.

    Dann sind Server ungepflegt, Home-Server mit dynamischen DNS Namen verschwinden einfach, und und und. Letzte Rettung https://archive.org/

    Daher würde ich grundsätzlich vorschlagen solche Site-Transfers nur noch auf Plattformen zu machen die eine "Überlebens-Chance" haben die über das ehrenwerte Engagement des einzelnen Initators hinausgeht.

    Entweder durch Admin-Gemeinschaften, die mehr voneinander wissen als nur Nicknames und Mail-Adressen, oder Plattformen wie eben Github oder Sourceforge.

    Wie wäre es mit https://github.com/vdr-projects/vdr/wiki/ ?


    CU
    Martin

    Ok, klares Statement.

    Ich bin durchaus dafür lieber früher als zu spät ein "Fork" auf einer "öffentlichen" Plattform (sf.net, Gihub, Gitlab usw.) anzulegen, die auch ein längeres Motivationsloch oder ungeplante Abwesenheit bis him zum Tod des Besitzers überlebt. (Bin da etwas sensibel, habe letzteres schon 2x erlebt).

    Nur sehe ich an der ersten Reaktion auf meinen ersten Beitrag daß manche Leute das einfach nur dreist finden. Damit muss ich wohl leben.

    Meine Definition von "ungepflegtes Plugin" ist, dass es nicht mehr mit aktuellen VDR-Versionen gebaut werden kann. Wenn mal für über ein Jahr bei einer größeren VDR-Distribution (also nicht vdr4arch) ein Patch rumliegt der zwingend nötig ist, der Entwickler den aber nach über einem Jahr nicht in einen neue Version eingebaut hat, dann wird es meiner Meinung nach Zeit eine aktualisierte Version irgendwo abzulegen um den Patch mal "Distributions-neutral" bereitgestellt zu haben.

    Wenn ich für ein Plugin, dessen Original-Homepage noch verfügbar ist, genau EINEN Patch habe, damit es für den aktuellen vdr compiliert/funktioniert, wäre es dann nicht sinnvoller nur diesen einen Patch zu verlinken (zusätzlich zur Original-Homepage) ?

    Auch bei dieser Lösung kann ich den Original-Author anschreiben und bitten die Patche zu übernehmen, danach ist es auch leicht auf der Liste wieder auch "Active Maintainer" zu ändern.


    Beispiel: https://madmartin.github.io/vdr-projects.github.io/ plugin epgsync

    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.

    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

    Hi,


    ich hab noch zwei weitere Ideen was da vielleicht nicht stimmt.

    Mein Satip Server ist ein EXIP414/e der ist dem EXIP418 sehr ähnlich.


    1) Welche Art LNB ist angeschlossen? Eins mit integriertem Mulitschalter? dann ok. Wenn eines mit vier Anschlüssen wo Low/vertikal High/Vertikal usw, unterschieden wird - dann sind vielleicht Kabel nicht richtig angeschlossen?


    2) beim EXIP414 müssen für korrekten Betrieb im satip-Plugin "Quirks" aktiviert werden, und zwar "ForcePilot". Beim EXIP414 erfolgt das über den UPNP-String


    "KATHREIN SatIP Server"


    Aktuelle Versionen vom satip-plugin setzen dann das "ForcePilot".

    Die entsprechende Zeile im syslog nach dem vdr start sieht dann so aus:



    Code
    1. May 13 20:28:58 vdr vdr: [24364] SATIP: Adding server '192.168.166.129|DVBC-4|FRITZ!Box 6490 Cable' Bind: default Filters: none CI: no Quirks: none
    2. May 13 20:28:58 vdr vdr: [24364] SATIP: Adding server '192.168.166.146|DVBS2-4|KATHREIN SatIP Server' Bind: default Filters: none CI: no Quirks: ForcePilot

    Wenn der EXIP 418 dem 414 auch in dieser Beziehung ähnlich ist, dann funktioniert die Erkennung nicht - denn laut Bedienungsanleitung meldet der EXIP418 hier "EXIP418". Siehe Sourcecode server.c Zeile 116 und folgende.


    Wenn Du aber den Satip-Server als plugin-parameter fest angibst dann muß alles stimmen. Das habe ich als Hilfe in der gentoo vdr-satip config abgelegt:


    Vielleicht hilft das?


    Grüsse

    Martin

    Ich würde mal zwei Dinge versuchen (ich habe noch keine Installation mit gcc-11):

    Code
    1. bool operator()(const cConflictCheckTimerObj* a, const cConflictCheckTimerObj* b) const {
    2. return (a->Compare(*b) < 0);
    3. }


    Hi seahawk,


    Sehr guter Hinweis, so lässt es sich compilen!!! Vielen Dank!


    Nun muß es nur noch funktionieren, werde die nächsten Tage testen und dann "upstream" reporten.


    Hier nochmal als Patch:



    Ich hab hier ein Problem mit epgsearch mit gcc-11 (gcc-9 und -10 compilen epgsearch ohne Probleme). Bei gcc-11 (vdr-1.4.7 ist gcc-11 übersetzt und installiert) gibt es eine Meldung, mit deren Kontext ich so gar nichts anfangen kann.

    Es führt bereits das

    conflictcheck.h:30 #include <set>
    zu einem Abbruch.


    Ich hab schon mal probiert davor ein#define DISABLE_TEMPLATES_COLLIDING_WITH_STL zu setzen, ohne Veränderung.


    Hat jemand eine Idee?


    Source ist die neueste aus https://projects.vdr-developer…vdr-plugin-epgsearch.git/
    Habe auch alle älteren Pakete durchprobiert, identischer Abbruch.

    Ja, das war mein erster Gedanke auch, aber ich kann nicht auf private Variablen vom VDR zugreifen, und in der öffentlichen Plugin Schnittstelle habe ich nichts gefunden.

    Hmm. Sieht ganz so aus als ob andere Plugins auch den svdrp-Port nochmals einstellbar machen - epgsearch tut das jedenfalls.

    Schade.