Posts by M-Reimer

    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.

    Den diff sollten _vorher_ viele testen, bevor du das in deine Version übernimmst,

    damit das wirklich niemand mehr anfassen muss. Ich wäre ungern daran Schuld, wenn das noch mal aufploppt.

    Ich hab jetzt auch mal einen GCC 11 "Full Run" durchgefahren um zu sehen was noch baut.


    Ich verwende den zuletzt von kls vorgeschlagenen Patch (kommt ja ursprünglich von wirbel ) an VDR 2.4.7 angepasst:


    https://github.com/VDR4Arch/vd…r-fix-stl-conflicts.patch


    Ich hatte Probleme mit "vdr-filebrowser". War aber ein kleiner Fix, weshalb ich das direkt upstream commited habe inklusive neue Version:

    https://github.com/vdr-projects/vdr-plugin-filebrowser


    "vdr-mp3" musste ich deaktivieren. Baut nicht mehr. Wenn sich jemand berufen fühlt würde ich einen Pull-Request gerne übernehmen:

    https://github.com/vdr-projects/vdr-plugin-mp3/issues/2

    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.

    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.

    M-Reimer Was ist so schwer daran, wenn Plugins, die dieses Problem haben (was ja beileibe nicht alle sind), einfach vor dem Includieren jeglicher VDR-Header-Files '#define DISABLE_TEMPLATES_COLLIDING_WITH_STL' machen? Gibt es einen Fall, wo das nicht hilft?

    Musst letztlich du wissen wie "angenehm" Plugin-Entwicklung sein soll. Ist halt schade das in "tools.h" auch einiges drin ist, das für Plugins durchaus praktisch sein kann. Und wie hier mittlerweile gezeigt wurde braucht es eben kein "using namespace std" um das Problem zu triggern. Man kann da durchaus auch unerwartet reinrennen und dann erstmal suchen wer da genau was vergurkt hat.

    kls könntest du eventuell einfach ein zweites "tools.h" anlegen und da Dinge reinpacken die wirklich nur für den internen Gebrauch vom VDR sind? Dann würde man sich einfach festlegen, dass Plugins diesen "speziellen STL-inkompatiblen Header" nicht includen?

    Informatik an der Hochschule hat nicht immer den passenden Bezug zur Realität - nicht böse gemeint...

    Trotzdem kann ich durchaus nachvollziehen das man sich alles aus "std" in den globalen Namespace holt. Für mich ist das irgendwie "fester Bestandteil der Sprache C++" und wenn man diese Typen viel nutzt, dann wird das ständige "std::" irgendwann lästig.


    Und ja, ich hab auch "using namespace std" in ".h"-Files. Allerdings nur in ".h"-Files die nicht "Projektübergreifend" genutzt werden. Bei Libraries sehe ich ein das das da nichts verloren hat aber wenn ich ein abgeschlossenes Projekt erstelle und in meinen Header-Files die Klassen deklariere, dann will ich in den Attributen auch nicht ständig das "std::" haben.


    Da der vdr-Code komplett ohne Namespaces ist, ist es dann immer so eine Sache, wenn man durch ein using den globalen Namespace mit Dingen füllt..

    Könnte man natürlich jetzt auch umdrehen und fragen: Warum hat der VDR nicht über den gesamten Code einen eigenen Namespace "vdr". Wenn das konsequent überall eingebaut ist wäre das Problem aus der Welt und da der VDR komplett in seinem Namespace läuft wäre auch am VDR-eigenen Code gar nicht so viel zu ändern. Ja, ich weiß:

    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.