Probleme mit DVB-C-Karte

Vermutlich muss bei der einen Karte das DVB-T deaktiviert werden, bei der anderen DVB-C.
Das Umschalten (dvb-fe-tool) ist heutzutage nicht mehr (in allen Treibern?) vorgesehen, stattdessen werden (normalerweise?) dem Userprogramm alle "delivery systems" parallel angeboten. Beim Start des vdr (mit ausreichend hohem loglevel) schreibt er, welche Systeme auf den einzelnen Devices aktiv sind. Leider gibt es im vdr selbst keine Moeglichkeit, bestimmte Devices fest einem Standard zuzuordnen, das soll - soweit ich gehoert habe - mit dem dynamite-Plugin gehen...

Gruss,
S:oren

Ja, mit dynamite kann man per udev attribute festlegen, welches device welche source empfangen darf. Ich wollte das immer schon mal rausziehen und als einzelnen vdr-Patch anbieten. Ich muss mir demnächst mal wieder vdr-Zeit abzwacken.

Beim Start loggt der vdr, welche delivery systems die einzelnen Frontends anbieten. Wenn der Treiber da keine Option bietet, nur bestimmte zu melden (da gehört es meiner Meinung nach hin), hat man schlechte Karten. Da man das Kabel ja nicht ständig wechselt, wäre eine Moduloption optimal. Dann müssten nicht alle Anwendungen eigene Konfigurationsmöglichkeiten implementieren, sondern könnten sich auf das verlassen, was die Treiber melden.

Lars

Da driftet die Diskussion ein bisschen ab, aber hier muss ich anmerken, dass es da zumindest unterschiedliche Ansichten gibt:
Kernel-Policy war und ist immer, dass alles, was man im Userspace machen kann, nicht im Kernel selbst implementiert wird. Der Kernel-Treiber stellt die Funktionalitaet der Hardware per standardisiertem API zur Verfuegung, die Konfiguration ist Sache der User-Applikation.

Hier sollen ja gerade zwei gleiche Karten mit dem selben Treiber fuer einmal DVB-C und einmal DVB-T2 (parallel zu jeweils DVB-S2) verwendet werden, wie kompliziert sollen Moduloptionen fuer solche Faelle werden? Wie will man das einigermassen konsistent ueber verschiedene Treiber implementieren? Was ist anwenderfreundlicher, mit root-Rechten an Moduloptionen zu basteln, oder eine GUI zur Konfiguration in der Applikation?

Davon abgesehen habe ich selbst natuerlich auch Treiber und vdr gepatcht, um parallel DVB-C und DVB-T zu verwenden. Aber das ist eben mehr fuer Entwickler als fuer Anwender - gut, dass es dynamite gibt. Und ich wuerde mir auch wuenschen, dass man bei linux-media erst nachdenkt und vernuenftige APIs implementiert, statt immer wieder irgendwas Neues und Inkompatibles zu erfinden...

Gruss,
S:oren

Wir sind grundsätzlich einer Meinung, was linux-media betrifft.

Ja, das mit der Trennung von Kernel- und Userspace kann man so sehen. Aber es gibt ja durchaus auch andere Treiber, die Optionen brauchen. Und dafür könnte man auch GUIs bauen, aber egal.

Ich sehe auch eher udev in der Pflicht, wobei eine Moduloption leichter für alle zu setzen ist, als eine udev-Regel zu schreiben. Na, mal sehen, ob ich dem vdr mal ein wenig udev beibringe...

Lars

Zitat von TEDDYXXL

Könnte mir ggf. jemand Beispiel-Konfigfiles, entsprechende Optionen für das dynamite-Plugin, etc. per PM mailen, um mein Problem zu lösen.

Ich hätte auch Interesse.
Wenn da schon jemand Erfahrungen hat - vielleicht würde er das ja auch hier veröffentlichen?
Das wäre schön.

Der vdr muss natürlich für dynamite gepatched sein. Und man muss sich bewusst sein,dass dynamite mit bestimmten, gern genutzten Plugins Probleme haben kann,da ich diese aber nicht nutze, hab ich da keine Erfahrung.

Dann muss man einen eindeutigen Filter aus den udev Attributen bestimmen (udevadm hilft) und dann eine udev Regel anlegen, siehe readme:
https://github.com/flensrocker…e/blob/master/README#L311

Sowas wie der PCI-Slot ist meist ein guter Ansatz, die DVB-Adapternummer eher nicht, weil die sich ändern kann. Seriennummer von USB-Adaptern sind natürlich super. Ein paar Beispiele findet man auch hier im Portal.

Lars