Posts by wirbel

    OK, ich hoffe immer noch, daß ich meine TBS 6205 zum laufen kriege, aber das sind zumindet schon einmal Anhaltspunkte.


    Bestünde rein theoretisch die Möglichkeit, den Treiber aus meiner funktionierenden 16.04-Installation "herauszuoperieren" und in der 22.04-Installationn einzubauen? Was müßte da wohin kopiert werden?

    Rein theoretisch schon, wenn du den alten Kernel zusammen mit seiner System.map, die alten Module und die alte Firmware verwendest. Die alten Module werden nicht mit dem neueren Kernel funktionieren.


    Aber es gäbe das Restrisiko, dass sich Schnittstellen zu glibc zwischen dem alten Kernel und dem Kernel gegen den die glibc des neueren ubuntu compiliert wurde geändert haben.

    So klappt das auch bei mir.


    Bei remote habe ich immer CTRL +, dann kommt der telnet prompt, und dann quit gemacht.

    So wie es ausschaut, macht telnet selbst dann das tcp socket zu und auf server Seite (also im Plugin) gibt es keine chance mehr ein EC_SHOWCURSOR, also "\033[?25h" zurück an den telnet client in der shell/putty zu senden.

    Hallo Zabrimus und seahawk1986, passt diese Änderung für euch?


    GitHub - wirbel-at-vdr-portal/vdr-plugin-control: This Plugin shows [VDR's](www.tvdr.de) menu via telnet session on port 2002. You may also use ssh/putty to the VDR computer, and use telnet locally. Dont forget to configure svdrphosts.conf.
    This Plugin shows [VDR's](www.tvdr.de) menu via telnet session on port 2002. You may also use ssh/putty to the VDR computer, and use telnet locally. Dont…
    github.com


    Ich konnte keine Probleme damit feststellen, und würde das gerne als 1.0.2 taggen, sobald ihr kurz angetestet habt.

    Btw wenn ich control per telnet aus dem cli aufrufe, ist nach dem Beenden von telnet der Cursor weg, den muss ich mit reset wieder herstellen. Bei remote gibt es das Problem nicht.

    Wie genau machst du das, bzw. wie kann man das reproduzieren?

    xterm und dann ein telnet tippen oder wie?


    Beim starten wird der cursor deaktiviert, aber beim Beenden sollte der eigentlich wieder hergestellt werden mit

    vdr-plugin-control/telnet.c at d43e31910720f3342c6ad01d4dda9146c3a69d5c · wirbel-at-vdr-portal/vdr-plugin-control
    This Plugin shows [VDR's](www.tvdr.de) menu via telnet session on port 2002. You may also use ssh/putty to the VDR computer, and use telnet locally. Dont…
    github.com

    Soweit ich noch weiß, hat man sich durch den Konstruktor

    Code
    cCtrlKeyboard::cCtrlKeyboard(const char* name) : cKbdRemote()

    noch einen anderen Thread eingefangen

    Code
    cKbdRemote::cKbdRemote(void)
    :cRemote("KBD")
    ,cThread("KBD remote control")

    der dann in telnet action parallel lief und der für die Last verantwortlich war, die unmittelbar bei einem reinen telnet-Connect auftrat und auch nicht mehr beendet wurde.

    Ich schau mir das auf jeden Fall an.

    Der Patch müsste genauer angeschaut werden. Ich kenne das beschriebene Problem nicht und wusste nichts davon.


    Wenn damit ein Problem gelöst wird und nichts anderes kaputt geht, dann würde ich das übernehmen. Aber erst nach dem Urlaub

    Laut google könnte sein, dass DNS traffic zu externen Servern auf Port 53 udp und tcp benötigt wird für libunbound, aber nicht offen ist.

    Die channels.conf ist IMHO unabhängig vom System.

    Vollkommen egal, mit welchem tool du die erstellt hast - solange die Datei korrekt ist.




    Du möchtest sicher nach Firmware files und Kernel Treibern suchen. Beide müssen immer zusammen passen.


    Oder auch einfacher

    Empfang == (Kernel modul passend zur Firmware Version)


    Bei DVB hardware ist immer das Dreigestirn aus

    - Firmware

    - Treiber passend zur Firmware

    - Software passend zu Firmware und Treiber


    der Key zum Erfolg.

    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.


    Quote

    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.