Posts by durchflieger

  • VDR für OE-Linux 5.0 aka OpenATV aka Enigma STB's

    Hallo,


    nachdem in meiner betagten x86 basierten VDR-Server-Box die DVB-Karten wegen Altersschwäche aufgeben, der Markt für DVB-Steckarten offenbar zum erliegen gekommen ist, Lösungen mit SAT/IP Servern auch nicht gerade preiswert sind, habe ich mal eine Portierung des VDR für Open-Embedded-Linux gemacht.

    Das ist die Linux-Variante die vielen STB-Boxen mit dem Enigma-Frontend zugrunde liegt.


    Ich habe mir die Gigablue UHD UE 4K zugelegt die als Besonderheit über einen FBC-Tuner verfügt der in Verbindung mit einer Unicable-LNB 8 virtuelle Tuner dem VDR bereitstellt -> Timerkonflikte ade :P


    Die Gigablue hat serienmäßig Platz für eine SATA 2" Platte wobei für diese nur 5V bereitgestellt werden was bei der Auswahl berücksichtigt werden sollte.

    Ins Gehäuse passt aber auch eine 3,5" HD mit selbst konstruierter 3d gedruckter Halterung und Anschlusskabeln.


    Der VDR kann in der Box derzeit nur als Server genutzt werden da kein passendes Ausgabeplugin verfügbar ist.

    Als weiteres Manko ist das fehlende Wake-On-Lan (WOL) zu nennen.


    Obwohl die verbaute ARM CPU nur 2 Kerne hat und nur 1GB Hauptspeicher verbaut sind läuft der VDR erstaunlich rund.

    Es reicht sogar noch für eine Samba, NFS, FHEM und Nextcloud-Server-Instanz womit die Box bei mir alle 24x7 Aufgaben im Haus übernimmt.

    Backups erfolgen auf eine per USB3 angeschlossene externe HD.

    Das ganze lüfterlos und mit erfreulich niederigen Stromverbrauch.



    Obwohl unter OE-Linux die Tuner die V4L-Schnittstelle bereitstellen waren einige Anpassungen am DVB-Device-Code des VDR notwendig.

    Prinzipiell müsste der VDR auch auf andere STB's auf denen OE-Linux 5.0 läuft nutzbar sein.


    VDR-Plugins sind streamdev, live, markad-ng, epgsearch, svdrposd, svdrservice, wirbelscan, control, devstatus, dummydevice portiert.

    Auch vdr-plugin-softhddevice-drm ist portiert aber auf der Gigablue nicht nutzbar.


    Die Sourcen zur Portierung sind für OE-Linux typisch als Layer zum selber compilieren hier verfügbar: https://github.com/durchflieger/meta-vdr


    Fertig installierbare Pakete für die Gigablue UHD UE 4K mit installiertem OpenATV 7.0 gibts hier: https://github.com/durchflieger/vdr-oe-5.0-repo


    Viel Spass beim ausprobieren.

  • [markad] überarbeiteter Decoder

    kfb77

    Es hat sich aber leider erst nach den damaligen Tests im praktischen Betrieb gezeigt dass die damals gefundene Lösungen nicht wirklich die Ursachen

    der Probleme behoben haben.

    Tatsächlich sind noch memory leaks im code vorhanden die mit dem von mir bereitgestellten patch beseitigt werden.

    Wäre schön wenn du den nocht integrierst.

  • [markad] überarbeiteter Decoder

    Der Patch ist aber offenbar nicht im 3.0.26 ?

  • [markad] überarbeiteter Decoder

    Hallo,


    sieht so aus als ob ich bei dem Problem mit dem "push_back" auf meiner Platform doch richtig lag:

    Quote from durchflieger

    Mit dem neusten Git Stand selbes Ergebnis.

    Ich denke das Problem ist weder in der class vector noch im Compiler zu suchen.

    Beides sind zu fundamentale Funktionen.

    Sieht für mich eher danach aus, das der heap vorher corrupted wird und es nur den vector bzw. die recordingIndex reference trifft.

    Gibt es kein Analysetool mit dem man solche Fehler sucht?


    Ich hatte hier auch mit den letzten Fixes immer wieder noch Aufnahmen bei denen das markad crashed allerdings an anderer Stelle.

    Die Probleme resultieren aus nicht ganz sauberer Parameterversorgung/vorbereitung für die Funktionen getline und sscanf was dann

    zu korrupten Hauptspeicher führt.

    Im Anhang ist ein Patch der das fixed.

    Jetzt funktioniert auch das push_back bei mir ohne das man vorher ein reserve macht.

  • [markad] überarbeiteter Decoder

    Quote from kfb77

    Deine Argumente überzeugen mich. Aber zum Start mal 1000 Elemente zu allokieren und dann doch wieder einzeln ist auch nur eine halbe Lösung.

    Ich schaue mal, ob ich da für die nächste Version nochmals was optimieren kann. Ideal wäre, wenn ich vor dem ersten Element abschätzen könnte, wie viele ich brauche um dann gleich alle allokieren. Wenn nicht, dann in z.B. 1000er Blöcken.

    Nein, bei deinem Code würde er 1 x 1000 und dann 4000 x 1 Element allokieren. Und genau das gefällt mir nicht.

    Ja da hast du vermutlich Recht das push_back weiterhin nur für das aktuelle Element neuen Speicher anfordert.

    Ich hab den Test mal mit 10000 reservierten Elementen am Anfang durchgeführt mit dem Ergebnis das die Laufzeit wieder schlechter wird! :wow

    Auf meinen System hier zu messen scheint keine gute Idee zu sein.

  • [markad] überarbeiteter Decoder

    Quote from kfb77

    IndexVector: Das wundert mich, dass das geht, weil die allokiert ja nur die ersten 1000 Elemente vor. Und damit sparst du dann die 2% Laufzeit.

    Das Risiko ist mir hier zu hoch, dass es mit irgendeinem anderen Video wieder crashed. Was passiert nach dem 1000sten Element ? Gibt es einen nächsten Wert, der wieder Probleme macht ? Das weiß keiner. Die beste Lösung, die stdlibs deiner Build Umgebung passend zum Compiler zu bekommen.


    ptsRing: Der Vector hat eine konstante Größe, da macht das Sinn.

    Mein Testvideo benötigt ja über 5000 Einträge.

    Das push_back wird dabei mindestens 5 mal reallokieren müssen was offenbar nicht zu einem crash führt.

    Bezüglich der wirklichen Ursache auf meinen System stochern wir deshalb immer noch im Nebel.

    Unabhängig davon macht das reserve() am Anfang gerade auf indexVector Sinn weil viele Einträge und nur wenige auf ptsRing.

    Wie cppreference.com zum vector schreibt:


    Code
    Notes

