Posts by Sundtek

Ok Uwe hat's noch auf die Liste geschafft (4 sind an der Stelle bereits vergeben).

jsffm - vielleicht (wird dann Ende nächster Woche entschieden). Das ist wie oben erwähnt noch ein Prototypen-run.

Hab Dir eine Nachricht geschickt, abzüglich Dir ist noch einer verfügbar.

Hallo,

//////////

Alle Tuner sind vergeben

//////////

Ende nächster Woche können wir 4x DVB-C/T/T2 4K USB Prototypen kostenlos (inklusive Versand) abgeben, wir haben diese für die Fertigung optimiert.

Der Treiber funktioniert soweit wie gewohnt mit X86, X86-64, ARM-32, ARM-64, MIPS, PPC, etc. die Treiber werden im Laufe der kommenden Woche freigegeben.

Bedingung - Feedback innerhalb der ersten 2 Wochen wie sie sich im Einsatz mit VDR schlagen.

Nur 1 Tuner pro Person.

Bei Interesse einfach eine Nachricht schreiben.

//////////

Alle Tuner sind vergeben

//////////

Kommt dann im Laufe der kommenden Woche, bin aktuell eigentlich an einem anderen Thema dran welches ich unbedingt abschließen möchte.
Der Code ist schon fertig, kann ihn dann auch hochladen zum Testen.

Der Fehler wurde behoben und der Treiber wurde aktualisiert.

Ich denke das Problem ist behoben, MarkusE kann's erst mal testen.
Eine Race Condition beim Abmelden vom Treiber, dort wo kein DVB Device geöffnet wird tritt es auch nicht auf. Praktisch sehr schwer zu triggern.

Kudos an MarkusE.

Quote from M-Reimer

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.

Dafür kommt dann auch noch ein Update, in der glibc gibt's auch nen Bug der behoben werden muss (den Fix haben wir schon aber das muss jetzt noch genauer überprüft werden). Der libc Patch behebt dann 3 glibc Bugzilla Einträge.
So kommt dann eins zum anderen.
Das libc Update lässt es dann zu dass man preloading auf einzelne Programme limitiert, aber global festlegen kann.

Markus hat uns das schon mitgeteilt, ein guter Fund - danke!
An einem Update wird gearbeitet.

Ich schätze logrotate hat diese Datei rasiert.

Hast Du auch eine ganze Logfile, wo z.B die Frequenz / der Transponder drinnen steht?

Wenn das auftritt bitte auch /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapterX/frontend0 --band universal ausführen.

