Posts by M-Reimer

    Mal eine Anmerkung zu dem Problem.


    Die Parameter sollten niemals als zusammenhängender String übergeben werden! Die Idee ist es, "argv" direkt als Array zu übergeben. Wenn du das machst kommt keine Shell zum Einsatz und die Parameter gehen direkt an das Zielprogramm. Genau genommen kannst du so das "argv" das im Zielprogramm ankommt direkt beeinflussen ohne das eine Shell dazwischen einen zusammenhängenden String teilen muss. Dann macht auch kein "&" mehr Probleme.


    Immer wenn man eine Befehlszeile selber als zusammenhängenden String baut und das an eine Shell übergibt resultiert das in einer Sicherheitslücke. Es ist zumindest sehr schwer alle denkbaren Fälle zu behandeln die eine Shell zur Ausführung von Programmcode bewegen könnte. Auch wenn die Lücke hier wohl kaum jemand ausnutzen würde.


    Hier ist eine Beispiel wie man Parameter richtig übergibt:

    http://openbook.rheinwerk-verl…xKap07009040002001F028177

    Ich hab zweimal probiert und zweimal ohne Probleme klonen können.


    Rein interessehalber hab ich mal mit "time" laufen lassen:


    Code
    1. $ time git clone http://git.tvdr.de/vdr.git
    2. Cloning into 'vdr'...
    3. Fetching objects: 30309, done.
    4. real 9m25,469s
    5. user 1m25,685s
    6. sys 0m37,920s


    Fast 10 Minuten für einmal komplett klonen. Bei Updates (die ja dann weniger umfassen) fällt das nicht so ins Gewicht aber beim ersten Runterladen lohnt es wirklich vom GitHub-Mirror zu ziehen und dann das "remote" auf den Server von Klaus umzustellen für zukünftige Updates:



    Zum Vergleich noch der Mirror von projects.vdr-developer.org:


    Code
    1. $ time git clone https://projects.vdr-developer.org/git/vdr.git
    2. Cloning into 'vdr'...
    3. Fetching objects: 30309, done.
    4. real 0m35,122s
    5. user 0m7,685s
    6. sys 0m1,401s

    Ich interpretiere den aktuellen Status eher so das 2.4.3 das nächste Release werden wird aber eben noch nicht veröffentlicht wurde.


    Wenn es ganz offiziell eine 2.4.3 gibt, dann wird Klaus die sicher auch wie gewohnt als Paket ablegen und wie gewohnt ankündigen.


    Edit: Sehe gerade das das Tag schon dran ist. Entweder das war ein Versehen oder es fehlt (aktuell) wirklich nur noch das Paket für ein offizielles Release.


    Edit2: Ich glaube ich komme mit den Releases jetzt komplett durcheinander. Ein 2.4.2 wurde ja so auch nie angekündigt. Da ist sowohl tvdr.de wie auch die abgelegten Tarballs nicht auf dem aktuellen Stand.


    Edit3: Man kann sich das hinbasteln. Ich könnte damit leben. Frage ist halt ob Klaus die Webseite und die abgelegten Pakete noch aktualisiert. Wenn nein würde ich das für vdr4arch auf dieses Schema umbauen:

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

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

    Ich habe meinen Test-VDR hier jetzt mehrere Tage mit 100ms (statt 1000ms) Wartezeit in cInterface::GetKey() laufen lassen. Damit wird die Hauptschleife zehnmal so oft durchlaufen als normal. Es kam aber zu keiner erkennbaren Steigerung des Speicherverbrauchs. An der Häufigkeit liegt es also wohl nicht.

    Damit wäre aber die Hauptschleife inklusive des entsprechenden Threads eigentlich ganz außen vor.


    Die Zunahme ist aber weitgehend linear. Fällt dir etwas anderes im VDR ein was mit einer gewissen Regelmäßigkeit läuft?


    Sehe ich das richtig das das hier: https://github.com/google/sanitizers/wiki/AddressSanitizer einfach nur einen Compiler-Parameter erfordert?


    Bezüglich des Freigebens nach Typwandlung: Speicher wird in aller Regel erstmal nur über seinen Zeiger freigegeben:

    https://linux.die.net/man/3/free


    Ein "delete" ist auch nicht viel anders als ein "free" das vorher die Destruktoren aufruft.


    Unter Umständen kann einem hier natürlich die eine oder andere Eigenart von C++ reinfunken. "Virtuelle Desktruktoren" wurden ja schon genannt.

    Ich habe EPG-Scan schonmal aus. Trotzdem würde natürlich der eine Transponder den ich tunen würde EPG produzieren.


    Ich gehe mal davon aus, dass einfach Sat-Kabel abziehen keine Lösung wäre weil der VDR dann in "Emergency-Exit" geht?

    Was den Speicherverbrauch erhöht ist ja allgemein noch im dunklen. Ich habe z.B. ein System ganz ohne Ausgabe. Reines VDR-Backend. Ich werde den morgen bevor ich arbeiten gehe einfach mal booten und einen Sat-Radio-Sender laufen lassen. Dann vergleiche ich mal Speicherverbrauch vorher und nachher. Einfach aus Interesse ob der Speicherverbrauch bei einem System ohne Ausgabe auch stetig steigt.

    Ich hab mal drauf geschaut aber mir sagt das nichts. Ist vielleicht der "threshold" zu niedrig und VDR hält Speicherblöcke einfach länger?


    Aber selbst wenn: Ich vermisse eine klare Ansage wie "possible memory leak". So wie das Log aussieht müsste man es erst mit zusätzlichen Tools irgendwie auswerten.


    Dazu kommt das du echt viele Plugins geladen hast.


    Um das Leak im VDR selbst zu finden müsste ich vielleicht doch einmal meine Kiste länger laufen lassen. Ich hab da kaum Plugins drauf. Allerdings müsste man dann erstmal ein Tool finden das taugt. Bisher war ich von allem zum Thema enttäuscht. Valgrind bringt auch kaum was. Dazu kommt das Valgrind jedes Programm das komplexer als "Hello World" ist so stark langsamer macht das es unbenutzbar wird.


    Edit: https://github.com/WuBingzheng/libleak/issues/13

    Wenn du einen Test mit libleak machst, dann poste mal die Ausgabe.


    Wenn ich das Prinzip richtig verstehe, dann loggt libleak die malloc and free. Und da C++ auch nur oben auf die glibc aufsetzt resultiert ein "new" sicher auch irgendwie in einem "malloc".


    Wäre praktisch wenn das jemand testen könnte der bereits einen VDR dauerhaft laufen hat. Wenn sich hier niemand findet, dann würde ich halt mal meinen HTPC eine Weile durchlaufen lassen.

    Ein Versuch ist letztlich nie verkehrt. Schaut beides gut aus. Kenne ich beides nicht. Wäre aber für beide interessiert wie so deine Erfahrung damit ist.


    Wegen des 100MB-Problems muss ich dann wohl selber mal schauen. So grob überschlagen ist das deutlich weniger als TVHeadend bei mir "gefressen" hat und vielleicht habe ich ja auch das Glück das das Problem gar nicht auftritt wenn der VDR keine Ausgabe macht. Bei mir soll der eigentlich nämlich tatsächlich 24/7 als reiner Server laufen. Wenn es aber "nur" 100MB pro Woche sind ist durchaus möglich das in der Zwischenzeit sowieso geplante Reboots fällig werden wegen Sicherheitsupdates.

    Etwas ähnliches hatte ich halt auch mit tvheadend. 100 MB pro Woche ist gefühlsmäßig sicher erstmal nicht viel aber wenn man sowas auf einem Raspberry fahren will dann sind 4GB RAM halt in endlicher Zeit voll. Man kann den VDR über systemd bei Überschreiten einer Speichergrenze hart restarten lassen, aber dann läuft man Gefahr eine Aufnahme zu killen.


    Ärgerlich für mich vor allem weil das eigentlich mein Hauptgrund war um von tvheadend auf VDR zu wechseln. Ich möchte einfach einen kleinen Mini-Server der wenig Strom braucht und einfach TV-Programm ins Haus-LAN streamt. Mit tvheadend wird das nix, denn da tut sich deutlich weniger wie aktuell im Bereich VDR.


    Gibt es nicht Hilfstools die "verlorenen" Speicher erkennen und die Stelle wo der verloren gegangen ist melden?


    Edit: https://www.cprogramming.com/debugging/valgrind.html


    Ich erinnere mich aber das für irgendwas schonmal genutzt zu haben und der Erfolg war begrenzt.

    Das hat überhaupt nichts mit "Evangelisierung" sondern mit dem Aufzeigen von durchaus nicht zu vernachlässigenden Alternativen zu tun.


    "VDR" ist auch noch "VDR" wenn es im Backend läuft und als extrem stabiler Aufzeichnungsdienst verwendet wird.


    Mit dem Beharren auf "Geht mit VDR nicht" wird man auf Dauer dem Projekt "VDR" zumindest im Bezug auf "Massentauglichkeit" keinen Gefallen tun.

    Ob sich das lohnt ist eine Frage auf die du von 10 Leuten 10 verschiedene Antworten bekommen wirst.


    Soviel kann ich nämlich schonmal vorweg nehmen: Für mich würde es sich definitiv nicht lohnen.


    Das letzte Mal das ich HD+ zu Gesicht bekommen habe, war das Material Full-HD. In der Anfangszeit wurde viel skaliert aber das hat sich mittlerweile gegeben.


    Allerdings bekommt man eben auch Werbung in Full-HD serviert.


    Dann doch lieber in einen Streaming-Dienst investieren wo man für sein Geld dann wenigstens werbefreie Unterhaltung bekommt.

    Das VDR-Frontend ist für reine "Nur TV-Nutzer" sicher einfacher. Man kann sich da im Kodi viel hinkonfigurieren aber wer ganz einfach und Schlicht braucht weil er eben eigentlich nur einen Receiver braucht, der ist mit reinem VDR sicher besser bedient. Viele der "rein VDR-Nutzer" würden aber mit halbwegs aktuellem Fernseher auch mit einer einfachen USB-Platte direkt am Fernseher auskommen und könnten sich den HTPC dann auch sparen.


    Es gibt zumindest einen Kodi-Skin das extra auf die reine TV-Nutzung abzielt und dadurch potentiell auch viele der Nachteile von Kodi im Vergleich zum VDR wieder wettmacht. Ist allerdings nie so richtig hier im VDR-Portal angekommen:


    https://www.kodinerds.net/index.php/Thread/66003-Unfussy/


    Ja, der geht natürlich auch mit VDR im Backend weil Kodi da erstmal keinen Unterschied macht. Mit meinem graphlcd-Addon für Kodi hatte ich bei meinen Tests mit tvheadend auch die vom VDR bekannte Graphlcd-Darstellung. Nur eben mit tvheadend.


    Kodi hat im Gegensatz zum VDR-Frontend den enormen Vorteil viel unter eine Oberfläche zu packen. Jede Bemühung auch nur ansatzweise mit dem VDR-Frontend da hinzukommen ist eigentlich verlorene Liebesmüh. Alle Mediatheken und mittlerweile auch diverse Bezahldienste. Alles aus einem Guss auf einer Oberfläche. Mit reinem VDR hat mein HTPC so langsam zu verstauben angefangen. Mit Kodi als einziges Frontend wird der aktiver genutzt als je zuvor. Kurz eine TV-Aufnahme, dann ein paar Videos bei YouTube und zuletzt noch ein paar Folgen "Lost" auf Amazon Prime: Mit Kodi kein Thema.