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

Ich suche eine DVB-C Karte für den PCIe BUS zum Empfang von unverschlüsselten SD und HD Sendern.

Da ich mit DVB-* Karten bezüglich Linux auch schon schlechte Erfahrungen gemacht habe, suche ich nun ein ausgereiftes Produkt das unter Linux ohne Probleme und zwar mit ausschließlich Open Source Treibern ohne der Notwendigkeit irgendwelcher CS Firmware oder Closed Source Treiber funktioniert.

Was für eine DVB-C Karte könnt ihr mir da für Linux empfehlen?
Sie sollte einfach out of the box funktionieren, also reinstecken und loslegen.
Wichtig ist nur, dass es eine PCIe Karte ist, weil mein neuer Rechner keinen PCI Slot mehr hat. USB würde auch noch in Frage kommen, aber nur dann, wenn hier alle Open Source Kritieren erfüllt sind, also keine Closed Source Firmware/Treiber benötigt werden.
Einen CI Slot oder eine Fernbedienung, oder einen Twin Tuner brauche ich nicht.
DVB-S und DVB-T Support sind auch völlig irrelevant, ich werde die Karte nur für DVB-C nutzen.
Ein schneller Senderwechsel wäre wünschenswert.
Ein Hardwaredecoder ist ebenfalls nicht erforderlich, eine normale passive DVB-C Karte genügt mir.
Auch wichtig ist ein guter Empfang, falls das bei DVB-C eine Rolle spielt.

Hier noch mal eine kurze Zusammenfassung was mir wichtig ist:

1. komplett mit Open Source Treibern lauffähig
2. Empfang von unverschlüsselten SD und HD Sendern möglich
3. PCIe BUS oder USB (falls 1. erfüllt)
4. unter Linux ausgereift, sollte out of the Box funktionieren ohne Stottern, Bildfehlern & Co.
5. DVB-C
6. guter Empfang
7. (optional) schneller Senderwechsel

Zitat von karlson

Meines Erachtens die Cine CT. Musst halt die Treiber immer neu übersetzen, aber ansonsten super. Teuer halt...GrK.

Wieso das? Sind die Treiber noch Experimental?
Wenn die Treiber OpenSource sind, dann sollten sie auch mittelfristig in den vanilla Kernel wandern und dann out of the Box immer funktionieren ohne das man da etwas übersetzen muss.

Woran liegt das also?
Haben die Treiber eine andere Lizenz und liegen lediglich im Quellcode vor?

Zitat von chriszero

Ich würde eine DigitalDevices Cine C/T nehmen. Die Doppeltunerkarte lässt sich durch zusätzliche Tuner erweitern und belegt trotzdem nur einen PCIe.
Soweit ich weiß braucht es für die neueren Modelle unter yaVDR nur ein DKMS Packet für die Treiber.

DKMS riecht ziemlich stark nach proprietärer Firmware.
Bei richtigen Open Source Treibern sind solche Verrenkungen nicht notwendig, weil dann alles im Standard Kernel ist.

Gibt es noch andere DVB-C Karten, die in Frage kämen?

Die Doppeltunerfähigkeit brauche ich wie schon gesagt nicht, wenn ich eine Single Tuner Karte kriege, die bezüglich Treiber im Gegensatz z.B. zu einer Doppeltuner Karte unkompliziert ist, also alles im offiziellen Linux Kernel Open Source drin ist, dann nehme ich lieber die Single Tuner Karte als eine Doppel Tuner Karte.

Meine Priorität liegt ganz klar bei Open Source! Alles andere ist nachrangig.

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.

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.

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.

Zitat von Copperhead

Warum reden wir überhaupt darüber? Der Treiber ist Open Source.

Ja, ich würde mir das mal gerne genauer selber ansehen.

Hast du nen Link zu den Treibern?

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.

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.