Beiträge von Salami

  • DVBSky T9580 DVB-T/T2/C and DVB-S2 Dual PCIe

    Zitat von fadi2013


    das heisst ja nicht , dass es nicht funktioniert.


    Zumindest bietet der Hersteller Linux-Treiber an, was viele andere nicht machen.


    Zu meiner alten Eumex 50irgendwas ISDN Telefonanlage gab es auch mal closed source Treiber für Suse < 10 (und kleiner 10 heißt hier nicht für alle Suse kleiner 10 Versionen, sondern nur für eine einzige ganz bestimmte. Vielleicht Suse 8.0 oder so).
    Glaubst du etwa, diese Telefonanlage ist heute unter einer aktuellen Suse oder sonstigen Distritbuition noch benutzbar?



    Wenn ein closed source Treiber also unter einer oder ganz wenigen Linux Distributionen funktioniert, dann sagt das gar nichts aus.
    Entscheidend ist, wie lange der Support für den closed source Treiber auch für spätere Distributionsversionen aufrecht erhalten wird und wenn es da schon ca. 6 Monate nach Produkteinführung Probleme mit modernen Distributionen gibt, dann ist da nicht viel zu erwarten.


    Mir sind nur sehr wenige Closed Source Treiber bekannt, die langfristig supportet werden.
    Darunter gehören z.B. die von NVidia, aber das gilt eben nicht für jede Hardware.


    EDIT:


    BTW
    was die Cine CT betrifft, die ich mir nach der T9580 gekauft habe, so läuft die seit dem ersten Tag ohne nennenswerte Probleme.
    Wer also DVB-C benötigt, dem würde ich auch eher zur Cine CT raten.
    Und wer beides benötigt, DVB-C und DVB-S2, der ist vielleicht mit zwei Karten jeweils für DVB-C und DVB-S2 besser beraten.
    Natürlich kostet das wesentlich mehr, das ist der einzige Nachteil, die CineCT ist bswp. doppelt so teuer, aber dafür sind die Treiber Open Source und für DVB-S2 wird sich sicher auch eine reine Open Source Karte finden lassen.

  • DVBSky T9580 DVB-T/T2/C and DVB-S2 Dual PCIe


    Debian Wheezy ist eine alte Distributionsversion vom 4. Mai 2013 und verwendet noch einmal eine wesentlich ältere Kernelversionen als Mai 2013. Das ist ein Zeitpunkt, als diese Karten gerade auf dem Markt erschienen sind.
    Und jetzt, mit dem aktuellen Ubuntu 13.10 und relativ neuem Kernel läuft sie nicht.


    Kannst du also, gerade bei closed Source Modulen und schlechtem Support so eine Karte empfehlen, wenn schon bei Distributionen innerhalb der Gewährleistungszeit abzusehen ist, dass die Karte unter recht neuen Distributionen oder zukünftigen Debianversionen nicht mehr laufen wird?


    Ich denke nicht und ich denke, dass du mit dieser Karte ein paar Debianversionen später noch deine Probleme bekommen wirst. Gerade wegen dem closed source Modul.
    Falls du natürlich kein DVB-C benötigen solltest, besteht natürlich die Möglichkeit, dass du keine Probleme zu erwarten hast, denn das closed source Modul ist nur für DVB-C notwendig.



    Ich kann dir also nur den Rat geben, die Karte noch umzutauschen, solange du noch die Möglichkeit dazu hast.



    PS: Es gibt übrigens keinen Grund ein ganzes Posting zu zitieren.
    Man zitiert nur die wesentliche Stelle die für die Antwort nötig ist, das reicht vollkommen.

  • Cine C/T - Umschalten dauert 5-7 Sekunden

    Gibt's für den VDR auch ein auf den Desktop Einsatz zugeschnittenes Clientprogramm?



    Das hier sieht ja jetzt nicht so prickelnd aus:
    http://www.youtube.com/watch?v=cpdQKDXXh1Q
    Keine Mausbedienung und ein Menü das für eine Fernbedienung optimiert zu sein scheint. Das ist so grausig wie ein Konsoleninterfaces für Spiele auf einem PC.
    Auf dem Desktop PC habe ich aber eine Tastatur und eine Maus und möchte dafür auch einen optimierten Client.
    Wenn es für den VDR einen für den Desktop optimierten Client gibt, dann würde ich den natürlich gerne ausprobieren.

  • Cine C/T - Umschalten dauert 5-7 Sekunden

    Nein, ein CI Modul habe ich nicht.



    Zitat


    Und Du bist hier im VDR-Portal richtig?


    Kennst du ein deutschsprachiges Linux Forum das sich auf TV schauen stärker spezialisiert hat als dieses hier?
    Also denke ich schon, dass ich hier richtig bin, völlig unabhängig davon ob ich jetzt vdr einsetze.
    Treiberprobleme sind nämlich überall gleich, daran ändert auch vdr nicts, falls es ein Treiberproblem sein sollte.

  • Cine C/T - Umschalten dauert 5-7 Sekunden

    Ich bin gerade beim Ausprobieren meiner neuen Cine C/T DVB-C Karte und stelle gerade fest, dass der Wechsel auf einen anderen Sender sehr lange dauert.
    Gemessen sind es je nach Sender ca. 5-7 Sekunden, unter 5 Sekunden sind es aber so gut wie nie.


    Ist das bei dieser Karte normal?
    Von meiner alten Mystique CaBiX-C2 DVB-C bin ich jedenfalls wesentlich schnellere Umschaltzeiten gewöhnt.


    Könnte dies eventuell am verwendeten TV Client Me-TV liegen, denn den benutze ich zum Ersten mal?
    Bisher habe ich immer Kaffeine benutzt, aber bei Kaffeine schlägt der Sendersuchlauf mit dieser Karte leider fehl
    und andere DVB-C Programme für den Einsatz auf dem Desktop, welche auch eine schöne Senderliste zwischen denen man bequem hin und herschalten kann, sind mir nicht bekannt.




    Woran könnte das also liegen, dass die Umschaltzeiten 5-7 Sekunden dauern?

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Zitat von henfri


    Ist das Problem/ein Workaround bekannt?


    Als Workaround würde ich versuchen ob das Problem auch dann auftritt, wenn der Treiber nicht geladen ist.
    Falls das nicht der Fall sein sollte, dann könntest du das Modul für den Autoloader blacklisten und bei Bedarf laden
    sobald du die TV Karte benötigst, wenn du sie dann nicht mehr benötigst, dann entlädst du das Modul einfach wieder mir rmmod.

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    Zitat von S:oren

    Salami: Wuerdest Du bitte diese unterschwelligen Vorwuerfe unterlassen. Die sind - meiner Meinung nach - hier ueberhaupt nicht angebracht.


    Unterschwellig ist nur was du daraus machst, ich habe nichts dergleichen behauptet und es wie ich bereits schrieb dies nur der Vollständigkeit halber dazugeschrieben und es auch nicht hier auf diese Treiber hier bezogen. Punkt.



    Zitat


    Ich habe so das Gefuehl, viele an dieser Diskussion Beteiligte haben ueberhaupt keine Ahnung, wie die Entwicklung von linux-media-Treibern laeuft. Die Entwicklung parallel zum mainline-Kernel (im media-build-Repository auf linuxtv.org) ist das offizielle Vorgehen der media-Maintainer, das Austauschen aller Kernel-Module unterhalb von drivers/media ist somit auch der offizielle Weg zu Entwicklung und Test von media-Treibern. Das hat ueberhaupt nichts mit Profilierung zu tun. Der Vorteil dieses Vorgehens ist, dass man auch fuer altere Kernel-Versionen die neuesten media-Treiber bauen und integrieren kann, der Nachteil ist, dass man als unabhaengiger Entwickler mindestens 2 Kernel-Versionen braucht, um Patches ins mainline-linux integriert zu bekommen. Wenn ein Maintainer also mal einen Treiber "kaputtgespielt" hat (was leider in letzter Zeit immer mal wieder vorgekommen ist und auch Kritik von verschiedenster Seite eingebracht hat), dann hat man als Entwickler quasi keine Chance, diesen Bug in angemessener Zeit zu fixen. Auch eine zeitnahe Weiterentwicklung des Treibers im mainline-Linux ist quasi unmoeglich.


    Danke für die Aufklärung, aber wenn dem so ist und das media-build Repo der offizielle Entwicklungszweig der TV Sachen im Linux Kernel ist, und der Zweig des Linux Kernels nur das "stable" Zeugs hat, wieso gibt es dann im mainline Kernel API und ABI Brüche wie es Oliver hier erwähnt hat:
    Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

  • DVBSky T9580 DVB-T/T2/C and DVB-S2 Dual PCIe

    Da ich mir ja vor ein paar Tagen eine DVBSky T9580 TV Karte gekauft habe und inzwischen wieder umgetauscht habe,
    wollte ich euch hier mal meine Erfahrungen bezüglich dieser Karte und Linux berichten.


    Noch ein kleiner Hinweis.
    Als ich die Karte noch hatte, habe ich schon ein Posting wie dieses hier erstellt, hierbei waren auch einige Konsolenausgaben
    einiger Kommandozeilenbefehle vollständig dabei, aber als ich das Posting dann im Forum abschicken bzw. speichern wollte, kam
    die Aufforderung dass ich mich erneut einloggen soll. Als ich dies dann tat, war mein komplettes Posting weg und der Zurückbutton lieferte auch nicht mehr das Geschriebene.
    An dem Tag war ich dann auf die Forensoftware so sauer, dass ich gar kein Posting mehr erstellt habe.
    Am nächsten Tag habe ich dann die Karte zurückgeschickt ohne die Kommandozeilenbefehle erneut aufzurufen und die Konsolenausgaben
    zu retten, es ist also einiges an Information verloren gegangen, die ich in meinem ursprünglichen Posting drin hatte und ich durchaus als wichtig erachte.
    Nun aber zurück zu meiner Erfahrung mit dieser Karte:



    Die TV Karte besitzt 3 Chipsätze.


    Der

    Code
    M88DS3103
