Beiträge von wirbel

    Die Variable header_size wäre am besten ein size_t statt uint32_t. reserve() darf gefahrlos bleiben bei deiner Änderung, das ist nur eine Optimierung, damit nicht Speicher in kleinen Häppchen angefordert wird.


    Zitat

    eine universelle (überladene) add()

    wäre immer eine Stolperstelle. z.B. wäre ein add(0) mehrdeutig, ist das nun int, uint32_t, int32_t, ..?

    Gegen std::string spricht eindeutig, dass der Inhalt der Daten mit voller Absicht auch Nullen '\0' enthält. Die sind normaler Teil der Datenpakete.

    std::string ist nun einmal eher ein Container für nullterminierte const char* und beendet dann auch Daten bei Nullen.

    std::string ist klasse, aber eben nicht hier. Falsche Anwendung, das sind keine strings, sondern bytes.


    std::stringstream stolpert sowohl über über die Nullen im Datenpaket, als auch über die Tatsache, dass erst nachträglich noch einige bytes am Anfang des Streams geändert werden müssen. Genauer, die Anzahl der Bytes, die dem Header folgen, als uint32_t.


    std::vector ist all dem gewachsen, linearer Speicher, die Anzahl member (hier bytes) ist in der standard lib verwaltet.

    Und beliebiger Zugriff nachträglich möglich auf bytes mitten drin..


    Was die Effizienz betrifft, laut Testprogramm in ./test ist der neue Code geringfügig(!) schneller als der alte. Zumindest mal nicht schlechter.


    Aber ja, das ist eine Diskussionsgrundlage. Nicht mehr.

    Ich habe hier mal einen Vorschlag abgelegt, wie man cResponsePacket überarbeiten könnte.

    Die grobe Idee ist


    - es gibt kein cResponsePacket::init* mehr, dafür aber dann drei Konstruktoren, je nach Art von response.

    init* taucht zur Zeit nach jedem neuen cResponsePacket auf, das macht keinen Sinn.


    - cResponsePacket::finalise() wird private member der Klasse, verschwindet im sonstigen code.

    finalise() wird zur Zeit jedesmal aufgerufen, bevor die fertigen Daten verwendet werden. Unmittelbar danach wird das Objekt zerstört.

    Warum dann nicht das einfach intern aufrufen.


    - die neue Version soll binär kompatibel die Daten übertragen - 1:1 gleiche Bytes.

    Das macht das debuggen wirklich einfacher.


    - die Speicherverwaltung übernimmt neu dann std::vector<uint8_t>, keine lokalen Baustellen mit Speicher mehr in der Klasse.


    - es gibt einen neuen Ordner /tests im sourcecode, der solche tiefen Eingriffe im Plugin isoliert testen lässt.


    - Ausführungsgeschwindigkeit etwa mit der alten Klasse vergleichbar. Siehe neuer Ordner tests, da gibt es dafür ein Programm.




    Commits · wirbel-at-vdr-portal/vdr-plugin-vnsiserver-crashes
    VDR plugin to handle XBMC clients. Contribute to wirbel-at-vdr-portal/vdr-plugin-vnsiserver-crashes development by creating an account on GitHub.
    github.com


    Aber wenn(!) man diese Klasse cResponsePacket überarbeiten würde, dann müsste man das Gegenstück, cRequestpacket ebenso anfassen müssen.


    Was denkt ihr? Weiter verfolgen oder verwerfen?

    Ist noch nicht am lebenden Objekt getestet.

    Ich habe jetzt folgenden Test durchgeführt


    a) vdr-2.6.6 mit epg2vdr und control gestartet

    b) vdr-2.6.6 mit epg2vdr und softhddevice gestartet


    In beiden Fällen stürzt vdr absolut zuverlässig ab, wenn ich im Haupmenü

    'EPG and Timer' und dann auf 'Timer' gehe.


    Der Fehler liegt eindeutig an epg2vdr. Auch der Stack trace sieht gleich aus.

    Die code Änderungen für satip und iptv wären gering.

    Mal abgesehen davon, dass eine Änderung in iptv rein zu bekommen schwierig wird.



    Aber der Impact des Patches als solches für VDR Infrastruktur sind nicht ohne..

    Oh, ich hatte das schon vergessen..


    Da muss ich nochmal nachhaken. Wieso wurde aus der 2 eine 1?


    snprintf darf bis zu (sizeof(buffer) - 1) bytes schreiben, da ein byte weg ist für (Code & st_Mask) >> 24 und der pointer nicht mehr bei buffer beginnt.

    Wenn kein byte mehr übrig war für das \0, ist der string nicht mehr terminiert. Das führt dann zu l < (sizeof(buffer) - 1). Kleiner.

    Das byte für die nachfolgende Zeile fehlt mit dem W oder E dann aber noch - mein Fehler, sorry.

    Also

    Code
    if (l < (sizeof(buffer) - 2) && l > 0) {

    alternativ deine korrekte Lösung.

    Code
         int l = snprintf(q, sizeof(buffer) - 2, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
         if (l > 0) {

    nobanzai:


    Das kam mir auch schon in den Sinn, ob das vllt. die gleiche Ursache hat.

    Beide Plugins sind schon ewig nicht mehr angefasst worden, weil sie eben zu 100% stabil liefen und es keine feature requests oder dringende Änderungen in VDR selbst gab. Neuer VDR -> neu bauen && fertig. Mit 2.6.6 gibt es zu beiden Plugins problem reports, die nicht verstanden sind.

    Die letzte echte Änderung in control war Apr 3, 2021.


    Vom Prinzip her müsste das genau wie hier mit Geduld, Testern und detaillierten Infos / cores debugged werden.

    Ich selbst nutze control regelmäßig beim debuggen meiner Plugins mit einem (fast) ungepatchten VDR, aber ich kann hier leider keine Abstürze provozieren.


    Kann ich auch mit vnsiserver nicht, aber nutze das Plugin eigentlich nicht selbst.

    Würde es dir etwas ausmachen eine Datei namens .gitignore in VDR aufzunehmen?

    Diese Textdatei enthält Infos, welche files nicht versioniert werden.

    Normalerweise macht diese Datei keinerlei Arbeit, aber erleichtert das Verfolgen von Änderungen immens.




    Ein sinnvolles Beispiel wäre das hier

    Ich würde vorschlagen UpdateNameSource() privat zu halten: