Blockieren von Kanälen auf bestimmten Adaptern

  • Hallo allerseits (und ein frohes neues Jahr),

    bei mir sind zwei ähnliche aber nicht gleiche DVB-C-Adapter im Einsatz, die bei der aktuellen Empfangslage leider beide nicht in der Lage sind, jeweils alle gewünschten Kanäle sauber zu dekodieren. Kombiniert würde ich aber das Ziel erreichen, sprich es gibt für jeden Kanal einen Adapter, der geht.

    Nach meiner bisherigen Recherche hat vdr bislang keinen Mechanismus auszudrücken, dass z.B. Adapter 0 nicht mit Kanal 10 klarkommt, Adapter 1 aber nicht optimal für Kanal 12 ist etc. Hard-coded habe ich so etwas gestern mal erfolgreich probiert:

    Nun geht es mir aber darum, dass das vernünftig konfigurierbar wird und danach upstream geht.

    Was wären Vorschläge dazu? Sollte ich eine neue Konfigurationsdatei einführen, die eine Inkompatibilitätsliste darstellt (Adapter-Channel-Paare)? Oder sollte ich die channels.conf erweitern?

    Ferner, wie sollen Patch-Serien danach eingereicht werden? Per vdr@linuxtv.org (git sendemail) oder lieber als Attachments im Patches-Board?

    Danke schon mal,
    Jan

  • Könnte man dafür nicht die diseqc.conf benutzen?

  • Das lässt sich über den "Conditional Access" Eintrag in der channels.conf erreichen (siehe man vdr.5). Funktioniert allerdings nur für FTA-Sender.

    Du könntest auch ein Plugin machen und einen cDeviceHook implementieren, der in DeviceProvidesTransponder() entsprechend reagiert.

    Ansonsten vielleicht mal den Kabelanschluss überprüfen lassen.

  • Conditional Access - nett, das hatte ich übersehen. Probiere ich gleich. Überleben diese Anpassungen automatische Updates der channels.conf?

    Führt dann aber auch zum zweiten Thema: Adapternummerierung. Die ist inhärent instabil, weswegen ich ein rmmod / modprobe Workaround in der vdr.service habe. Das klappt aber nur, weil hier unterschiedliche Treiber im Spiel sind. Gibt es da ggf. auch schon die Möglichkeit, die interne Nummerierung stabil an die (Frontend?) Namen zu koppeln?

  • Du könntest eine udev rule erstellen.

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Die CAID wird bei automatischen Updates der channels.conf nicht angerührt, da die ja gerätespezifisch ist.

    CAID

    Die Conditional Access-ID definiert, ob der Kanal verschlüsselt ist und wie er dechiffriert wird. Auch mehrere IDs sind als kommagetrennte Liste möglich.

    • 0 "Free To Air"
    • 1 bis 8 (vor VDR-1.5.1: 1 bis 4) Benötigt die DVB-Karte mit der bestimmten Nummer.
    • 9 bis 15 (vor VDR-1.5.1: 5 bis 15) Benötigt Gerät mit der bestimmten Nummer (z.B. streamdev-client).
    • 16 bis 100 Benötigt eine spezielle Methode zur Dekodierung.

    Die entsprechende Methode ist in der Datei ca.conf beschrieben.

    vdr User #2022 - hdvdr2:

    Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 32 GB Ram, zram-swap/tmp, ubuntu-focal+ESM, softhdcuvid-placebo, ffmpeg-6.1.4(git)

    ddbridge mit DVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF1050Ti SFF (nvidia-dkms-580.126.09), system SSD btrfs,

    timeshift-btrfs, Video 8TB HDD XFS/cow, yavdr-ansible-2.7.9-seahawk, tvscraper tvsp, Kernel 6.12.69+dddvb-0.9.41-git

    vdradmin-am-3.6.15, vdr-live-ng, vdrmanager (Smartphones als FB)

  • Ein udev rule erscheint naheliegend, und ich hatte mir das wohl auch schon mal angesehen. Nun habe ich es erneut, und ich komme wieder zum gleichen Ergebnis: geht nicht.

    Man kann leider die Adapter-Nummer nicht per udev beeinflussen, auch nicht den Gerätenamen (geht nur bei network devices). Man könnte einen symlink setzen, nur hilft das hier nicht, da vdr nur nach festen Pfaden sucht (/dev/dvb/adapter*).

    Dafür funktioniert der Conditional Access Trick. Gut auch zu wissen, dass die Werte stabil bleiben. Danke für die Hinweise!

  • Was für Adapter sind es denn?
    Bei manchen kann man Kernel-Modul Parameter mitgeben (zB bei DD).

  • udev rule sollte eigentlich gehen, udev organisiert ja alle diese links in /dev. Vielleicht mal spielen damit..

    Code
    udev-hwdb update &&
    udevadm info -a -p /sys/class/dvb/dvb0.frontend0

    Da kommt dann eine Liste von Attributen raus, die man nutzen könnte, z.B. so etwas

    Die Logik folgt der Baumstruktur des PCIe Bus
    /devices/pci0000:00 -> Dein PCIe root node in der CPU
    /devices/pci0000:00/0000:00:1b.3 -> Am ersten PCIe Bus auf Node 00 hängt ein Gerät 0000:00:1b.3 welches eine PCIe / PCIe bridge ist, sieht man am Treiber
    /devices/pci0000:00/0000:00:1b.3/0000:04:00.0 -> Aha, Treiber ist ddbridge, das ist eine DVB Karte
    /devices/pci0000:00/0000:00:1b.3/0000:04:00.0/dvb/dvb0.frontend0 -> Ein Subsystem der DVB Karte


    Tja, und dann versucht man eine passende rule für udev zu erstellen, z.B. so in der Art (habs nicht probiert, weil ich es nicht brauche..)

    Code
    cat > /etc/udev/rules.d/99_dvb_devs.rules << "EOF"
    
    # my own fancy rule for dvb tuners
    KERNEL=="dvb[0-9].frontend0", KERNELS=="0000:04:00.0", ATTRS{device}=="0x0006", ATTRS{vendor}=="0xdd01", NAME="dvb0/frontend0"
    KERNEL=="dvb[0-9].frontend0", KERNELS=="0000:04:01.0", ATTRS{device}=="0x0006", ATTRS{vendor}=="0xdd01", NAME="dvb1/frontend0"
    
    EOF

    Die genaue Syntax und Möglichkeiten findest du hier:
    https://reactivated.net/writing_udev_rules.html#syntax

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Ich habe ein ähnliches Problem mit den öffentlich-rechtlichen HD-Sendern. Auf manchen meiner Empfänger laufen sie gut, auf anderen sind Aufnahmen ziemlich sicher mit TS-Fehlern durchsetzt. Bei kls hatte ich deswegen angefragt, ob man Kanälen nicht optional eine Affinität zu Devices zuordnen könnte (so wie man bei Betriebssystemen Threads eine Affinität zu Cores zuordnen kann), sodass Aufnahmen solcher Sender bevorzugt "ihre" Devices nutzen und erst dann auf andere ausweichen, wenn "ihre" Devices nicht frei sein sollten. Das wäre vermutlich flexibler aus die Lösung mit Conditional Access, richtig?

    Klaus fand das hinsichtlich der Device-Auswahl aber zu kompliziert und hat das leider nicht weiter verfolgt. Keine Ahnung, ob – wie von Klaus angedeutet – ein Plugin so ein Verhalten realisieren könnte und was das für Konfliktprüfungen bspw. von EPGsearch hieße.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.9 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, satip, screenshot, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Zum Thema udev: https://www.man7.org/linux/man-pages/man7/udev.7.html

    NAME    The name to use for a network interface. [...] The name of a device node cannot be changed by udev, only additional symlinks can be created.

    Und das deckt sich mit meinem Experimenten. In einem Fall bekam ich sogar diesen freundlichen Hinweis:

    dvb1.net0: /etc/udev/rules.d/70-persistent-dvb.rules:1 Only network interfaces can be renamed, ignoring NAME="%c".

    Aber Danke für die ausführliche Erkärungen. udev rules schreibe ich gefühlt alle Jahre mal eine, und jedes Mal ärgere ich mich über die mäßig intuitive Erstellung und das unscharfe Debugging. Kommt gleich nach regexps.


    Zum Thema Hardware: Bei mir kommen zwei Hauppauge USB Adapter zum Einsatz, inzwischen Museumsware:

    Bus 001 Device 003: ID 2040:1605 Hauppauge WinTV-HVR 930C HD 
    Bus 001 Device 005: ID 2040:b130 Hauppauge Hauppauge Device

    Die Treiber sind em28xx und cx231xx.

  • Nicht hübsch, aber nun geht es ohne orchestriertes Modulladen. Da sieht man aber dem DVB-Subsystem sein Alter an. Ähnliche Modul-Parameter habe ich in meiner "Jugend" auch erfunden :D. By-Name/Path/etc. bliebe schöner.

  • BTW, bei Verwendung des gleichen Treibers für mehrere Adapter kann sind weiter die Probing-Reihenfolge ändern, da Probing vor einiger Zeit im Kernel parallelisiert wurde. Auch daher wären udev-generierte, stabile Links besser, wenn Userland wie vdr auf diese konfiguriert werden kann.

  • Eine weitere Möglichkeit (und so habe ich es bei mir gemacht) ist, die adapter_nr bei Treibern die das unterstützen, anzugeben.
    z.B. bei mir in der "/etc/modprobe.d/local.conf":

    options ddbridge msi=1 adapter_nr=4 
    options smipcie adapter_nr=2,3

    Meine zweite DVB-Karte (TT6400) bekommt dann automatisch die Nummer 0 und 1, egal in welcher Reihenfolge die Karten vom System erkannt werden.

    Leider haben die beiden oben genannten Treiber, em28xx und cx231xx, diesen Parameter nicht.

    Grüße
    kamel5

    VDR 2.7.9: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 10TB HD mit ZFS RaidZ, GT1030, Fedora 42 Kernel 6.18 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!