4K51188.1
FPC1221NQ


    Chipsatz ist für den DVB-S2 Empfang zuständig, diesen konnte ich nicht testen, da ich hier nur DVB-C habe.


    Der

    Code
    Si2168 30
1253A00081


    Chipsatz ist für den Empfang von DVB-T(2) und DVB-C zuständig.
    Testen konnte ich nur DVB-C, weil der DVB-T Empfang hier ohne Dachantenne mangelhaft liegt,
    dies hat aber nichts mit der Empfangsqualität der Karte zu tun, sondern trifft auf alle Geräte in meinem Haus zu.



    Gegenüber dem PC werden die Signale beider Chipsätze durch folgenden Chipsatz repräsentiert und durchgeleitet:

    Code
    Conexant
PCIe A/V Decoder
CX23885-15Z
PFAC6621B
1249 CN



    Out of the Box ohne die Installation der Treiber auf der DVBSky Webseite lief die Karte unter Linux Kubuntu 13.10
    nicht, es sind also keine passenden Treiber im Vanilla Kernel oder dem nachgepatchten von Kubuntu enthalten.
    Ob es mal Open Source Treiber im Kernel geben wird, wird die Zukunft zeigen müssen.
    Bezüglich des Si2168 Chipsatzes sieht es da momentan eher schlecht aus, denn dieses liegt bei den Treiber des Herstellers nur als binäres Modul ohne Quellcode vor. Aber dazu komme ich gleich.



    Also habe ich auf der Webseite des Herstellers http://www.dvbsky.net/ das media_build_bst_130806 Linux Treiberpaket
    für Kernel 3.5.x ~ 3.11.1 downgeladen und es nach der Anleitung
    http://www.dvbsky.net/download…river_installation_en.pdf
    versucht zu installieren.
    Dies hat auch geklappt, allerdings hätte man den 2. Schritt

    Code
    "Check and choose one of the target systems, run ‘uname -a’ to get os Information."


    in ein IF Bedingtes Skript reinpacken können.


    Anschließend wurde die Installation mit einem sudo make install abgeschlossen.


    Bedauerlich an diesem media_build System war, dass darin nicht nur die Treiber für die DVBSky T9580 enthalten waren,
    sondern auch weitere Treibermodule für ALLE Karten des Herstellers von DVBSky.
    Wer also sein System nicht mit unnötigem Ballast zumüllen möchte, hat hier praktisch keine Chance selektiv die Treiber nur für die benötige Karte zu installieren,
    zumindest geht dies nicht ohne großen Aufwand die ganzen Buildscripte zu überarbeiten.


    Auch war nicht klar, ob man den 5. Schritt

    Code
    Copy firmware file dvb-fe-ds300x.fw and dvb-fe-ds3103.fw to /Lib/Firmware directory. Firmware
