Tuner für Raspberry Pi 5(00)

Wenn es um DVB-C/DVB-T2 geht sollte das Ding eigentlich gut laufen:

Hauppauge DVB-C Duo

Der Vorteil sind halt zwei Tuner in einem und Treiber für Linux.

Aber anstatt Raspi würde ich lieber auf einen Mini x64 Computer wechseln. Mehr Leistung ähnlich wenig Strombedarf und direkter SSD/HD Anschluß. Und vor allem volle Linux Unterstützung ohne zu Überlegen ob es auch einen ARM Version der Software gibt.

Zum Beispiel sowas hier:

Link

Da kannst du eine M2 SSD zum Booten und für die VDR Software nutzen und gleichzeitig eine 2,5" Festplatte für Aufnahmen rein setzen und dann den oben genannten USB Stick nutzen.
Du kannst die ganz normale VDR Software aus deiner Linux Distribution nehmen und auch eine VDR Ausgabe wäre möglich. Auch für andere zukunftige Dinge (z.B. Hausautomation, Fileserver, etc) hat so ein Ding mehr Power als ein Raspi.

Oder wenn du eine eigene Fritzbox als KabelTV Internet Router hast, das Ding hat 4 DVB-C Tuner, die man über das SAT-IP Plugin im VDR als Tuner nutzen kann.

Bei mir läuft ein RPI5 als VDR Server. System auf ssd, Daten auf externer USB3. Empfang hier zwar über einen Kathrein Satip Server, aber als Empfänger sollte ein sundtek stick gute Wahl sein.

Das Argument mit der fehlende vollen Linuxunterstützung für ARM kann ich nicht nachvollziehen. Wer jetzt noch keine Software oder Treiber für ARM bereitstellt, hat eh verschlafen. Mir hat noch nie was bei ARM gefehlt.

Auch für Hausautomation, Fileserver etc. hötte der RPI5 genug Leistung. Ich baue meine VDRSternELEC builds darauf. Na gut, "unglaubliche Geschwindigkeit" ist das nicht

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.

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

Falls es missverständlich war:
Ich habe nie behauptet, dass die Sundtek-Karten und -Treiber oder der Support irgendwelche Probleme machen.
Mir auch nichts derartiges bekannt.

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.

Quote from Sundtek

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.

Da habe ich leider andere Erfahrungen machen müssen, besonders mit Micro-USB-Steckern.
(Und ein Mal hat mich das wirklich Nerven und Zeit gekostet.)
Aber vielleicht mögen mich die USB-Stecker auch einfach nicht ...

Dann ist beim RASPI 500+ ist das Keyboard im Gehäuse integriert.
Das beim tippen nicht zu bewegen, stelle ich mir schwierig vor.

Quote from mhanft

Naja, nachdem meine "Bastelzeit" seit fast 40 Jahren vorbei ist, wollte ich mir mit dem 500+ halt den Luxus gönnen "einschalten und geht" (zumindest ohne Hardwaregebastel - Softwareinstallationen bekomme ich schon noch hin, und Linux-erfahren bin ich auch).

Ich hatte da an ein kleinen Barebone oder Thinclient gedacht.
Der Bastelaufwand hätte sich da maximal auf den Einbau von SSD und Arbeitsspeicher beschränkt, wenn überhaupt.

Quote from mhanft

Ich hab mich nochmal ein bisschen mit ChatGPT unterhalten, und der meinte zuletzt ...

KI ist schon irgendwie faszinierend, hat anscheinend keine Ahnung und schwafelt wie ein Autoverkäufe. (Die letzte Empfehlung ist wohl ein Android-Receiver und kein DVB-Adapter.) Und so recht zum Punkt kommt es auch nicht.
Erstaunlich, wie man es geschafft hat sowas einem Computer beizubringen.

Dabei ist es doch eigentlich ganz einfach:
Damit ein DVB-Adapter funktioniert, müssen eigentlich nur 3 Punkte erfüllt sein:

1. Er muss die gewünschte DVB-Art empfangen können.
2. Eine passende Schnittstelle zum Computer haben.
3. Es muss einen Treiber für das Betriebssystem (hier Linux) geben.

Punkte 1 und 2 sind trivial.

Bei Punkt 3 hilft klassische Suche:
: linux Hauppauge WinTV-dualHD
Das 4. Ergebnis, gleich unter den Hauppauge-Seiten:
https://www.linuxtv.org/wiki/index.php…ge_WinTV-dualHD
Auf der Seite gibt es alle relevanten zum Betrieb unter Linux.
Es gibt anscheinend mindestens 2 Versionen mit gleichem Namen, also auf die Bestellnummer/EAN achten!

Das Linuxtv-Wiki ist übrigens immer einen Blick wert, wenn es um DVB-Karten unter Linux geht.
Keine Ahnung, warum die KI das nicht verlinkt, das wäre mal echt hilfreich gewesen .

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.

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.

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.

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.

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.

Hier meine Erfahrung mit den sundtek USB DVB-S2 Sticks:

Es gibt theoretische Probleme, die aber für für mich in der Praxis keine Probleme sind:

• LD_PRELOAD: OK, ist etwas seltsam, hat bei mir in der Praxis aber nie zu Problemen geführt
• USB-A Anbindung an RPI4: Funktioniert problemlos. Das Ding steht im Speicher, am USB hängen auch noch die Festplatten, ... OK, da rüttelt natürlich auch niemand dran, und der Speicher vibriert auch nicht ....

Und dann noch die (für mich) prakisrelevanten Probleme:

