Beiträge von M-Reimer

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:

  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

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:

if (by < 512) by = 512;

Ich hab immer noch nicht ganz verstanden wo der Puffer genutzt wird. Wenn der binär übers Netzwerk geht wäre schon sinnvoll Platz zu sparen.

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.

Ich hätte prinzipiell Interesse daran mein Modul (https://github.com/M-Reimer/pysvdrp) weiterzuentwickeln.

Ich spiele sogar mit dem Gedanken damit, mehr zum Spielen, irgendwann damit Kodi an VDR zu koppeln. Allerdings ist da noch einiges zu klären. Ich gehe davon aus das so eine Lösung VNSI in mehreren Belangen unterlegen ist. Aber sie ist definitiv geeignet mein Python-Modul in einem "Real World Szenario" zu testen und ggf. zu erweitern.

Wir können bei fehlenden Features ggf. gerne direkt kommunizieren. Ich hab selber noch ein paar Änderungen vorbereitet die in nächster Zeit auf GitHub gehen.

Scheint im Prinzip recht robust zu sein, so ein PCIe Signal.

Wäre nicht sinnvoll wenn du den Schutz gegen Selbstzuweisen im cString noch aufnimmst? Meiner Meinung nach sollte kls das auf jeden Fall auch aufnehmen.

Hatte ich im Plugin gelöst. An der Stelle, wo das Plugin externe Scripts ausführt statt nur Prozess ausführen erst eine Prozessgruppe anlegen und den Prozess darin ausführen.

An der Stelle wo das Script nun stoppen soll nicht mehr den Prozess sondern die ganze Gruppe weg.

Weil Probleme mit dem Beenden von VLC genannt wurden:

Es ist zwar wirklich ewig her, aber vor etlichen Jahren wollte ich mal ein paar Internetradio-Sender via IPTV in meine Kanalliste basteln und mir ist das Problem da auch aufgefallen. Das Problem war für mich vor allem das VLC dann auch munter den Stream offen gehalten hat. Zwei Streams parallel waren mit meiner damaligen Internetverbindung aber nicht drin.

Ich habe meinen Bastel-Code von damals nicht mehr, aber ich habe mich dann mit Prozess-Gruppen befasst und VLC in eine Prozess-Gruppe gestartet. Bei Kanalwechsel bin ich dann nicht mehr gezielt auf einen Prozess sondern auf die ganze Gruppe gegangen.

Ich vermute VLC forkt irgendwann einen Prozess ab und ein "kill" auf den ursprünglichen Prozess kommt nicht mehr an. Die Gruppe umfasst aber auch den von VLC neu erstellten Prozess.

Eigentlich ist das ja genau die "Niesche" in die das IPTV-Plugin passen sollte?

Etwas Aufwand wäre dann nur noch das EPG. Aber das würde ich als Betroffener dann extern über SVDRP einspeisen.