Ja, der Tuner hat zur Zeit nur einen Empfänger. Die Dual DVB-C/C2/T/T2/S/S2 Tuner werden noch getestet (der Empfang wird noch getestet, auch gibt's in der Produktion bei uns Upgrades); Es werden demnächst dann weitere Tuner auf den Markt kommen.

> Normal ist bei Linux (eine übliche Distro meine ich, kein abgespecktes Image), dass die unterstützte Hardware einfach funktioniert. Maximal muss man ein Paket
> mit Firmware installieren, aber das war. (Das ist doch auch gerade das geile an Linux!)

Man kann das Ganze eigentlich recht einfach — und historisch — sehen.
Am Anfang gab’s ausschließlich Kernel-Treiber, weil es gar keine andere Möglichkeit gab. Später kam dann die Möglichkeit hinzu, Treiber auch im Userspace zu betreiben. Genau diese Schnittstellen wurden damals geschaffen, um komplexeren Code nicht im Kernel laufen zu lassen – also dort, wo jeder Fehler gleich das ganze System reißen kann.

Wir haben uns eben auf diese Userspace-Variante gestützt. Das war kein Zufall, sondern eine bewusste Entscheidung. Leider hat sich über die Jahre kaum jemand die Mühe gemacht, die Userspace-Infrastruktur konsequent weiter auszubauen – von uns mal abgesehen.

Dass Kernel-Treiber der „Standard“ seien, ist eher historisch gewachsen als technisch begründet. Nur weil etwas im Ring 0 läuft, heißt das noch lange nicht, dass es sinnvoll ist. Im Gegenteil:
Ein schlecht gepflegter oder schlecht getesteter Treiber im Kernel ist ein massives Sicherheitsrisiko.

Und was das Argument angeht, dass „unter Linux alles einfach läuft“ – das stimmt nur, solange die Hardware schon drin ist. Sobald neue Geräte auf den Markt kommen, hängt’s meistens: kein Treiber, keine Firmware, kein Support. Die wenigsten Anwender kompilieren sich selbst irgendwas, und genau das ist ja auch nicht Sinn der Sache.

Zur Pflege: Man schaue sich mal die glibc an – Open Source, seit Ewigkeiten da, also müsste sie doch top gepflegt sein, oder?
Wer da wirklich mal in den Code eintaucht, wird schnell merken, dass „gut gepflegt“ relativ ist.

Kurz gesagt:
Userspace-Treiber sind nicht „gegen den Standard“, sondern genau dafür gedacht – um Systeme stabil, sicher und updatefreundlich zu halten. Nur nutzen diese Möglichkeit halt die wenigsten (abgesehen von jenen die unsere Geräte verwenden

Ok somit letzte Antwort hier bezüglich des Debugging Themas, du wirst wohl Debug-Bibliotheken benötigen damit GDB die Rücksprungadressen findet (wenn Du das weiter verfolgen willst bitte im Chat oder in Deinem anderen Beitrag).

Kommt wohl daher da das Library keine Symbole hat, solltest Du die benötigen einfach sagen /opt/bin/mediaclient --arch sagt dir welchen Build Du benötigst. Solche Dinge würde ich lieber im Chat besprechen und auch direkt bereitstellen - da es schneller und zielführender ist. Wennn Du es öffentlich dokumentieren möchtest ist das kein Problem für mich / uns.
Für uns zählt nur alles was Verbesserungen bringt ist willkommen

gdb findet in dem Fall einfach die Rücksprungadresse nicht mehr, es ist also kein Fehler im eigentlichen Sinne.

https://discord.gg/AR5QJhyNnw

Quote from M-Reimer

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?

Hatte ich vorher erwähnt, Non-Disclosure Verträge mit Zulieferern. Diese Verträge sind teils sehr strikt, und Verstöße hätten erhebliche Konsequenzen. Im Gegenzug erhalten wir dafür direkten Support von den jeweiligen IC-Designfirmen – was insbesondere bei komplexen Chips ein entscheidender Vorteil ist.

Hi MarkusE,

das mit dem Debugging ist ein Problem und dafür gibt's wohl einen Grund, wenn Du das reproduzieren kannst können wir das eventuell gemeinsam durchgehen, am Besten wäre das remote zu überprüfen - Es würde mir auch nicht gefallen wenn ich andere Bereiche nicht debuggen könnte. Es gab schon die Situation wo über den Stack Bugs in anderen Programmen gefunden wurde. Wenn es irgendwelche Probleme gibt - vor allem auch uns irgendwie mitteilen damit wir das registrieren.

Eine libmediaclient.so Version mit Symbolen bereitzustellen ist kein Problem.

Betrifft 1. und 2. wir haben jetzt auf Anhieb kein so ein Testszenario mit einem beschädigten Datenstrom von einem schwachen Transponder.
Zum Testen haben wir soweit immer Astra 19.2 verwendet und einen Signalgenerator.

Falls DVB Debugging benötigt wird ich denke wir hatten da mal was eingebaut was die DVB Befehle in eine Logfile geschrieben hat, sowas kann man auch schnell mal in einen Debug-Treiber stecken.

Wie erwähnt bezüglich dem LD_PRELOAD wird es demnächst von uns einige Änderungen in der Libc geben. Mal schauen was die Diskussionen mit den Entwicklern sonst noch ergeben werden.

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.
Diese gingen in einigen Fällen soweit dass Chip Hersteller Kunden sogar besucht haben um Probleme zu überprüfen. Diese garantieren uns 100%igen direkten Support, und wir wissen genau welche Versionen der Treiber im Umlauf sind - spätestens dann wenn Kunden die Treiber aktualisieren - und das geht in 10 Sekunden.

Es sei auch gesagt die direkte Linux Anwendergruppe ist die schwierigste, aber sie haben die Treiber auch dorthingebracht wo sie jetzt sind und dafür sind wir auch sehr dankbar.
Anwender auf NAS Systemen, Settopboxen sind da etwas weiter entfernt von den Systemen.

Quote

Für eine Ankopplung an eine Closed-Source-Library werde ich persönlich auf jeden Fall keine Freizeit aufwenden.

Deshalb kümmern wir uns ja auch um die Anbindung
- vdr-dynamite hat den Ursprung für unsere Geräte (dank an Lars Hanisch hierfür)
- tvheadend hat in frühen Zeiten auch bereits Updates für unsere Geräte implementiert.

Deine Anfrage bezüglich CUSE / FUSE - diese beiden Projekte sind Opensource hängen ja auch mehr in der Luft als sonstwas (ich denke es war der Teil mit dem Interrupt Signalling der nicht ganz rund ist, FUSE an sich ist schon ganz okay - aber halt nicht für solche erweiterten Dinge ausgelegt). Es würde sicher jeden freuen die Qualität von CUSE / FUSE Opensource Teilen zu erhöhen.

So sieht dass dann auch in der Realität aus, es gibt mehr oder weniger viele offene Baustellen mit Linux, selbst mit anderen Opensource Projekten, aber die wenigsten schauen es sich tatsächlich an.

Ein Beispiel war ein FreeCAD Update, wir haben ein Problem repariert - einem Entwickler gefiel der Coding Style nicht und es dauerte sage und schreibe 3 Jahre bis sich dann jemand durchgerungen hat es umzuschreiben. In der Zeit stießen viele Anwender der jeweiligen Funktion auf die Probleme.
Erst dauerte es Stunden bis das Problem lokalisiert wurde, und es fehlte einfach die Zeit sich mit den Vorlieben des Entwicklers zu spielen - da wir pragmatisch sind haben wir einfach gesagt er soll es doch selber umschreiben was er natürlich nicht gemacht hat, das war auch früher schon meine Erfahrung mit LinuxDVB (und da gab's auch ohne uns genug Streitereien), mittlerweile sind so gut wie alle Entwickler weg davon da der Rest vom Settopbox Markt nun mehr oder weniger komplett in asiatischer Hand ist. Übrig geblieben sind nur noch einige Analog / Kamera-Entwickler und der Maintainer der oben drüber sitzt.

Bei unseren kommenden libc Patches wird es anders ablaufen, da wir absolutes Interesse an Verbesserungen haben - und das Fenster durch die aktuelle Situation einfach gegeben ist.
So trägt auch unser Closed-Source-Treiber dazu bei, Open Source zum Positiven zu verändern.
Und die Unterstützung kommt schlussendlich durch unsere existierenden Kunden welche ebenfalls gerne Linux einsetzen.

Quote from M-Reimer

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.

Es gibt 3 Möglichkeiten, man kann den Treiber einfach als Treiber-Server verwenden.

1. direkt gegen Interface Bibliotheken linken (oder mittels dlopen / pluginmäßig öffnen), die API der Interface Bibliothek entspricht der offiziellen LinuxDVB / V4L API (mit einigen Erweiterungen, z.B Hardware Blindscan, DAB+, etc.)
2. den Streamingserver verwenden (der auch direkt verlinkt).
3. über libc simulieren (LD_PRELOAD).

Nun gibt's das auch nicht seit gestern sondern seit den letzten 17 Jahren.

Wer mit CUSE / FUSE experimentieren möchte kann das gerne machen, und direkt gegen die Interface-Bibliotheken linken und einen Proxy bauen.
Aber vorab CUSE benötigt (meines Wissens nach) noch etwas Arbeit im Kernel. Wir hatten uns das früher mal angeschaut, und es war nicht stabil. Einige Linux Versionen können damit zum Absturz gebracht werden. Außerdem ist CUSE / FUSE auch nicht überall verfügbar.
Dennoch sicherlich ein interessantes Projekt, und je mehr Möglichkeiten es gibt desto besser.

LD_PRELOAD an sich ist auch nichts schlechtes, wir werden demnächst einige Patches auf der libc-alpha Mailingliste hinterlegen um das Interface zu erweitern, und Regeln hinzufügen (damit man die Architektur limitieren kann, oder Applikationen).
Das beinhaltet dann auch dass 3-4 andere Einträge im glibc Bugzilla geschlossen werden können, einige Ideen waren dort so gut dass wir sie auch einarbeiten z.B den Support der include Direktive um wie bei /etc/ld.so.conf "include /etc/ld.so.conf.d/*.conf" zu unterstützen. Dann muss man ld.so.preload nicht mehr anrühren sondern kann einfach eine Datei hinterlegen.
Es wird dort innerhalb der nächsten Wochen auf jeden Fall zu Änderungen in der glibc kommen.

Quote from SHF

Trotzdem sind die Treiber leider Closed-Source und nicht im Kernel.
Ein Treiber direkt im Kernel ist IMHO aber vorzuziehen, da es einem jegliche Software-Bastelei spart und man im Zweifelsfall nicht vom Wohlwollen (und der Existenz) des Herstellers abhängig ist.

Das sind für mich zwei eindeutige Vorteile für den User.
Daher würde ich eine Karte mit Kernel-Treiber immer vorziehen, selbst wenn sie etwas teurer wäre.
Den Treiber in den Kernel zu bringen macht anfangs halt etwas extra-Arbeit, da unterstütze ich den Hersteller gerne, anders kann Opensource auch nicht existieren. Auf Dauer gesehen rechnet sich das für mich dann aber auch .
Ich habe über die Jahre leider einfach schon zu viele Firmen einfach verschwinden oder ihren Support einstellen gesehen.

Es ist Dein gutes Recht

Ich denke mit der Software Bastelei verwechselst Du da etwas gerade wenn's um's Kompilieren geht - da bei uns nichts kompiliert wird.
Die Antwort legt aber nahe dass Dir einfach Erfahrung mit Userspace Treibern fehlt. Die benötigen nämlich keine Updates über verschiedene Kernel hinweg.
Unsere Tuner werden genau aus solchen Gründen auch in Flugzeugen verwendet (zwar nicht für DVB aber Analog) um Kameras anzubinden. Kerneltreiber haben dem Betreiber das System mit der Zeit abgeschossen und ein Update des Kernels oder gar der Media Treiber funktioniert für den Betreiber nicht.

Zudem kann der Treiber autark als Streamingserver verwendet werden.
Und das Argument mit zu vielen Firmen verschwinden gibt's jetzt schon seit 17 Jahren und macht es dennoch nicht besser.
Wenn es im Kernel Probleme gibt wird das gesamte System lahmgelegt, im Userspace betrifft es lediglich den Treiber selber (ähnlich einer Mikrokernel Architektur). Auch die Portabilität ist einfach deutlich besser, der eine Installer deckt x86, arm, mips, ppc, sh4, etc. ab. Auf Synology NAS Systemen sind wir praktisch die einzigen USB Tuner die funktionieren.

Das größere Problem ist eher der Support, das merken wir auch bei uns. Defekte Kabel / driftende LNBs, schlechtes Signal, und da wird am häufigsten nachgefragt wie das überprüft werden kann.

Und die Stecker sind reguläre USB Typ A Stecker, die sitzen gut - wenn die das im Flugzeug schon langfristig hinbekommen dann sollte es für den Anwender auch möglich sein
Wie sich USB Typ C in Zukunft bei den Tunern schlagen wird werden wir sehen. Dem Argument der Verbindung - wenn Du in Küstennähe mit feuchtem Klima wohnst kann es durchaus auch vorkommen das PCI-Express Verbindungen - vor allem die PCIe 1x Verbindungen über Jahre hin Probleme beim Kontakt bekommen (Quelle - eigene Erfahrung).
Wenn der USB Tuner mehrere Jahre nicht benutzt wurde muss er eventuell auch mehrmals angeschlossen werden um die Oxid-Schicht zu entfernen

Kontaktprobleme sind aber keine schwerwiegenden Probleme und dadurch leicht behebbar, dieses Argument ist eigentlich nicht mal die Rede wert.

Quote from SHF

Da ich schon zu viel Ärger mit wackeligen USB-Steckern hatte, würde ich zu etwas mit PCIe-Slots, SATA-Buchsen und einem gescheiten Gehäuse drum raten.

Den Raspberry Pi 500+, also dieses Keyboard-Ding, finde ich daher für einen Server als völlig ungeeignet.
Wen es dasteht staubt das Keyboard ein und wenn man es dauern bewegt, gibt es irgendwann Probleme mit den Steckern.

Die Sundtek-Treiber sind ein Closedsource-Eigengewächs, was am Kernel vorbei arbeitet.
Damit das geht, werden Teile der C-Standard-Bibliothek überschrieben. Allein deswegen würde ich eine andere Karte vorziehen, wenn möglich.

Man kann das Preloading problemlos auf den VDR beschränken oder alternativ direkt die Streaming-Server-Funktionalität verwenden – je nach Setup.

Was die USB-Stecker betrifft: bei einem stationären Aufbau bewegt man das Gerät ja nicht ständig. Solange die Stecker ordentlich sitzen, gibt es da keine praktischen Probleme. Es fährt schließlich niemand mit der kompletten Anlage durch den Wald über Stock und Stein.

Der große Vorteil dieser Lösung ist, dass sie seit 2006 mit nahezu allen Linux-Systemen funktioniert – ohne Kernel-Abhängigkeiten oder Versionsprobleme. Das ist im Alltag deutlich wichtiger als theoretische Bedenken zur Architektur. USB hat praktisch jedes System, PCI-Express nicht unbedingt (PCI-e wird von uns aber auch noch kommen, sobald der Dual DVB-C/T/T2/S/S2 USB Tuner [1] fertig ist, der wird wird zur Zeit noch getestet - und das dauert üblicherweise..).
Nach wie vor wenn jemand Probleme meldet, schauen wir uns das an. Das Treiberpaket unterstützt jetzt noch den ersten Tuner den wir 2008 verkauft haben.

[1] https://i.snipboard.io/0YP5oC.jpg?nocache=1760171093150