file can be downloaded from support web page in www.dvbsky.net.
Unzip it then copy files.


    ausführen sollte, denn es befanden sich nirgends Hinweise dazu, ob genau diese Firmware nun für die eigene T9580 Karte
    oder für andere Karten des Herstellers notwendig waren, also habe ich notgedrungen auch diese Firmware installiert.
    Hinweis: das closed source Treibermodul für den Si2168 Treiber, welcher für den Empfang von DVB-C notwendig ist,
    liegt bereits als compilierte binäre Objektdatei unter den Namen

    Code
    sit2.o.dvbc_x64  
sit2.o.dvbc_x86  
sit2.o.x64  
sit2.o.x86


    vor und davon wird dann über den oben erwähnten 2. Schritt

    Code
    "Check and choose one of the target systems, run ‘uname -a’ to get os Information."


    die passende Moduldatei, je nachdem was man für ein System einsetzt, 32 Bit oder 64 Bit, mit DVB-C Support oder ohne,
    ausgewählt und nach sit2.o kopiert.
    Auf diese sit2.o Datei greifen dann die restlichen Scripte des Buildprozesses zu.



    Also die die Treiber und die Firmware also erfolgreich installiert waren, habe ich das System dann neu gebootet.
    Doch nach dem Booten kam dann die Ernüchterung, denn es gab schon, wie dmesg zeigte, die erste Fehlermeldung beim Laden der neuen Treibermodule:


    Code
    cx2341x: Unknown symbol v4l2_ctrl_handler_init_class (err 0)


    Aber dies war noch kein Problem, denn in der Anleitung war dieser Fall ganz unten unter FAQ erwähnt.
    Als Lösung wurde mir daher vorgeschlagen, den kompletten

    Code
    /lib/modules/`uname -r`/kernel/drivers/media


    Ordner zu löschen und mit make install die Treiber noch einmal zu installieren.
    Was ich dann auch tat.
    Unschön ist hier, dass dadurch praktisch die ganzen original Module der Linux Distribution in diesem Verzeichnis gelöscht werden
    und dann durch das media Build Systems des Herstellers ersetzt werden.
    Sollte man hier mal zwei verschiedenen Karten zweier verschiedener Hersteller zum Laufen bekommen wollen und beide würden so einen Austausch für ihre Karte verlangen,
    dann wäre es praktisch ohne manuellen Eingriff nicht möglich, beide Karten zum Laufen zu bringen.
    Laien dürften hieran sicher scheitern.



    Als all das erledigt war, habe ich dann das System erneut gebootet.
    Dies mal wurde die Karte dann auch erkannt, es waren wie erwartet, zwei Verzeichniseinträge unter

    Code
    /dev/dvb/adapter0
und
/dev/dvb/adapter1


    sichtbar und lspci mit der angehängten verbose Option spuckte dann für diese Karte folgendes aus:



    Eine Ausgabe von dmesg habe ich leider vergessen zu erstellen und da ich die Karte inzwischen nicht mehr habe, kann ich das auch nicht mehr nachreichen.
    Die passenden dmesg Einträge in /var/log sind leider inzwischen auch nicht mehr vorhanden.




    Nun ging es weiter mit der Sendersuche.


    Code
    sudo scan -a /dev/dvb/adapter1/ -f /dev/dvb/adapter1/frontend0 -A 2 tuning_de-Kabel_BW.conf > channels_scan.conf


    Scheiterte kläglich. Hier war das Problem, dass zwar adapter1 der für den DVB-C Empfang zuständig war, als Option übergeben wurde,
    aber scan machte daraus aus mir unerfindlichen Gründen immer wieder aus adapter1 adapter0 und dann kam die Fehlermeldung

    Code
    WARNING: frontend type (QPSK) is not compatible with requested tuning type (OFDM)


    was ja auch logisch war, denn auf adapter0 war der Chipsatz der für DVB-S zuständig ist.


    Leider habe ich nicht mehr die komplette Konsolenausgabe mit dem genauen Wortlaut des obigen Scanbefehls, aber ich hoffe, meine Schilderung genügt.


    Die anderen Scanprogramme wie dvbv5-scan und dvbscan scheiterten ebenfalls, die Konsolenausgaben hierzu fehlen leider ebenfalls.
    scan-s2 war auf Kubuntu nicht verfügbar, zumindest habe ich kein passendes Paket gefunden und auf meinem System war es nicht installiert.


    Das einzige was funktionierte war w_scan und davon habe ich glücklicherweise noch die Konsolenausgabe gerettet, weil ich den Ouput in eine Textdatei gespeichert habe:


    Mit w_scan konnte ich alle Sender finden, allerdings konnte keines der Abspielprogramme etwas mit den channel.conf Dateien anfangen und ich habe hier wirklich alle relevanten durchprobiert, die
    w_scan erstellen kann.
    Also diese hier:

    Code
    -M      mplayer output instead of vdr channels.conf
       -X      tzap/czap/xine output instead of vdr channels.conf
       -x      generate initial tuning data for (dvb-)scan



    mplayer 1 lieferte folgendes:


    mplayer 2 dieses:


    Diese beiden Fehlermeldungen von mplayer 1 & 2 waren zu erwarten, denn mplayer verwendet von Haus aus immer /dev/dvd/adapter0
    Mit mplayer2 soll es aber möglich sein den Adapter auszuwählen:


    Aber das scheiterte ebenfalls oder ich habe die Angabe zur Kartennummer falsch übergeben.
    Allerdings habe ich hier einige Möglichkeiten durchprobiert, sie scheiterten alle.



    Mit kaffeine war es nicht möglich einen Senderdurchlauf durchzuführen.
    Ich hatte zwar adapter0 und adapter1 zur Auswahl, aber der Suchlauf brach nach ca. 3 Sekunden sofort ab.
    Als Fehlermeldung konnte ich das hier retten:

    Code
    kaffeine(3318) DvbDevice::frontendEvent: tuning failed


    zap lieferte dieses:

    Code
    zap -adapter 1 -channels .szap/channels.conf "arte"
