Posts by M-Reimer

    Wäre es denn wirklich so schlimm das DEFINE als Option drin zu lassen?


    Ja, über "using namespace std" scheiden sich die Geister aber zumindest ich hab das genau so im Studium vermittelt bekommen. Beim "normalen" C++-Programmieren braucht man die "std"-Dinger halt ständig und immer ein "std::" davor schreiben kann man machen, muss man aber nicht.


    Ich bin und werde zwar nicht "hardcore Plugin-Entwickler", aber ich fände es trotzdem nicht verkehrt die Option, auch in einem Plugin "using namespace std" machen zu können, zu erhalten.

    md_berlin Sie erfüllen den gleichen Zweck. Selbst wenn sie nicht exakt gleich sind sollten sie sich schon sehr ähneln.


    Ich hab jetzt einfach mal mitgenommen das das im VDR eben schon immer so war und dann "never change a running system".

    Wäre es mein Projekt würde ich es als Herausforderung sehen mal zu schauen was C++ mittlerweile "nativ" bietet und wie viel eigener Code damit raus könnte. Dafür spricht nicht nur das Argument, dass die "nativ" verfügbaren Funktionen über viele Projekte genutzt werden, und so Optimierungen/Bugfixes schneller umgesetzt werden, sondern auch der "Wiedererkennungswert". Ein neuer "Beitragender" findet sich, wenn er C++ kann und einen Standardtypen sieht, einfach direkt zurecht.


    Aber ist letztlich die Entscheidung von kls was ihm wichtiger ist. Mir kann es weitgehend egal sein weil ich auch in Zukunft nicht im größeren Stil Plugins entwickeln will.

    Warum nichtmal wenigstens einen Satz zur Frage warum der VDR eigene Spezial-Implementierungen hat? Und wenn es "gefallen mir besser" ist, dann schreib halt einfach das.


    Ich will ja nicht sagen das ignorieren sehr unhöflich ist, aber ich finde ignorieren eigentlich schon sehr unhöflich. :|

    Die Frage ist aber doch warum immer wieder der Kampf ausgefochten wird irgendwie die "Spezial-Versionen" im VDR zu "verteidigen". Warum nicht entsorgen und die "Standard-Versionen" nutzen? Ich frage mich ob das nicht sogar ein einfacher GCC11-Fix wäre. Passendes Include oben rein und die Defines so verbiegen das sie direkt auf std::max und std::min zeigen.


    Wegen dem "woher kommen die Defines" würde ich einfach mal in den Raum stellen das eine der vielen anderen Includes vielleicht seinerseits bei GCC 11 auf ein STL-Feature aufsetzen, die entsprechende ".h" inkludiert und so das Define global reinziehen. Ist halt irgendwo in Kampf gegen die Programmiersprache wenn man Standardfeatures mit der Brechstange nicht haben will.

    Eine gute Frage.

    Viele internals von VDR gibt es mittlerweile sehr gut geprüft und fertig in der STL mit ebenso guter Doku. Man könnte einige Dinge locker ersetzen cVector, cString..

    Mein Informatik-Dozent an der Hochschule hat immer darauf bestanden das man, bevor man auch nur zu Programmieren anfängt, immer erst schaut was es an Libraries fertig gibt. Je mehr eine "Basis-Library" nutzen um so mehr Leute testen in unterschiedlichen Konstellationen und finden so potentielle Fehler.


    Fehler sind bei sowas einfachem wie "min" oder "max" wohl eher unwahrscheinlich, aber ich frage mich schon warum man hier noch viele Verrenkungen machen sollte nur um unbedingt die eigene "Spezial-Implementierung" zu behalten. Wenn es einen wichtigen Grund gibt für die eigenen Implementierungen, dann würde mich einfach interessieren was das für Gründe sind. Vorstellen könnte ich mir das der VDR erstmals zu einer Zeit programmiert wurde, wo es die "stdlib"-Implementierungen noch nicht gab. Und das hat sich möglicherweise bis heute gezogen. Aber mittlerweile dürfte wirklich niemand mehr ein so altes System verwenden, das er keine "stdlib" nutzen kann.


    Wäre halt schon etwas schade wenn es um ein NIH Problem handelt.

    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.

    Wurde eigentlich irgendwann schonmal erklärt warum der VDR nicht einfach stdlib nutzt? Wenn ich das verpasst habe wäre ich auch für einen Link dankbar.


    Muss ja irgendeinen Grund geben warum man "Standard-Funktionen" nochmal "neu erfindet". Sind die VDR-Versionen performanter? Kleiner? Können die irgendwas besser? Ist ja nicht das erste mal das es solche Probleme gibt und es wird auch nicht das letzte mal bleiben.

    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.

    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.

    Das mit der Config-Datei keineswegs ein spezielles Setup sondern der VDR liest die selber. Sollte also eigentlich heute bei jeder Distribution so gelöst sein. Eben weil es "VDR Standard" ist. Man kann prüfen ob die Option tatsächlich beim VDR ankommt wenn man direkt auf der Maschine "vdr --showargs" aufruft.

    Für mich passt das so. Wie erwartet sind die Commit-IDs gleich geblieben. Ist also faktisch das gleiche GIT bis eben auf die Tags.


    Für "offizielle Release-Downloads" halte ich den Link auf deiner "Downloads"-Seite noch für etwas optimierungsfähig. Wäre schon schöner da sowas wie


    http://git.tvdr.de/?p=test.git…h=refs/tags/2.4.7;sf=tbz2


    zu haben. Gibt dann ein "vdr-2.4.7.tar.bz2" das runtergeladen wird und auch das Wurzelverzeichnis heißt "vdr-2.4.7". Würde aber erfordern das du die Ausgabe von "git tag" vorparst um da die letzte "Release-Version" manuell reinzubauen. Also das letzte Tag das an der "mittleren Stelle" eine gerade Zahl hat.

    Ich halte mich erstmal bisschen zurück bevor dann das Gemecker groß ist. Mein Problem hab ich erstmal gelöst mit dem Befehl von oben zum Umformatieren. Nur soviel: VDR dürfte aktuell das einzige Projekt sein das seine Releases so taggt.


    Ist auch ein bisschen "Kosmetik". Aktuell würden deine ".tar.bz2", die als Snapshot vom GIT geladen werden, als "Wurzelverzeichnis" ein Verzeichnis mit dem Namen "vdr-V20407" haben. Wäre der Tag "2.4.7", dann wäre das Verzeichnis "vdr-2.4.7" und würde in etwa dem entsprechen was viele auch beim "manuellen Packen eines Releases" machen würden.


    Ich würde auch das "v" weglassen. Ja, sieht man öfter. Ich frage mich aber selber wer das zuerst gemacht hat und warum das so häufig kopiert wurde.


    Am besten genau so taggen wie es der VDR auch dem Nutzer anzeigt.


    Eine Version wird durch ein "annotated tag" gekennzeichnet (git -a X.Y.Z -m 'Version X.Y.Z'). Dann bekommt man die, wenn man


    Code
    1. git config --global push.followTags true


    gemacht hat auch direkt mit "git push" mit auf den Server ohne extra ein "git push --tags" zu brauchen.


    "Nicht annotated" kann man dann diverse "Markierungen" machen. Die bleiben dann auch erstmal lokal und wandern nicht direkt auf den Server.


    Und was das "neu runterladen" angeht: Das Tag hängt "extern" am Commit. Ein Commit kann sogar mehrfach getaggt werden. Solange sich also nur die Tags ändern würde sich am Repo selbst nichts verändern. Auch alle Commit-IDs müssten gleich bleiben.

    Sieht gut aus. Danke. Das mit deinen Tags der Form "V20407" war etwas lästig. "Die Regel" ist eigentlich da einfach so die Versionsnummer reinzubauen.


    Wenn noch jemand den Fall hat das er eine Versionsnummer kennt und das Tag braucht:


    Code
    1. _tag="V"$(echo $pkgver | sed -r -e ':r;s/(\.)([0-9])(\.|$)/\10\2\3/g;tr' -e 's/\.//g')

    Nachtrag zur Download-URL. Die hier ist besser:


    http://git.tvdr.de/?p=vdr.git;…h=refs/tags/V20407;sf=tgz


    So gibt es keine abgekürzten Commit-IDs mit im Verzeichnisnamen im TAR-Archiv (zumindest für Arch leichter das dann im PKGBUILD auszupacken).


    Allerdings musste ich dafür im Sourcecode von "gitweb" suchen um das zu finden. Schade das es solche Links nicht direkt in gitweb gibt. Konnte auch keine Config-Option dazu finden.


    kls kannst du noch "tbz2" als snapshot-Format zulassen?


    Für Arch kümmere ich mich dann am Wochenende darum. Das wird diesmal aufwändiger weil projects.vdr-developer.org teilweise tot ist. Was ich via GIT holen kann bleibt erstmal auf projects.vdr-developer.org. Was nur über die "Files"-Sektion über projects.vdr-developer.org veröffentlicht wurde (kein GIT) ziehe ich auf vdr-projects.github.org um und fummle die Releases dafür alle bei "archive.org" raus. Würde mich dann sehr freuen wenn das dort wieder jemand übernehmen würde. Wenn Hilfe zu GIT benötigt wird helfe ich gerne aus.


    Nachtrag: kls wäre es möglich das du für die "tvdr.de"-Download-Sektion da was skriptest das Links wie die obigen dort automatisch darstellt? Dann wäre es tatsächlich alles über GIT, man müsste sich die Download-Links aber nicht selber basteln.