Feature Request: Beschränken von C/T Tunern auf eine Empfangsart

  • Hallo zusammen,


    Wenn man einen VDR hat der nur mit C/T Kombitunern bestückt ist, und man auch beide Signalarten empfangen möchte, dann hat man das Problem das der VDR nicht weiß an welchen Tuner denn nun welche Signalart angeschlossen ist.


    Ich schlage vor im Setup die Empfangsart pro C/T Tuner auf DVB-C oder DVB-T begrenzen zu können.


    Grüße,
    Christian

    VDR1: Debian 6.0.10, VDR 2.0.6, Kernel 3.2.36+mb_experimental, Zotac E350-ITX + TT6400 + DD DuoFlex-CTv2 Octopus mini PCIe + Noxon DAB Stick
    VDR2: Debian 6.0.10, VDR 2.0.6, Kernel 3.7.1+mb_experimental,, Zotac IONITX-S-E + TT6400 + DD DuoFlex-CTv2 mini PCIe

  • Ich schlage vor im Setup die Empfangsart pro C/T Tuner auf DVB-C oder DVB-T begrenzen zu können.


    Man kann auch den Weg des geringsten Widerstandes zu gehen und das Dynamite-Plugin dafür benutzen: http://projects.vdr-developer.org/projects/plg-dynamite ;)
    Denn damit kannst du pro Tuner per udev-Regel festlegen, welche Fähigkeiten ein Tuner nutzen soll (da muss natürlich noch ein Tunermerkmal in die udev-Regel):

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi,


    okay das scheint auch eine Möglichkeit zu sein das Problem zu lösen. Aber ich bin kein Fan davon für Dinge die eigendlich naheliegend sind extra ein Plugin nutzen zu müssen. Ich habe auf der Homepage des Plugins auch gerade gelesen das der VDR für das Plugin gepatcht werden muss? Das geht ja schon mal gar nicht ;-)


    Grüße,
    Christian

    VDR1: Debian 6.0.10, VDR 2.0.6, Kernel 3.2.36+mb_experimental, Zotac E350-ITX + TT6400 + DD DuoFlex-CTv2 Octopus mini PCIe + Noxon DAB Stick
    VDR2: Debian 6.0.10, VDR 2.0.6, Kernel 3.7.1+mb_experimental,, Zotac IONITX-S-E + TT6400 + DD DuoFlex-CTv2 mini PCIe

  • Das geht ja schon mal gar nicht ;-)


    Gehen tut das prima... ob man das will ist die andere Frage.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • soweit ich weiss, sind sich die Treiberentwickler noch nicht einig, wie Hybrid-devices von einem Modus in den anderen gesetzt werden sollen. Mag sein, dass es eine API dafür inzwischen gibt, aber Fakt ist, dass viele Treiber das noch gar nicht unterstützen. Zudem gibt es wohl auch hardwarespezifische Sonderheiten. Das Design der Karten ist ja auch sehr unterschiedlich.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.


  • Dieses Problem wurde schon so oft angesprochen und gehört eigentlich direkt in vdr, nicht in ein extra Plugin. Aber es scheitert eher am Willen das direkt im VDR zu implementieren.


    Klar ist, wie du schon schreibst: eine Kombikarte, bei der ein Eingang mehrere Signalarten empfangen kann, kann nicht wissen was der Benutzer angeschlossen hat: Sat, Kabel oder DVB-T. Aus dem Grund ist das nicht auf Treiberebene direkt lösbar, vielmehr muss es die Software selbst wissen und den Treiber passend zur Signalart ansteuern.


    Und auch das ist richtig: ein Plugin, was einen Patch für vdr braucht geht am Sinn der Pluginschnittstelle vorbei. Da nützen dann auch neue Makefiles mit Schnickschnack, Schleifchen und Schnörkeln dran nichts.

  • Dieses Problem wurde schon so oft angesprochen und gehört eigentlich direkt in vdr, nicht in ein extra Plugin. Aber es scheitert eher am Willen das direkt im VDR zu implementieren.


    Ich bin halt der Meinung, daß sowas "automatisch" passieren sollte, und da müsste eigentlich von Treiberseite Unterstützung angeboten werden. Was der Treiber nicht mitteilt, kann sich VDR auch nicht mehr aus den Fingern saugen.


    Quote


    Klar ist, wie du schon schreibst: eine Kombikarte, bei der ein Eingang mehrere Signalarten empfangen kann, kann nicht wissen was der Benutzer angeschlossen hat: Sat, Kabel oder DVB-T. Aus dem Grund ist das nicht auf Treiberebene direkt lösbar, vielmehr muss es die Software selbst wissen und den Treiber passend zur Signalart ansteuern.


    VDR reagiert auf das, was der Treiber über DTV_ENUM_DELSYS der Applikation mitteilt. Wenn das Device nur einen Antenneneingang für alle Signalarten hat, dann wäre, finde ich, der Treiber die richtige Stelle, um das festzulegen, z.B. durch einen Modul-Parameter.


    Quote


    Und auch das ist richtig: ein Plugin, was einen Patch für vdr braucht geht am Sinn der Pluginschnittstelle vorbei. Da nützen dann auch neue Makefiles mit Schnickschnack, Schleifchen und Schnörkeln dran nichts.


    Dieses konkrete Problem ließe sich mit der vorhandenen cDeviceHook::DeviceProvidesTransponder()-Schnittstelle lösen. Ein Plugin könnte so einen Hook implementieren und für dieses Device abhängig von der Source des Kanals und der benutzerdefinierten Einstellung der aktuellen Empfangsart true oder false zurückliefern. Das geht ganz ohne Patch.


    Ich werde mir das Thema nach der Version 2.0 nochmal anschauen.


    Klaus

  • Moin!


    das der VDR für das Plugin gepatcht werden muss? Das geht ja schon mal gar nicht ;-)


    Und auch das ist richtig: ein Plugin, was einen Patch für vdr braucht geht am Sinn der Pluginschnittstelle vorbei.


    Ich frage mich, wie ihr den vdr weiterentwickeln wollt, wenn ihr ihn nicht patcht... :)


    UFO hatte mal das Konzept, das Klaus hier erwähnt, in ein proof-of-concept-Plugin gegossen (ich glaub, es heißt delsys, einfach mal im Portal suchen).
    Da muss allerdings die Zurodnung direkt im Quellcode fest verdrahtet werden.


    Mögliche Probleme, die man bedenken sollte: wechselnde Adapter-Nummern, je nach Ladereihenfolge der Treiber.
    Entweder alle Treiber mit dem Parameter "adapter_nr" versorgen, damit es eine definierte Zuordnung gibt, oder die Adapter irgendwie anders markieren, z.B. per udev-Attribute wie dynamite es macht.


    Lars.


  • Mögliche Probleme, die man bedenken sollte: wechselnde Adapter-Nummern, je nach Ladereihenfolge der Treiber.
    Entweder alle Treiber mit dem Parameter "adapter_nr" versorgen, damit es eine definierte Zuordnung gibt, oder die Adapter irgendwie anders markieren, z.B. per udev-Attribute wie dynamite es macht.


    Ich persönlich bin dafür, die Adapter-Reihenfolge möglichst früh festzulegen, also z.B. per Modul-Parameter.
    Von "dynamite" halte ich nichts.


    Klaus

  • Ist doch alles Quatsch - so richtig kompliziert wird es dann doch wenn identische Hardware mit verschiedenen System im Rechner sind.
    Ich glaube nicht das es eine sinnvolle Möglichkeit gibt das ohne udev in den griff zu bekommen. Zumindest muss man darüber die Karten zweifelsfrei zuordnen können.


    Und ein Plugin das einen Patch braucht geht an der Pluginschnittstelle vorbei ? Ok - welches komplexere Plugin benötigt denn keinen Patch ? (Mainmenuhooks mal als Beispiel).


    Die Adapterreihenfolge festzulegen ist wohl doch ein bischen "Old School" - man könnte versuchen persistente Geräteknoten über udev festzulegen - andererseits vermute ich könnte vdr die dann garnicht einlesen/sehen wenn man von der Standardbenennung abweicht.


    Ich würde mir etwas mehr Toleranz und Weitsicht wünschen ... Sich nach 5 Jahren udev immer noch zu wünschen es wäre nicht da bringt uns doch nicht weiter. Es ist defakto inzwischen in jeder Distribution aktiv. Das Problem über udev-rules komplett auf den User abzuwälzen kann auch nicht die Lösung sein.


  • Die Adapterreihenfolge festzulegen ist wohl doch ein bischen "Old School" - man könnte versuchen persistente Geräteknoten über udev festzulegen - andererseits vermute ich könnte vdr die dann garnicht einlesen/sehen wenn man von der Standardbenennung abweicht.


    VDR setzt auf der Struktur in /dev/dvb/... auf und benutzt die Devices in der Reihenfolge, wie sie dort liegen.
    Wie sie dort hinkommen ist Sache des Treibers bzw. des Setups, aber nicht von VDR.


    Klaus

  • Das heisst der Zwang sie durchlaufend zu nummerieren und sie adapterX zu nennen ist inzwischen weg ? Prima.


    Solange 'Von "dynamite" halte ich nichts' nicht heisst das es andere nicht anders halten dürfen ist es für mich in Ordnung.

  • Das heisst der Zwang sie durchlaufend zu nummerieren und sie adapterX zu nennen ist inzwischen weg ? Prima.


    Sie müssen nicht mehr durchlaufend nummeriert sein, müssen aber noch "adapter*" heißen, so weit ich weiß.


    Lars

  • Das heisst der Zwang sie durchlaufend zu nummerieren und sie adapterX zu nennen ist inzwischen weg ? Prima.


    Das Namensschema gilt natürlich immer noch, denn das wird ja vom Treiber so vorgegeben.
    Also /dev/dvb/adapterX/frontendY etc.
    Seit Version 1.7.24 hört VDR beim Scannen der Devices nicht mehr bei einer "Lücke" in den Adaptern bzw. Frontends auf, sondern scannt das gesamte Directory.


    Quote


    Solange 'Von "dynamite" halte ich nichts' nicht heisst das es andere nicht anders halten dürfen ist es für mich in Ordnung.


    Jeder hat das Recht auf seine eigene Meinung ;-)


    Klaus

  • Von "dynamite" halte ich nichts.


    vdr-plugin-dynamite ist eine sehr gute Erweiterung für VDR, es wird von den Nutzern sehr gut angenommen, wie auch neue Funktion wie SCR/Unicable® oder der achso schmutzige Workaround "LNB-Sharing", heute bekannt als Device Bonding ... :thumbup:


    Jeder hat das Recht auf seine eigene Meinung ;-)


    Natürlich, verlangt auch keiner das "dynamite" direkt Teil des VDRs kommt, aber die generelle Möglichkeit so etwas als Plugin zu nutzen ist mehr als legitim, der VDR wurde schon für "sinnloseres erweitert" ... 8o


    Regards
    fnu

    HowTo: APT pinning

  • Dynamite ist dann gut, wenn es keine VDR Patches mehr benötigt


    Und der VDR ist dann richtig gut, wenn er seine Empfänger dynamisch ein- und aushängen kann...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dynamite ist dann gut, wenn es keine VDR Patches mehr benötigt. Es gibt ja auch schon einige andere Plugins, die Empfangsgeräte einbinden, ohne Patch.


    Ganz deiner Meinung, deswegen wäre es ja eben schön, wenn der Patch in den VDR einfließen würde. Ohne Änderungen geht es eben nicht, deshalb hinkt der Vergleich, oder gibt es deiner Kenntnis nach ein Plugin, dass ein Empfangsgerät zur Laufzeit nachträglich einbindet? Ich glaube mini73 wäre dir für jeden Tipp sicher sehr dankbar.
    Der Patch stört die Nicht-Dynamite-Nutzer erwiesenermaßen nicht und ist von mini73 sehr schlank gehalten worden.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • @seahawk: Sehe ich nicht so. Meine TV-Karte steckt im PCIe und bleibt da auch. Ich habe die vor einem halben Jahr da hingepackt und seitdem nicht mehr angerührt.


    gda : Naja mcli macht ja sowas ähnliches. Da wird einfach behauptet, es wären 8 Tuner (oder mehr? einstellbar?) da, obwohl gar keine Tuner direkt am VDR hängen. Und das scheint auch ganz gut ohne Patch zu funktionieren.

  • @seahawk: Sehe ich nicht so. Meine TV-Karte steckt im PCIe und bleibt da auch. Ich habe die vor einem halben Jahr da hingepackt und seitdem nicht mehr angerührt.


    Und weil du es so nicht siehst, sollen andere, die zusätzlich noch einen USB-Tuner haben, warten müssen bis der fertig ist, obwohl sie schon längst mit ihrer PCIe-Karte Empfang hätten? Tut mir leid, für mich ist der VDR dann gut, wenn er eben diese Flexibilität hätte ein Bild zu zeigen sobald es geht und nicht erst wenn sich alles gesettelt hat.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470