1. Debuggen von VDR: Bei allen Threads, bei denen libmediaclient.so beteiligt ist, gibt es ein: "Backtrace stopped: previous frame identical to this frame (corrupt stack?)". Siehe sundtek, "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" wird von gdb auch im Normalbetrieb (also wenn kein Fehler aufgetreten ist) ausgegeben . Das erschwert die Fehlersuche sehr deutlich, wenn VDR hängt. Ich kann mit gdb dann nicht mehr herausfinden, ob das Problem in einem dieser Threads ist. Ich kann im gdb auch nicht sehen, was VDR macht, bevor VDR die DVB API aufruft . Dass ich nicht mehr sehen kann, was hinter der API im sundtek Treiber passiert, ist aus meiner Sicht weniger kritisch, dafür habe ich ja den sundtek Support.
2. Gelegentlich tritt folgendes auf: Die Antwortzeiten beim Aufruf der DVB API können sehr lange sein, z.B. mehrere Minuten. Vor allem wenn der Empfang schlecht ist. Die Erwartung hier ist, dass solche Anfragen an die DVB API sehr schnell beantwortet werden, auch bei schlechtem Empfang. Die Antwort kann ja dann sein, dass keine Daten verfügbar sind oder ähnlich. Siehe Section Handler hält Locks zu lange . Und ja, die beste Lösung wäre natürlich, den Empfang zu verbessern. Aber bei mir ist der Empfang von Astra-2A halt wetterabhängig.

Also 1 empfinde ich als echten Nachteil, weil es unnötig die Fehlersuche in VDR erschwert.

2 ist jetzt unschön, aber da wäre dann halt die Frage, ob es einen open source Treiber für eine (andere) DVB-S2 Karte gibt, der besser funktioniert. Ich kann diese Frage nicht final beantworten, ich habe nicht alle getestet. Aber ich habe da meine Zweifel.

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.

Quote from Sundtek

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?

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.

Quote from Sundtek

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.

Ich hätte jetzt erwartet, dass ihr das mit den hier gposteten Informationen reproduzieren könnt. Wenn nicht, dann schreibt das doch bitte hier rein.

Ich würde natürlich gerne testen, ob der Fehler auch bei Verwendung einer libmediaclient.so Version mit Symbolen auftritt.

Aber wie gesagt, das wird hier doch sehr off-topic, daher bitte in dem anderen Thread sundtek, "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" wird von gdb auch im Normalbetrieb (also wenn kein Fehler aufgetreten ist) ausgegeben) weiter diskutieren.

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).

Quote from MarkusE

1. Debuggen von VDR: Bei allen Threads, bei denen libmediaclient.so beteiligt ist, gibt es ein: "Backtrace stopped: previous frame identical to this frame (corrupt stack?)". Siehe sundtek, "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" wird von gdb auch im Normalbetrieb (also wenn kein Fehler aufgetreten ist) ausgegeben . Das erschwert die Fehlersuche sehr deutlich, wenn VDR hängt. Ich kann mit gdb dann nicht mehr herausfinden, ob das Problem in einem dieser Threads ist. Ich kann im gdb auch nicht sehen, was VDR macht, bevor VDR die DVB API aufruft . Dass ich nicht mehr sehen kann, was hinter der API im sundtek Treiber passiert, ist aus meiner Sicht weniger kritisch, dafür habe ich ja den sundtek Support.

Diese Problem ist gelöst. Danke, Sundtek

Eigentlich dachte ich, dass ich zu dem Thema schon alles geschrieben hätte, aber anscheinend ist mein erster Beitrag gründlich missverstanden worden. Es ist erstaunlich, was sich für eine Diskussion aus meinem kleinen Hinweis entwickelt hat, denn als mehr als das war der Beitrag auch nicht gedacht.

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!)
Eine Garantie gibt es natürlich nicht, aber mit erprobter Handware funktioniert das eigentlich immer, Regressions sind äußerst selten.
Einen entsprechenden Hinweis hätte ich daher auch bei einer TBS oder DD-Karte gegeben, oder wenn eine sehr neue Kernel-Version benötigt würde.

Der Themenstarter erwähnte ein "RAID 6 mit 8 Festplatten", was er "verkleinern" möchte. Meine Empfehlung bezgl. USB bezog sich darauf, nicht so sehr auf den DVB-Adapter.
Einen Fileserver auf Basis eines Mini-Computers, mit einem Stapels fliegend verdrahteter USB_Festplatten, würde ich mir nämlich nicht an tun.
Allein schon, weil ich bislang keinen USB-SATA_Adapter hatte, bei dem SMART, hdparm und dergleichen funktionierten.
Und dann hatte ich bei USB-Festpalatten halt einfach deutlich häufiger Übertragungsfehler/Abbrüche als bei internen, direkt angeschlossenen Festplatten. Aber da kann ich mit meiner bescheidenen Hardware-Stichprobe auch einfach Pech gehabt haben...

An dem LD-PRELOAD selber ist technisch nichts auszusetzen.
Eine Closed-Source-"Blackbox"-Lib zwischen meinen Open-Source-Programmen und dem Linux-Kernel kommt für mich aber nicht in Frage.
Wenn die Treiber-Anwendung aus rechtlichen Gründen unbedingt Closed-Source sein muss, dann halt meinetwegen, die kann man abschotten.
Aber hätte man nicht wenigstens diese Lib Open-Source machen können? Da wird nun wirklich nichts NDA-Relevantes drin sein.

So, ich hoffe das war jetzt ausführlich genug erklärt.
Das war's nun aber auch endgültig vom mir und ich entschuldige mich bei Themanstarter für das Chaos.