Can you check this fork:
https://github.com/mdre77/vdr-plugin-vnsiserver
Maybe it already contains your proposed fixes?
https://github.com/vdr-projects/vdr-plugin-vnsiserver ist ein Fork von eben diesem Repo und VNSIServer wurde dann als "Community Projekt" weiter entwickelt.
Das von dir verlinkte Repo hatte vor 6 Jahren den letzten Commit.
Kann da einer der "C++ Wissenden" mal drüber schauen? Wenn noch jemand sein OK gibt würde ich damit ein neues Release bauen.
Ich hab mal den Patch von seahawk1986 ins Repo nachgezogen, die History aktualisiert und Version 2.0.0 getaggt.
Ab dieser Version läuft das Radio-Plugin dann als "Community maintained" Plugin. Fixes gerne als Pull-Request. Mittlerweile gibt es ja auch ein Team von Maintainern die sich das dann anschauen können.
Jedem beliebigen Programm etwas zu "preloaden" halte ich generell für problematisch. Gerade bei DVB Treibern. Es gibt auf einem typischen Linux System wohl maximal ein oder zwei Programme die tatsächlich auf DVB zugreifen müssen.
Jeder, der auch unter Linux spielt, sollte zudem Anti-Cheat zumindest im Hinterkopf behalten. Solche Systeme achten durchaus genau darauf was man dem "überwachten" Prozess so an Libraries unterschieben will.
Lösung 3: Warum machst du dich überhaupt von Herstellerclouds abhängig? Setze auf einem Raspberry einen Home Assistant Server auf.
Wenn Du die Chip-Treiber meinst, wir haben Verträge mit unseren Zulieferern, und das von Anfang an. Dies betrifft unter anderem Treiber der ICs und Firmware.
Firmware ist egal. Die lädt man üblicherweise einmal ins Device und gut. Mich hätte tatsächlich interessiert wie das Protokoll USB Host zu Device funktioniert. Warum kann das nicht offen gelegt werden?
Beantwortet jetzt die Frage nicht warum man das Protokoll jetzt unbedingt geheim halten muss und in einer Closed-Source-Applikation versteckt, aber gut. Für eine Ankopplung an eine Closed-Source-Library werde ich persönlich auf jeden Fall keine Freizeit aufwenden. Können andere natürlich anders sehen.
Sicher hat beides sein Für und Wieder. "Treiber ist im Kernel" ist auch keine Garantie dafür, dass es nie Probleme geben wird. Ist ja nicht so das es da auch schon Probleme gegeben hätte und die Treiber von Digital Devices sind Open Source aber trotzdem findet sich bis heute keiner der den Aufwand (sowohl von der Programmierung als auch mit der dann folgenden Abstimmung für die Übernahme) auf sich nehmen will, bzw. diejenigen, die es begonnen hatten, haben nach einer Zeit das Handtuch geworfen.
Was ich aber ausgesprochen schade finde, ist das die Schnittstelle zum Tuner, also das Protokoll das zum USB-Gerät gesprochen wird, nicht offengelegt ist. Das würde meiner Meinung nach alle Optionen eröffnen was Treibermodelle angeht. Ich persönlich bin mir auch nicht sicher ob ich einen Treiber unbedingt im Kernel haben wollen würde, aber ich fände es durchaus interessant mal zu probieren einen Usermode-Treiber zu basteln der das ganze über CUSE abhandelt und so ohne nötiges "LD_PRELOAD" die Devices anlegt.
Ich weiß nicht warum dieser Part auch geheim gehalten werden muss. Eventuell wäre es je möglich den Treiber aufzuteilen in eine (beim offiziellen Treiber dann statisch gelinkte) Library für die USB-Kommunikation und "Rest". Diese "Treiber-Library" dann unter was weiß ich für eine offene Lizenz stellen damit jeder, der sich mit alternativen Treibermodellen befassen will, einfach dagegen linken kann.
Ich kann das nur aus Sicht eines Gamers bewerten, der diesen Trend gerade in Indie-Spielen immer wieder sieht. Und ich dachte mir schon soooo oft: Hättet ihr's halt lieber in Englisch gelassen, denn die deutsche Übersetzung ist der totale Abschuss.
Ich glaube mit halbwegs ordentlichem Englisch erreicht man die Meisten bereits. Und eine automatische Übersetzung wirkt immer wie "gewollt und nicht gekonnt".
Ich verwende Google Translate lediglich um einen "Übersetzungs Pull Request" für mich lesbar zu machen. Also um auszuschließen das mir da einer einen Streich spielt.
Bitte mich nicht mehr pingen. Danke.
Kann ich gerne machen. Wenn mir jemand einen PR erstellt geht das sofort, andernfalls dann frühestens morgen.
Außerdem habe ich bisher noch keine Funktion im VDR vermisst, die tools.h bietet da ausreichend Möglichkeiten, z.B. mit cString, das Du teilweise durch std::string ersetzt hast. Das ist zwar C++-Standard, aber zwei String-Libraries in einem Plugin finde ich nicht so schön zumal ich bei cString noch nichts vermisst habe und das .c_str() ziemlich sperrig finde.
Gerade wenn man auf Mitarbeit von anderen Plugin-Entwicklern hofft könnte man auch annehmen das die "tools.h"-Features mehr oder weniger "VDR-Standard" sind. Also auch eher im VDR-Kontext "vertraut" sind.
Das die Zusatz-Library aus dem Kontext reingewandert ist, dass der Sourcecode eigentlich in ein anderes Plugin gelinkt wird (und da die Library eh gelinkt wird) war in einem anderen Thread schonmal Thema. Ist halt im "Solo-Betrieb" dann eher lästig.
Meine Kritik zur "Spezial Library" hatte ich ja schonmal geäußert. Ich frage mich: Wie viele Zeilen zusätzlicher Code wären im Plugin wenn man die Library wieder raushaut? Ja, das Plugin hat schon Abhängigkeiten, aber das sind halt alles Standard Libraries.
Das Thema "Sat IP" wird definitiv weiter an Relevanz gewinnen weil der Markt an PCI Tunern schon klar in eine Richtung zeigt. Hier ist es definitiv von Vorteil wenn alle an einem Strang ziehen für genau ein gut gemachtes Plugin.
Wenn gewünscht lege ich euch das auch gerne "neutral" bei VDR-Projects an.
Es ging mir hier nur um Leerzeichen am Ende einer Zeile, die sowohl der menschliche Leser des Codes, als auch der Compiler ignorieren. -> Es ist egal ob sie da sind, Entfernung ist kein Mehrwert.
Eine IDE und/oder Editor zeigt die durchaus an. Bei mir im Emacs als dicke rote Balken.
https://github.com/VDR4Arch/vdr4a…95db70724b0cdc1
Sollte als temporärer Fix hinhauen
Wie sinnvoll es ist, unendlich zu warten, sei mal dahingestellt...
Eigentlich ein guter Punkt. So ist in der Theorie ein Deadlock möglich. Aber ich kenne mich mit dem VNSI Code auch nicht aus. Zumindest für mich gilt da: Never change a running system.
Ich halte es für durchaus möglich das dort das Problem liegt.
VNSI übergibt eine "-1" für das Timeout und das soll für "unendlich langes Timeout" stehen. Dieses "Max" killt diese Option weil dann eine 3 draus wird.
Danke für die Warnung. Also erstmal Finger weg.
Kompiliert schonmal auf Anhieb ohne Nacharbeit. Bin gerade dabei das für Arch mal komplett mit Plugins zu bauen.
Update AUR-Upload läuft. "vdr-plugin-plex" hab ich rausgehauen. Das hat nicht mehr gebaut und ich werde das nicht weiter analysieren.
Nicht jedes Fernbedienungs-Protokoll hat ein Bit das "gedrückt gehaltene" Tasten signalisiert. Es gibt sehr viele Protokolle die dann einfach immer wieder exakt die gleichen Bits senden wie beim einzelnen Drücken. Und die bekommt man dann nur über ein Zeitfenster erkannt.