Correctly using reserve() can prevent unnecessary reallocations, but inappropriate uses of reserve() (for instance, calling it before every push_back() call) may actually increase the number of reallocations (by causing the capacity to grow linearly rather than exponentially) and result in increased computational complexity and decreased performance. For example, a function that receives an arbitrary vector by reference and appends elements to it should usually not call reserve() on the vector, since it does not know of the vector's usage characteristics.

    folgt dein Workaround dieser Empfehlung nicht.


    Aber du kannst es auch so lassen. Die 2% tuen nicht weh.

    Vielen Dank noch mal für deine Unterstützung!

  • [markad] überarbeiteter Decoder

    Sorry hab beim letzten Hochladen eine alte Log-Datei erwischt.

    Jetzt greift das Directive.

    Trotzdem schon erstaunlich der Fehler beim push_back. Da fragt man sich warum überhaupt ein Programm auf der Box richtig läuft. :/

    Der derzeitige Workaround ist vermutlich nicht sehr effizient. Schaut man sich das vorherige Log mal an wo noch mehr debug output kam

    so wird da vermutlich bei dem Teststream über 5000 mal der vector reallokiert.

  • [markad] überarbeiteter Decoder

    Puh da jetzt die Toolchain bezüglich gcc oder libs zu ändern feht mir auch das know how.

    Ob die warnings wirklich mit unserem crash in Bezug stehen ist ja auch nicht klar.

    Gibts denn keine Tools die wir hier bezüglich detection of heap corruption an den start bringen können?

    Der Fehler wird nicht im gcc oder class vector stecken. Viel zu fundamental. Un dein Code ist hier auch sauber programmiert.

    Da geht vorher was in die Hose.