Posts by M-Reimer

    Allerdings finde ich nur Infos, das es mit dem vdr-plugin-iptv geht, das plugin unter Debian 12 aber nicht mehr verfügbar ist und vdr-plugin-iptv gar nicht mehr entwickelt wird.

    Ähnliche Situation hatten wir mit dem sat-ip Plugin. Man kann wohl davon ausgehen das alle "rofafor-Plugins" aktuell nicht weiter entwickelt werden. Auf meine, allgemein formulierte, Anfrage habe ich bis heute keine Antwort: https://github.com/rofafor/vdr-plugin-satip/issues/86


    Wenn aber der Bedarf besteht kann ich das gerne auf "vdr-projects" übertragen damit nötige Fixes wo hingehen können.

    Ich hab selbst einen Usermode Treiber geschrieben der genau das macht. Die Nullen stören nur wenn man das Resultat tatsächlich als String nutzt. Von der Idee her ist std::string nur ein Byte Buffer. Die Nullen sind auch nur Bytes.

    So wie ich es verstanden habe war der letzte Vorschlag von wirbel genau das: Ein Vorschlag. Getestet hat das bisher keiner und da ich selbst bis heute nicht dazu gekommen bin das zu testen kann man das selbstverständlich auch nicht einfach so übernehmen.


    Was mich aktuell daran noch am meisten stört ist dieser Block (der eigentlich ähnlich ein zweites mal drin ist):

    Wenn auf "Objektorientierung und C++" dann bitte, wenn irgendwie möglich, raus mit dem Pointer-Low-Level-Kram. Eine Google-Suche hatte zumindest Ansätze gegeben wie man einem "Vector" gleich mehrere Elemente auf einmal zufügt. Es muss also irgendwie gehen, aber ich bin da noch zu weit weg.


    Im Prinzip spricht auch technisch nichts dagegen std::string zu verwenden: https://stackoverflow.com/ques…-avoid-manual-dynamic-mem

    Allerdings stimme ich da schon zu das ein "Vector" vermutlich "sauberer wäre". Aber wenn der "std::string" es einfacher macht eine aufeinander folgende Bytekette zu verwalten ohne dann doch wieder mit Pointern zu jonglieren, dann würde ich persönlich das vorziehen. Lieber std::string als wieder Low-Level-Zeugs. Und bei einem std::string weiß ich halt das ich ein 4 Byte Integer einfach auf "char" casten kann um es als "String der Länge 4" hinten anzuhängen. Habe ich selbst schon gemacht. Funktioniert einwandfrei.


    Vielleicht komme ich auch tatsächlich nochmal dazu selbst bisschen zu probieren. Ich komme aktuell nicht dazu viel zu machen. Meine VDR-Kiste wird kaum noch genutzt und ich muss meinen Bekannten, für den ich bisher noch ein bisschen versuche zumindest den Arch-Paketsatz nutzbar zu halten, mal fragen ob er überhaupt noch vorhat einen neuen VDR zu bauen. Seine alte Kiste (größer 10 Jahre alt) wird nämlich nur noch mit Gebraucht-Teilen "am Leben gehalten" und Updates fahren wir da schon lange keine mehr drauf weil die bei so alter Hardware nur Ärger machen. Wenn er da keine Motivation mehr hat würde ich mich tendenziell eher noch mehr aus dem VDR-Bereich zurückziehen.

    Ich hatte den NetCeiver bei einem guten Kumpel, der 30 km entfernt wohnt, in Betrieb gehabt. Ich hab den mit Hilfe hier aus dem Board irgendwie zum Laufen gebracht. Zunächst mit minisatip und dann mit gleichen Einstellungen mit dem mcli Plugin. Meine Möglichkeiten, noch etwas nachzuvollziehen, tendieren aber gegen Null. Wie schon erwähnt habe ich keinen funktionsfähigen NetCeiver mehr. Ich selber habe und hatte nie Interesse am NetCeiver. Das war eine Idee des Vaters meines Kumpels, welcher den NetCeiver entgegen meinen Rat dann "spontan" bestellt hatte. Bei den Preisen "guter" Sat>IP Server glaube ich am ehesten das da jetzt wieder PC-Hardware mit eingebauten Tunern hinkommt. Oder ein ARM mit PCI-Express um bestehende Tuner stecken zu können.


    Ich glaube "lftp" wurde ursprünglich eingebaut um einen "gängigeren" FTP Client zu nutzen. Allerdings gab es dann zumindest in einem Fall ein Problem das mit lftp nicht lösbar ist: https://github.com/vdr-projects/libnetceiver/issues/1


    Schon aus diesen Grund würde ich empfehlen nicht lftp sondern tnftp zu nutzen und wie der mit IPv6 konfiguriert wird steht hier: https://aur.archlinux.org/cgit…it/tree/PKGBUILD?h=tnftp6

    In Fällen wo "dauerlaufende" Scripts ein Problem sind ist es zumindest bei einem Shellscript extrem einfach das zu vermeiden.

    Der "Hack" mit "at" den man immer mal wieder sieht ist nämlich nie nötig gewesen.

    Einfach den gesamten Shell-Code klammern (normale runde Klammern) und hinter die schließende Klammer ein "&" setzen. Das gesamte Script läuft damit im Hintergrund und die VDR-Prozesse, die Scripte nutzen, werden nicht blockiert.

    Man könnte auch vereinfacht sagen: Diejenigen, die ihr TV-Programm über eine "Tunerkarte" empfangen und über eine Grafikkarte wiedergeben sind sehr sehr deutlich in der Minderheit. So deutlich in der Minderheit das das Angebot an Tunerkarten auf dem Markt auch stetig zu schrumpfen scheint.


    Und die Fernseher, die "in der Masse" im Einsatz sind, halten sich eben an die zu dem Zeitpunkt definierten Standards. Seit Fernseher nicht mehr nur analoge Empfangsteile eingebaut haben würde ich sogar sagen das selbst der Besitz eines "Receivers" mittlerweile sehr selten geworden ist.

    Die Frage ist auch wie viel Investition 4K wert ist. Bei den allermeisten Fernsehern und üblichen Sitzabständen dürften viele den Unterschied zwischen 4K und 1080p nicht erkennen. Um von 4K wirklich Mehrwert zu haben bräuchte man schon enorme Diagonalen oder sehr kurze Sitzabstände. Da gibt es ganz andere Dinge wo man bei den ÖRR mehr investieren sollte. Man könnte auch ganz banal mal bei der Qualität des Programms anfangen.


    Zurück zum IPTV Plugin: Wenn sich jemand berufen fühlt kann er gerne bei der Pflege des Plugins helfen. Bei der Vielzahl verschiedener möglicher Standards für IPTV würde ich jetzt nicht erwarten das das alles im VDR direkt landet. Hier wird man wohl das Plugin entsprechend fit machen müssen.

    Was "lftp" hier bemängelt ist ja eigentlich recht klar kommuniziert. Scheinbar ist es möglich lftp ohne IPv6 zu kompilieren, was hier auch getan wurde. Auf jeden Fall ist IPv6 bis in den FTP Client zwingend erforderlich. Der NetCeiver hat ausschließlich eine IPv6-Adresse.


    Es gab auch weitere Probleme mit lftp weshalb mehr oder weniger der empfohlene Client letztlich wieder tnftp war. Der muss aber auch zwingend so konfiguriert sein das er IPv6 unterstützt. Ich hatte das bei Arch vor vielen Jahren mal als Bug gemeldet, was ignoriert wurde. Aus diesem Grund gibt es für Arch https://aur.archlinux.org/packages/tnftp6


    Viel weiter werde ich aber nicht helfen können. Ich hatte nochmal Zeit in das Netceiver-Thema gesteckt weil ein guter Freund von mir einen voll ausgestatteten NetCeiver gekauft hat und wir den irgendwie sauber nutzbar machen wollten. Das hat auch halbwegs funktioniert aber dann ist der NetCeiver plötzlich komplett ausgefallen. Auch die LEDs geben keine Auskunft. Das Ding ist einfach mausetot ohne feststellbare Ursache. Nachdem jetzt schon so viel Zeit in das Thema geflossen ist, war mein Vorschlag er soll sich bei Kleinanzeigen oder so nach einer neuen Hauptplatine umschauen in die man die 3 Doppeltuner stecken könnte. Ob er den Weg geht weiß ich nicht. Eventuell wäre es hier auch an der Zeit auf etwas "modernes" zu wechseln.

    Ist jetzt für mich spontan nicht ganz zu erfassen. Müsste ich mich mal länger mit befassen. Ich weiß z.B. das es Templates gibt, hab die aber selbst nie verwendet.


    Für meinen Geschmack ist da noch zu viel "Low-Level Speicher Kram" drin. Hätte etwas dagegen gesprochen als Buffer einen "std::string" zu nutzen? Und dann mit "append" einfach alles hinten anhängen? Eventuell wäre das sogar (je nachdem wie da intern optimiert wird) effizienter weil Daten blockweise kopiert werden statt Byte für Byte in einer Schleife.


    Und eventuell doch eine Basis-Klasse und dann abgeleitete Klassen pro "Paket-Typ"? Hätte dann den Vorteil das jede Klasse ein eigenes "finalize" haben kann. Oder doch ein globales "finalize" und als Konstanten im "Private" der jeweiligen Klasse dann die relevanten Positionen.

    Selbst eine "primitive Anwendung" kann aktuell schon zu viel sein. Ich hatte SVDRP noch nicht 100%ig abgedeckt sondern schrittweise das eingebaut was ich brauche. Also ggf. einfach vorher fragen was gebraucht wird. Wenn's fehlt baue ich das mit Priorität ein.


    Aktuell drin ist Kanalverwaltung und EPG. Beim EPG hab ich noch kleinere Anpassungen vor, aber ich hab für den EPG Part hier schon ein Demo-Script welches mir für einen Kanal ohne EPG ein EPG aus dem Internet holt.


    Edit: Das andere Modul das du gefunden hattest unterstützt aber auch nur einen Teilsatz. Im Prinzip ist mein Ziel schon 100% Abdeckung. Wenn der Bedarf aufkommt gerne auch inklusive Unterstützung des Befehlssatzes ausgewählter Plugins. Aber das geht halt besser wenn man konkrete Projekte hat um neue Funktionen auch direkt zu erproben.

    Im Prinzip gehört die gesamte "cResponsePacket" komplett neu geschrieben. Mal sehen ob ich da irgendwann mal Zeit und Lust für habe.


    Statt mehrerer "init..." und "finalize..." wäre sinnvoll eine Basisklasse zu haben und dann die Varianten davon abzuleiten. Allerdings müsste ich dafür erstmal komplett erfassen wie "cResponsePacket" genutzt wird. Bisher sieht es so aus als würde immer nur ein Paket erstellt und das Objekt dann verfallen gelassen. Ein "Wiederverwenden" eines Buffers findet scheinbar nicht statt. In dem Fall könnte man die "init..." auch als Konstruktor der abgeleiteten Klassen anlegen.


    Auf jeden Fall hab ich jetzt erstmal die "Realloc Strategie" des ursprünglichen Autors wieder hergestellt und ein paar Kommentare hinzugefügt. Wenn damit alles läuft würde ich das die Tage mal als neues Release markieren.

    Deinen zweiten Vorschlag hatte ich auch erst vorbereitet aber mir dann gedacht das ja eigentlich total wumpe ist in welchem Raster man Speicher abfragt. Und ja, das verfällt alles wenn das Paket raus ist.

    Jetzt hab ich mich notgedrungen doch mal mit der Datei responsepacket.c auseinandergesetzt. Im Prinzip wäre es nicht verkehrt das komplett neu zu schreiben. So einen dynamischen Buffer baut man am besten mit einem "std::string", der einem sowas wie die Speicherverwaltung direkt abnimmt.


    Erstmal zum Thema "sicherheitshalber etwas früher mehr Speicher holen" (ein Byte mehr für vergessenes "trailing zero"), also diese Zeile wo im unverändeten Code stand:

    Code
      if ((bufUsed + by) < bufSize)
      {
          return;
      }

    Soll heißen: Wenn "Füllstand plus nötige Bytes" KLEINER IST als die mögliche Größe des Buffers, dann nichts tun. Hier dürfte in Theorie auch "<=" stehen, denn wenn der Buffer genau die größe hat, die gebraucht wird, dann könnte man den ja einfach so verwenden. Hier ist also, wenn ich das nicht falsch verstanden habe, bereits ein "Sicherheits-Byte" vorgesehen.


    ==> Ich würde diese Stelle einfach "im Original" verwenden.


    Wegen der "growth strategy" bin ich mal in der Historie etwas zurück und hab dort das gefunden: https://github.com/vdr-project…91ad8830af8ce970de9f4L277

    Code
    if (512 > by) by = 512;

    Das könnte man frei interpretieren als "hole mindestens immer 512 Bytes Speicher".


    Ich würde vorschlagen diese Zeile einfach wieder rein zu nehmen. Die ist beim dort stattgefundenen Maintainer-Wechsel und dessen Überarbeitung "untergegangen", war aber vom ursprünglichen Entwickler sicher nicht umsonst so gewählt.


    Ich würde das aber rein gefühlsmäßig umdrehen in:


    Code
    if (by < 512) by = 512;

    Erledigt.


    Sorry das es sich verzögert hat, aber ich hänge schon den ganzen Tag für die Arbeit vorm Firmenrechner und nicht jeden Tag (oder in letzter Zeit sogar die wenigsten Tage) habe ich dann noch Lust danach noch am privaten Rechner zu sitzen.


    Auch wenn hier nicht wirklich richtig aufgehoben aber generell der Hinweis: Wann auch immer möglich bitte Pull-Requests anlegen. Ich habe weder den Anspruch noch die Zeit vdr-projects alleine zu "stemmen". Das war als Community-Projekt gedacht und einen PR kann ich ggf. auch beim Spazieren im Wald schnell am Handy weiterklicken.

    Letztlich gibt es nur zwei realistische Optionen. Entweder die API wird nicht inkompatibel geändert (keine Ahnung wie die dann aussehen müsste) oder sie wird inkompatibel geändert und nach dem "krachen lassen" Prinzip rausgegeben.


    Ein Makro mit "standardmäßig deaktiviert" bringt niemandem was wenn ein Plugin dann die neue Schnittstelle benötigt. Der Distributor hat dann nur eine realistische Option: Einschalten.


    Und eigentlich haben wir mittlerweile auch theoretisch bessere Chancen denn je eine Änderung in endlicher Zeit bei allen Plugins reinzubekommen.