Hi, die Geräte sind unterwegs, es sind tatsächlich nur 4 Stück. Der Treiber sollte zur Zeit ausreichend sein wird aber auch noch etwas poliert werden.
Nach der damaligen Ankündigung hat mich leider die Grippe 2 Wochen flachgelegt und dann kamen andere große Projekte auf uns zu sodass es ruhen musste.
Hoffe dass die nächsten mehrfach TV Tuner dann im September kommen. Es tut sich sehr viel bei uns auch in anderen Bereichen.
Guter Fund, ich hatte mich ja für eine der Test-Karten von Sundtek beworben, aber daraus ist leider bislang nichts geworden. Wenn es für dich funktioniert und ich es im Paket ergänzen soll, lass es mich wissen.
Nächste Woche gehen die mit nach Deutschland, sorry damals hatte mich plötzlich eine starke Grippe heimgesucht und ich war 2 Wochen weg - und musste danach andere Dinge nachholen. Bis zum Eintreffen der Geräte wird's aber sicherlich noch 2 Wochen dauern. Werde diejenigen die damals geschrieben haben gegen Ende nächster Woche nochmal extra anschreiben.
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.
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.
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.
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.
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.