Using frontend "Sit2 DVB-T2/C", type DVB-C
status | signal 1817 | snr 0000 | ber 00000000 | unc 00ff00ff |


    und das darauffolgende mplayer Kommando, das also in Kombination mit zap verwendet wurde ergab dieses und auch kein Bild:

    Code
    mplayer /dev/dvb/adapter1/dvr0 
MPlayer2 UNKNOWN (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.


Playing /dev/dvb/adapter1/dvr0.


    Ein Versuch mit vlc, bei dem ich die Frequenz und Symbolrate eines existierenden Senders manuell eingab, scheiterten ebenfalls und ergab diese Fehlermeldung:

    Code
    VLC:
dtv error: tuning to 362000000 Hz failed
main error: open of `dvb-c://frequency=362000000:modulation=256QAM:srate=6900' failed


    me_tv ergab diese Fehlermeldung bei der Verwendung der von w_scan erstellten channel.conf Dateien:

    Code
    Fehler:Invalid parameter count on line 1


    Und ich habe versucht hier me_tv alle channel Formate unterzuschieben, die ich mit w_scan erstellt habe.
    Alle scheiterten.
    Ebenfalls scheiterte der me_tv eigene Sendersuchlauf.
    Vielleicht hängt dies auch damit zusammen, dass auch schon scan trotz richtigem adapter den Falschen für die Suche ausgewählt hat,
    denn ich kann mir nicht vorstellen, dass dieser Bug an scan liegt, denn es gibt sicher schon seit Jahren Linuxbenutzer, die mehr als eine TV Karte im
    Rechner verbaut haben und dann müsste scan eigentlich ausgereift genug sein, um den richtigen adapter auszuwählen
    Ich schätze daher, dass der Bug irgendwo in den Treibern zu dieser Karte steckt und dies dann einfach an scan sowie alle anderen Programme, inkl. der Abspielprogramme die ich getestet habe durchgereicht wird.




    Wie dem auch sei, mir ist es auf jeden Fall in keinster Weise gelungen dieser Karte unter Linux irgendein Bild mit DVB-C zu entlocken.
    Mehr als ein Sendersuchlauf ging nicht. ich habe die Karte daher wieder umgetauscht.


    Empfehlen kann ich diese Karte somit auch keinem Linuxuser. Zumindest keinem, der die DVB-C Funktion verwenden möchte.


    Übrigens, wenn man w_scan ohne -c Option auswählt, also nach DVB-T gesucht werden soll, dann erhält man folgende Meldung von w_scan:

    Code
    /dev/dvb/adapter0/frontend0 -> "Montage DS3103/TS2022" doesnt support TERRESTRIAL -> SEARCH NEXT ONE.
  /dev/dvb/adapter1/frontend0 -> "Sit2 DVB-T2/C" doesnt support TERRESTRIAL -> SEARCH NEXT ONE.


    Es besteht also die Möglichkeit, dass ein Sendersuchlauf bezüglich DVB-T gar nicht möglich ist.
    In so einem Fall würde dies dann bedeuten, dass man eine channel.conf manuell anlegen oder von irgendwo kopieren müsste, um über DVB-T TV schauen zu können.
    Falls das zutrifft, dann wäre diese Karte eigentlich auch für den Empfang von DVB-T unter Linux nicht zu empfehlen.


    Möglicherweise gibt es mit der DVB-S2 Funktion der Karte die geringsten Probleme, denn hier scheinen die Treiber komplett Open Source zu sein
    und vielleicht klappt da der TV Empfang dann besser. Auch dafür sprechen könnte der Faktor, dass die Treiber AFAIK irgendwo in China entwickelt
    und programmiert wurden und da gibt es kein DVB-C oder DVB-T, wohl aber AFAIK durchaus DVB-S. Diese Funktionen müsste der Programmierer also ungetestet quasi blind programmieren.
    Falls das der Fall sein sollte, dann erklärt dies dann auch die Probleme die ich mit dieser Karte habe.


    Bestenfalls ist diese Karte also lediglich für DVB-S2 Nutzer oder Leute interessant, die einen Open Source für den SI2168 Chipsatz schreiben wollen.
    Allen anderen kann ich von dieser Karte nur abraten.
    Falls DVB-S(2) funktionieren sollte und man für die nächsten 5 Jahre auf alle Fälle via DVB-S TV schauen sollte, dann könnte die Karte ja durchaus interessant sein,
    vorausgesetzt natürlich, dass sich die Treibersituation bezüglich DVB-T(2) und DVB-C in den nächsten Jahren verbessert.


    Momentan, also Stand Oktober 2013 ist diese Karte absolut NICHT für DVB-C und DVB-T(2) unter Linux zu empfehlen.




    Dann noch etwas, die Mystique SaTeCaBiX des DVBShops ist absolut identisch zu der DVBSky T9580.
    Sie hat voraussichtlich lediglich eine andere PCI ID, so war das zumindest bei meiner anderen Mystique PCI Karte, die bis auf die PCI ID identisch mit der KNC One war.
    Dies bedeutet also, dass man mit der Mystique SaTeCaBiX die gleichen Probleme unter Linux haben wird, wie ich mit der T9580.
    Dazu kommt dann allerdings noch, dass die Treiber für die andere PCI ID erweitert werden müssen, auch dies war bei meiner alten Mystique Karte der Fall.
    Wenn man also die T9580 oder Mystique SaTeCaBiX kaufen möchte, dann würde ich trotz der 5 € mehr eher die T9580 empfehlen, denn dann muss man nicht auch noch wegen der PCI ID
    einem aktuellen Treiber hinterherrennen.



    Ich persönlich habe mir nun eine Cine CT für den DVB-C Empfang gekauft. Ich werde sie allerdings erst noch testen müssen.
    Sie ist leider auch mehr als doppelt so teuer und kann kein DVB-S(2) was ich in meinem Fall durchaus gebrauchen hätte können.
    Aber wer DVB-C und DVB-S(2) empfangen können möchte, der ist momentan definitiv besser beraten, wenn er jeweils eine TV Karte für DVB-C und noch eine für DVB-S(2) kauft und beide in den Rechner einbaut.
    Denn diese Kombikarte funktioniert unter Linux für DVB-C momentan ja leider schlichtweg nicht und ist für diesen Einsatzzweck absolut unbrauchbar.


    PS:
    Falls jemand diese Karte unter Windows nutzen möchte.
    Da lief sie halbwegs, allerdings machte der mitgelieferte TV Player erhebliche Probleme beim Sendersuchlauf einiger Sender unterhalb von 130 MHz und mit HDTV gab es nach ein paar Sekunden Aussetzer beim Ton.
    Das Problem konnte ich mit der Demoversion des DVBViewers umgehen, wenn man also die Karte unter Windows einsetzen möchte, dann sollte man in den Preis auch mit einplanen, dass man auch noch den DVBViewer Pro dazukauft,
    denn sonst wird man auch unter Windows mit dieser Karte keine Freude haben.
    Ich selbst hatte vor diese Karte ausschließlich unter Linux einzusetzen, denn auf dem Rechner auf dem ich sie verwenden wollte, ist gar kein Windows installiert.


    So, ich hoffe nun mit diesem Beitrag bezüglich dieser Karte und der baugleichen Mystique SaTeCaBiX und dem Linux Support etwas Licht ins Dunkel gebracht zu haben.

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

    jasminj


    Danke für den Hinweis auf die Links.



    Zitat von Mreimer

    Optimum wäre, wenn das jemand macht, der auch die Hardware hat.


    Warum macht das eigentlich nicht DD, der Hersteller?
    Mit Linux Support werben sie ja, da könnten sie ja durchaus einen Entwickler anstellen, der das Zeugs in den Kernel merged.


    Zitat von Mreimer

    Der einzig richtige Weg wäre aber, die Treiber irgendwie in den Kernel zu bekommen. Das letzte Mal habe ich mich aktiv um Treiber-Installation gekümmert als ich noch Windows genutzt habe. Eigentlich sehe ich es gerade als einer der großen Vorteile von Linux an, dass eine aktuelle Distribution mit fast allem, was man im Alltag an Treibern braucht, geliefert wird.


    Ich bin ganz deiner Meinung.
    Was aber noch dazu kommt ist, das ich bei meiner letzten Installation eines Media Build Zweigs den kompletten Ordner ersetzen musste* und jetzt stelle man sich mal vor, es gibt zwei verschiedene Hersteller, die zwei Produkte haben, die ebenfalls zwei eigene Quellcodezweige haben und erwarten, dass man die irgendwo in das lib/modules/.... Verzeichnis packt und jeder von denen besteht darauf, dass man den Originalcode aus dem Weg räumt. Dann ist es praktisch für Laien ausgeschlossen, dass sie beide Karten gleichzeitig zum Laufen bekommen können.


    * Wie ich gelesen habe, soll das nun ab jetzt ja nicht mehr nötig sein, das ist eine gute Entwicklung.


    Auch hoffe ich jetzt mal, das solche Außerkernelentwicklungen nicht zum Profilieren benutzt werden, sondern wirklich technische Gründe wie ständig sich ändernde ABIs dahinterstecken, denn so etwas habe ich schon bei einem anderen Open Source Projekt erlebt.
    Ein einzelner Entwickler hatte das Gefühl, dass er großen Projekt untergeht und deswegen lagerte er seine Arbeit aus, mit einer schönen Webseite, damit jeder sehen konnte was ER gemacht hat um von der Community Ansehen und Anerkennung zu gewinnen.
    Ich denke solche Entwicklungen schaden nur einem Projekt als Ganzes. Ich gehe jetzt mal nicht davon aus, dass das hier der Fall ist, ich erwähne es nur mal der Vollständigkeit halber.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    @all


    Also erstmal Danke an euch alle, ich habe mir die Cine CT jetzt bestellt und das Media Build schonmal vorsorglich installiert, so dass ich sehen konnte ob das klappt, was es dann auch tat.
    Jetzt muss ich nur noch warten bis die Karte da ist, dann kann ich sie einbauen, das Modul laden und gleich mal testen.




    Zitat von HTPC-Schrauber


    Dennoch:
    Die Cine CT hat einen Open Source Treiber und benötigt in aktuellen Hardware-Versionen keine zusätzlich geladene (Closed Source) Firmware. Die Firmware befindet sich im Flash auf der Karte und muss nicht geladen werden.
    Somit erfüllt sie einzig die Forderung nach OOTB mit Vanilla Kernel nicht.


    Ja, ich schätze ich werde da einfach noch etwas Geduld zeigen müssen, es besteht zumindest die Hoffnung, dass die Treiber irgendwann im offiziellen Kernel landen.
    Das sie keine extra Firmware benötigt war für mich ein gewichtiges Argument Kartenintern stört die mich nicht.



    Zitat


    Ich glaube es gibt keine PCIe DVB-C Karte am Markt, die Deine Anforderungen vollständiger erfüllen kann.


    Ja, das musste ich nach langer Suche leider auch feststellen.
    Die Terratec hätte ich noch probieren können, aber die braucht leider extra CS Firmware und preislich ist die auch schon recht teuer, so dass die Cine CT schon doch das bessere Angebot und die bessere Wahl ist.



    Es ist irgendwie Schade, dass es für PCIe so wenige DVB-C Karten gibt. Bei PCI war die Auswahl wesentlich größer. Bleibt zu hoffen, dass sich das in Zukunft bessert.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von mini73

    Cine CT = Digital Devices DuoFlex CT = Linux4Media...
    Wir reden eigentlich die ganze Zeit über diese Karte...


    Lars.


    Wenn das die gleiche Karte ist, dann wäre das ja super, denn dann würde das bedeuten, dass zumindest die Chance besteht, das die auch out of the Box funktioniert, wie in diesem Wiki Artikel beschrieben.
    Einziger Knackpunkte könnte das hier sein:

    Zitat


    Also a more recent card (miniPCIe, or Cine C/T/S2 card) might require it.


    Auf der Webseite von Digital Devices ist das halt etwas verwirrend, da beide Karten mit unterschiedlichen Namen getrennt aufgeführt werden.
    siehe:
    http://www.digitaldevices.de/DD-DVB-Komponenten.html


    Der einzige Anhaltspunkt, dass das die gleichen Karten sind, sind eigentlich nur die Bilder. Da sehen die beiden Karten, das Erweiterungs Flex Modul mal weggedacht, ziemlich identisch aus.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von Copperhead


    In diesem Fall eben nicht.


    Wirklich weiterentwickelt wird der Treiber nur von Ralph Metzler bzw. Oliver Endriss. Der letzte Commit von einem der beiden ist aber der 27.07.2011. Alle Commits inklusive des letzten vom 31.01.2013 sind nur Anpassungen an neue neue Kernelversionen.
    Ralph Metzler bevorzugt es aber, den Treiber als einzelnes Tarball zu veröffentlichen: http://www.metzlerbros.de/dddvb/


    Hm, okay. Das erklärt die Sache dann etwas.



    Mal aber eine andere Frage um wieder zurück zum Ursprünglichen Thema zu kommen.


    Was haltet ihr von der Digital Devices DuoFlex C&T?


    Hier, auf folgender Seite steht nämlich folgendes:

    Zitat


    Update July 2013: Kernel driver support is a mess! After the driver author (Oliver Endriss aka UFO) submitted to mainline, mainline was refactored in a way which broke the drivers for many devices. For now, the author does not want to work on fixing this, and instead provides instructions on patching in the dev version. This does not always work for the latest kernels. If you are contemplating buying this hardware, prepare for extra frustration before everything works.


    [UPDATE May 2013: AFAICT, recent(-ish - after 3.6.x at least) kernels have support for DuoFlex C/T out-of-the box, but if you have a CI you will need the media_build_experimental drivers below. Also a more recent card (miniPCIe, or Cine C/T/S2 card) might require it. So, unless you have a CI, test in-kernel drivers first, then please report here!]


    http://www.linuxtv.org/wiki/in…tal_Devices_DuoFlex_C%26T


    Das CI Modul brauche ich ja nicht und ohne das CI Modul soll die Karte out of the Box mit dem Vanilla Kernel funktionieren, insofern wäre das ja eine Option für mich, sofern die Angaben stimmen.
    Wer hat denn Erfahrungen mit der DD DuoFlex C&T und kann dazu etwas näheres erläutern?



    EDIT:


    Die TerraTec Cinergy T PCIe Dual scheint auch recht interessant zu sein.
    Auf Amazon gibt's dazu auch eine Rezension die sich auf den Linux Support bezieht und da scheint die Karte ohne Probleme zu funktionieren.
    http://www.linuxtv.org/wiki/in…raTec_Cinergy_T_PCIe_dual


    Hat die hier jemand und kann zu dieser etwas sagen?


    Das für DVB-C nur ein Tuner geht, würde mich in diesem Fall nicht stören. Denn wie schon gesagt, ein Dual Tuner ist für mich nicht so wichtig.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von chriszero

    Ist ja nicht so das wir hier kein gut sortiertes Forum sind...
    Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)?


    Danke für den Link.


    Auf den ersten Blick sage ich mal oh je, wenn ich das schon lese:

    Zitat


    Es empfiehlt sich, vor "make install" die "media"-Verzeichnisse unter
    - /lib/modules/<kernel-version>/kernel/drivers
    - /lib/modules/<kernel-version>/kernel/drivers/linux/drivers/staging
    aus dem Weg zu räumen, d.h. aus "/lib/modules/..." heraus zu verschieben! (Löschen ist nicht zu empfehlen, da man den alten Zustand evtl. wiederherstellen möchte.)


    Dieses media-build Zeugs mußte ich auch bei meiner DVBSky T9580 einsetzen und da war das auch so, dass ich ein riesen Verzeichnis unter /lib/modules/kernelversion.... aus dem Weg räumen mußte,
    damit die Treiber überhaupt fehlerfrei geladen werden konnte. Natürlich war da auch dann das binäre CS Treibermodul für den Si2168 Chipsatz dabei, aber das war nicht das einzige, was mich an diesem Media Build Zeugs gestört hat.
    Grundsätzlich fand ich das ziemlich übel, dass hier riesige Bestandteile der Kernelmodule überhaupt ersetzt werden.
    Wenn in denen ein Bug oder eine Sicherheitslücke ist, dann wird der normalerweise über den normalen Updatepfad der Distribution bezügl. Linux Kernel spezifische Pakete gestopft, das gleiche kann ich für diesen Media Build Wulst aber nicht behaupten.
    Da ist es dann erforderlich, dass die Media Build Macher diese Aufgabe übernehmen und das ist eben fraglich, wenn die sich nur um DVB spezifische Sachen Sorgen machen.
    Denn dummerweise war in diesem Ordner nicht nur das DVB Zeugs, sondern auch Sachen die USB usw. betreffen.
    Auch war es so nicht möglich nur die Karte spezifische Änderungen vorzunehmen, denn damit wurde ja leider fast alles ersetzt.


    Viel lieber wäre mir da ein diff Patch der nur die jeweilige Karte betrifft und nichts anderes und den ich dann gegen die offiziellen Kernel Source patche und fertig.






    Zitat von Copperhead


    In dem Fall nicht. Der Treiber wird einzeln als Tarball verteilt, welches gegen die Kernel Header gebaut wird. Soweit ich das mitbekommen habe, ist es gar nicht so einfach einen Treiber in den Kernel zu bekommen


    Der Punkt dass es nicht so einfach ist, einen Treiber in den offiziellen Kernel zu bekommen hat doch nichts damit zu tun, dass es nicht bequem wäre, wenn der Treiber in den offiziellen Kernelsourcen wäre.
    Es sei denn du verstehst unter Bequemlichkeit beim Coden schlampen zu können, schlechter Code hat es nämlich in der Tat schwer in die offiziellen Kernelsourcen zu wandern.
    Guter Code wird eigentlich recht unproblematisch angenommen.




    Zitat


    Das kann jeder behaupten.


    Oberflächlich könnte das jeder, das ist richtig.



    Zitat


    Ach, jetzt rede ich also ahnungslosen Unsinn? Entschuldigung, ich paketiere diesen Treiber für VDR4Arch und im Gegensatz zu anderen Distributionen Out-of-Tree. Wenn du auch nur ein bisschen Ahnung hast, weißt du, dass das gar nicht so einfach ist.
    Also ahnungslos bin ich sicherlich nicht.


    Außerdem sehe ich nicht ein, mich von dir beleidigen zu lassen. Mäßige deinen Ton oder du kannst zusehen, wie du zurecht kommst.


    Bedaure, aber das was du zum Commit geschrieben hast IST Unsinn, das kannst du jetzt schon runterschlucken anstatt hier den Beleidigten zu spielen. Zumal das keine Beleidigung ist, da ich mich auf die von dir geäußerte Sache bezog.. Außerdem lies dir hier in diesem Thread mal durch, was andere zu meinen Beiträgen geschrieben haben, da wird einem Totaler Quatsch usw. vorgeworfen obwohl der andere auch noch im Unrecht ist, die Ton macht die Musik, wenn ich also dich korrigiere und mich dabei etwas gelassener Ausdrücke, dann liegt es in erster Linie daran, dass diese Tonart hier offensichtlich üblich ist, denn gda hat es hier vorgemacht wie hier diskutiert wird. Ich passe mich lediglich an.



    Zitat


    Nein, für dich nicht. Erst Leute beleidigen und dann Hilfe erwarten. Das wäre ja noch schöner.


    Siehe oben, ich habe dich nicht beleidigt, sondern dich zurechtgewiesen in einer Sache in der du falsch liegst. Ein Commit gibt immer einen Hinweis über die Aktualität der Treiber im offiziellen Kernel, da kannst du noch so oft beleidigt mit den Füßen auf den Boden stampfen, aber da werde ich dir nie recht geben, wenn du etwas anderes behauptest. Und das habe ich eben zu Recht an deiner Aussage kritisiert und zwar so, wie es hier üblich zu sein scheint, es gda also vorgemacht hat. Die Möglichkeit ihn auf einen mäßigeren Ton hinzuweisen hattest du ja, da du dies aber unterlassen hast nimmst du diese Tonart hier als üblich hin und machst sie dir sogar zu eigen, daher kannst du dich jetzt nicht beschweren.
    Des Friedens willen würde ich dir jetzt aber hier einfach vorschlagen, in dem wir einfach von vorne Anfangen. :prost2




    Zitat von gda


    Du beantwortest eine Frage die ich gar nicht gestellt habe. Die Frage war, soll man auf die Sprache C verzichten weil damit unfreie Treiber geschrieben werden können, soll man auf DKMS verzichten weil damit unfreie Treiber verpackt werden können?
    Außerdem verheimlich ein DKMS-Paket nichts. Man kann sehr leicht hineinsehen und feststellen ob es nur Source-Code ist, oder binäre Blobs enthalten sind. Ganz im Gegenteil zu anderen binären Paketen einer Distribution.


    Gerald


    Schön, aber inwiefern sollte deine Frage Sinn ergeben? Ich habe nirgends gefordert, dass man auf die Sprache C verzichtet.
    Also muss ich ja wohl raten, was du mit deinem Beitrag gemeint haben könntest.


    So wie ich das nun jetzt lese, möchtest du wissen, ob man auf DKMS verzichten sollte, weil es damit auch möglich ist, unfreie Treiber zu verteilen.
    Wenn das deine Frage war, nun, das muss man natürlich nicht. Allerdings wäre das Zeugs direkt in den offiziellen Kernelquellen dennoch besser, dies gilt insbesondere dann, wenn der letzte Commit schon eine Ewigkeit her ist.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von Copperhead


    Wirklich? Du gibst UbuntuUsers als Quelle an?


    Natürlich, denn in diesem Fall könnte man sogar gar keine bessere Quelle angeben!
    Der Grund dafür ist einfach.
    Berichte mit Closed Source Modulen die DKMS verwenden landen nicht auf der Projektseite des DKMS Projekts und nur mit Einschränkungen bei der offiziellen Anlaufstelle einer Distribution die nur Open Source Software einsetzen.
    Also findet man derartige Informationen nur durch User, die sich Hardware gekauft haben deren Hersteller derartige DKMS Module auf ihrer Supportseite zum Download anbieten.
    Und wem sagen die user das zuerst weiter, wenn es Probleme gibt oder sie Informationen darüber verbreiten wollen?
    Natürlich auf den Community Seiten der Distribution die sie nutzen, wie z.B. eben die Wiki von Ubuntuusers.


    Eine bessere zuverlässigere Quelle als diese kann man also gar nicht angeben.





    Zitat


    Theoretisch. Praktisch liegt das im Ermessen des Entwicklers.


    Natürlich, aber auch ein Entwickler hat es bequemer, wenn er aktuelle Kernelsourcen nicht mit seinen Treibern manuell mergen muss, also hat er selbst einen Vorteil dadurch, wenn sein Quellcode in den offiziellen Sourcen landet.
    Dies gilt insbesondere dann, wenn in den offiziellen Sourcen Änderungen notwendig werden, damit die eigenen Treiber funktionieren.
    Ich weiß wovon ich hier rede, denn ich entwickle selber Software.




    Zitat


    Das hat mit Commit nichts zu tun. Es ist zumindest lange her.


    Was redest du da für einen Ahnungslosen Unsinn?
    Die Aktualität der Treiber in den offiziellen Kernel Sourcen hat sehr wohl etwas mit dem Datum des letzten Treibercommits zu tun.
    Wenn der Commit nämlich 2 Jahre zurück liegt, dann ist der Quellcode bezüglich der Treiber im offiziellen Kernel nämlich sehr alt im Gegensatz zu dem Quellcode der außerhalb des Kernels weiterentwickelt wurde.




    Zitat


    Genau. Das will ich damit sagen.


    LOL


    Zitat


    Kein Deut besser. Die sehen das alle zu engstirnig.


    Das ist meine Meinung.


    Exakt, nur deine Meinung.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von gda

    Proprietären (unfreie) Treibern für den Linux-Kernel werden so gut wie immer in der Sprache C geschrieben, sollte man deshalb jetzt im Open-Source-Bereich darauf verzichten? Ich bleibe dabei, es ist Unsinn. Was weiß der Schreiber dieses Artikels denn schon. Hat der statistische Erhebungen gemacht?


    Gerald


    Ja, man sollte auf unfreie Treiber wenn möglich verzichten.
    Der Grund ist einfach, der Support ist oftmals schlecht und ab irgendeiner Kernelversion endet dieser dann, dann kann man die Karte unter neueren Kerneln nicht mehr weiternutzen und hat somit ein Produkt, dass unter neuen Linux Versionen nicht mehr betriebsfähig ist.
    Der ganze Ärger mit Kernel nachpatchen und gegebenenfalls neucompilieren, kommt ebenfalls noch hinzu.


    Diesbezüglich bin ich auch ein gebranntes Kind und spreche aus Erfahrung. Erst kürzlich habe ich mir zwei DVBSky T9580 DVB-C/S2/T Karten gekauft die leider bezüglich dem für DVB-C verantwortlichen Si2168 30 Chipsatzes mit Closed Source Treibern und Closed Source Firmware ausgeliefert wurde, diese Karten zum Betrieb unter Linux zu überreden hat nicht zufriedenstellend geklappt und deswegen gehen die heute wieder zurück. Aber das war nicht meine erste Erfahrung mit CS Treibern, die hatte ich auch schon mit einer ISDN Anlage und sonstiger Hardware gemacht, bei dieser Karte habe ich nur wieder einmal einen Versuch gewagt, weil der Hersteller offiziell mit Linux Support geworben hat und die Karte eben nicht nur DVB-C, sondern auch DVB-S2 und DVB-T kann. Die Ernüchterung kam dann, als ich die Karten da hatte und ausgiebig testen konnte.


    Uneingeschränkt Produkte mit Closed Source Treibern kann ich einzig und allein nur von NVidia für deren Grafikkarten empfehlen, da ist die Firma groß genug und der Support ausgezeichnet und hat dies in den letzten 10 Jahren auch bewiesen. Bei allen anderen Produkten die ich bisher hatte und für die CS Treiber notwendig waren kann ich das nicht sagen.


    Die Qualität der Treiber hat übrigens nichts mit der Programmiersprache zu tun und der Kernel verwendet selbst C als Sprache, dass man hier dann ebenfalls C verwendet ist naheliegend, zumal es sich auch um eine Programmiersprache handelt, die für die Systemprogrammierung auch geeignet ist.


    Bei OpenSource Treibern gibt es im Falle von Probleme dagegen immer die Möglichkeit, dass man selbst oder irgendjemand anderes den Fehler behebt oder die Treiber über mehrere Kernelgenerationen hinweg von den Kernel- und Treiberentwicklern weitergepflegt werden. Bis da mal ein Treiber nicht mehr funktioniert und man die Hardware wegwerfen kann, vergehen oftmals 10 Jahre. Diese Möglichkeit hat man bei CS Treibern nicht. Der Hersteller ist nur verpflichtet für einen Zeitraum von 2 Jahren die Funktionstüchtigkeit der Karte unter Linux zu gewähren, sofern er damit wirbt.
    Geht man davon aus, dass eine Karte ca. 2-3 Jahre im Handel ist, dann ist man in 4-5 Jahren oftmals aufgeschmissen und kann eine neue Karte kaufen.


    Bei Produkten mit Open Source Treibern und CS Firmware ist es ein Zwischending aus beiden Welten, aber auch da kann man nur dann auf einen guten Support hoffen, wenn zumindest der OpenSource Teil Bestandteil des offiziellen Kernels ist, damit ist zumindest gewährleistet, dass genug Kerneklentwickler versuchen werden, den Open Source Teil über mehrere Kernelgenerationen funktionstüchtig zu halten und wenn man Glück hat und die Nutzerbasis groß genug ist, dann besteht sogar die Möglichkeit, dass die CS Firmware irgendwann durch Open Source Code vollständig ersetzt werden kann.

  • Welche DVB-C Karte würdet ihr mir momentan für Linux empfehlen?

    Zitat von gda


    Du erzählst totalen Quatsch. DKMS ist nur ein Hilfsmittel um eben Open-Source-Treiber die nicht Bestandteil des aktuellen Kernels sind, automatisch gegen eben diesen Kernel zu bauen.
    Es hilft einfach nur Usern die weder die Lust noch die Fähigkeiten haben diese Treiber bei jedem Kernel-Update selbst zu bauen. Was das mit proprietärer Firmware zu tun haben soll erschließt sich mir nicht.


    Gerald


    Eben nicht, siehe:

    Zitat


    Praktisch wird DKMS meist bei proprietären (unfreien) Treibern für Grafikkarten und RAID-Controller sowie Softwarelösungen zur Virtualisierung eingesetzt, also Bereiche, bei denen ein Kernelupdate unter Umständen zu einem nicht mehr funktionierendem System bzw. Programm führen kann.


    Quelle: http://wiki.ubuntuusers.de/DKMS



    Mag sein das man das für Open Source auch nutzen kann, aber die Regel ist das in der Regel nicht.
    Bei Open Source landet das Zeugs nämlich sobald es halbwegs ausgereift ist in der Regel gleich in den Kernel Sourcen, das ist am unkompliziertesten.


    Zitat von Copperhead


    Sollten sie, ja. Sind sie im Prinzip auch, aber nur ein älterer Stand.


    Wann gab es das letzte Kernel commit zu diesen Treibern in den offiziellen Kernel?


    Zitat


    Nein, die Lizenz passt zum Kernel.


    Also GPLv2?



    Zitat


    Vielleicht, nur gibt es solche ausgesprochen selten. Nur weil ein Treiber im Kernel ist, heißt das noch lange nicht, dass bis zur Hardware alles Open Source ist. Jede Distribution, die etwas taugt, hat dieses Repository paketiert --> http://git.kernel.org/cgit/linux/kernel/…ux-firmware.git


    Du willst jetzt doch wohl nicht sagen, dass z.B. Debian nichts taugen würde?
    Linux Firmware befindet sich bei Debian nicht ohne Grund in unfree.
    Canonical nimmt das bei Ubuntu vielleicht etwas lockerer, aber andere wie Fedora oder Open Suse verfahren hier inzwischen ähnlich wie Debian.


    Mir ist das propritäre Firmware Debakel mit denen man auch hin und wieder in der Linux Welt zu kämpfen hat, durchaus bekannt, nur will ich eben KEINE Karte, die derartiges erfordert.
    Meine letzten DVB* Karten kommen komplett ohne Firmware aus, leider sind es PCI Karten, sonst würde ich sie im neuen Rechner weiterbenutzen.


    Wenn diese Karte also proprietäre Firmware mitliefert, dann würde ich mich über andere Kartenvorschläge freuen.