Muss der UDP-Port für den VDR statisch definiert sein?

  • Hallo,

    wie in 06_default_svdrp_port_0.patch ist problematisch angesprochen setzt der VDR den hardcodierten Wert DEFAULTSVDRPPORT für den SVDRPUdpPort, für den SVDRPTcpPort wird das Start-Argument -p PORTNUMMER berücksichtigt. Spricht etwas dagegen das anzugleichen (oder den UDP-Port mit einem eigenen Startargument konfigurierbar zu machen)?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ist mir auch schon aufgestossen, als ich den vdr in zwei Instanzen laufen lies, da kommen sich die zwei in die Quere.


    Bei der Gelegenheit, es gibt ja den Parameter "--instance", warum hat der hier keinen Einfluss?


    vdr-User-# 755 to_h264 chk_r

  • Welchen (sinnvollen) Effekt könnte bzw. sollte der --instance Parameter auf die vom VDR genutzten Ports haben? Es gibt zwar die Möglichkeit, dass mehrere Programme den gleichen Port nutzen (https://lwn.net/Articles/542629/) - aber zumindest SVDRP über TCP könnte nach meinem Verständnis nicht unterscheiden, für welchen VDR der Befehl gedacht ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von seahawk1986 ()

  • Wenn ich ein Programm in zwei Instanzen, also zweimal, laufen lasse, müssen die Listen-Ports unterschiedlich sein. Das ist für den SVDRP-TCP Port leicht möglich, jedoch nicht für udp. Warum soll man das nicht an den --instance Parameter koppeln?


    vdr-User-# 755 to_h264 chk_r

  • Der Vorgabewert für die InstanceId ist 0 und dann nimmt man doch normalerweise für zusätzliche Instanzen einen um jeweils 1 höheren Wert - bis man da in den Bereich der nutzbaren Ports kommt, dauert das eine Weile...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich würde es für sinnvoll halten den Wert für die instance auf den default port zu addieren.


    vdr-User-# 755 to_h264 chk_r

  • Die Instance-ID gibt es ja eigentlich, damit sich verschiedene VDRs (egal ob auf dem gleichen oder einem anderen Rechner) ein Aufnahmeverzeichnis teilen können, deren Ports deswegen zu verstellen und damit andere Dinge zu brechen, die sich auf den Standard-SVDRP-Port verlassen (wie svdrpsend) halte ich für übertrieben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wenn es schon einen Port-Parameter gibt, dann sollte man den für beide nutzen. Die Instance-Id sollte mit dem Port nichts zu tun haben.


    Lars.

  • Der UDP Port 6419 ("svdrp-disc") dient dazu, dass ein VDR andere VDRs "finden" kann. Wenn ein VDR auf einem anderen als diesem "horcht", dann wird er niemals mitbekommen, wenn ein Broadcast auf UDP Port 6419 erfolgt. Welchen Sinn sollte es also haben, diesen Port einstellbar zu machen?


    Klaus

  • Weil man sonst nicht zwei vdr auf dem gleichen Rechner laufen lassen kann. Das nutzen wir bei yavdr z.B. für ein Picture-in-Picture-Feature.


    Lars

  • Der UDP Port 6419 ("svdrp-disc") dient dazu, dass ein VDR andere VDRs "finden" kann. Wenn ein VDR auf einem anderen als diesem "horcht", dann wird er niemals mitbekommen, wenn ein Broadcast auf UDP Port 6419 erfolgt. Welchen Sinn sollte es also haben, diesen Port einstellbar zu machen?

    Man könnte damit Gruppen von VDRs definieren, die eine gemeinsame Kanalliste haben (in den Release-Notes zum VDR 2.3.1 stand, dass die Synchronisierung der Kanallisten später möglich werden soll) und die Informationen über ihre Timer (und was da in Zukunft sonst noch an Funktionen für das Peering dazu kommt) austauschen können sollen.


    Mir fällt da z.B. eine gezielt eingeschränkte Kanalliste für von Kindern genutzte VDRs oder die Trennung von VDRs mit unterschiedlichen Empfangswegen im gleichen Netzwerk (Raspberry Pi haben z.B. nichts von DVB-T2 Sendern in der Kanalliste) ein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • kann ich das mit dem udp Port irgendwie abstellen / rauspatchen um zwei vdr Instanzen sauber parallel zu betreiben?


    Idealerweise mit dem Aufruf, sonst benötige ich für das addon pip ein anderes Binary als für den Hauptvdr, denn da ergibt es ja durchaus Sinn


    Christian

     CKone: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.3.8 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von CKone ()

  • Der VDR öffnet den UDP-Port nur unter bestimmten Voraussetzungen:

    • in der setup.conf muss SVDRPPeering = 1 gesetzt sein (ist standardmäßig deaktiviert, also 0)
    • der SVDRP-Port muss ungleich 0 gesetzt sein (das lässt sich also mit dem Start-Argument -p0 zuverlässig abschalten)

    Es gibt für den PIP-Betrieb also kein Problem, wenn man den PIP-VDR sowieso über dbus2vdr statt SVDRP ansteuert und man könnte auch SVDRP nutzen, wenn man sicherstellt, dass das Peering in der setup.conf deaktiviert ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Könnte man nicht die svdrphosts.conf erweitern, z.B.:


    Code
    1. 192.168.100.0/24:6419-6420


    Damit gibt man der vdr-Instanz vor auf welchen UDP-Ports das Peering stattfinden soll. Der eigene UDP-Port leitet sich dann vom übergebenen SVDRP-Port ab und kann mit SVDRPPeering ggfls. abgeschaltet werden. Damit sollte sich ein beliebiger Mischmasch von vdr-Instanzen mit und ohne Peering realisieren lassen.

    VDR Test: ASUS M3N78-VM, Cinergy S2 PCI HD, SanDisk SDSSDP06, Atric-IR-Einschalter, SW: Debian Wheezy / softhddevice

  • Für was soll es gut sein den Port konfigurierbar zu machen wenn man ihn

    • abschalten kann
    • er nur kollidiert wenn mehr als eine VDR Instanz mit aktivierten Peering auf einem PC laufen


    Wieviele VDR Nutzer betreiben mehr als eine Instanz auf einem Rechner?

    Gruß
    Frodo

  • Dass alle den gleichen Port benutzen, ist schon in Ordnung. Wenn man das Discover verbessern wollen würde, müsste man sonst avahi benutzen. Aber das ist sicherlich nicht gewollt...


    Lars

  • ich frage mich wo das port Problem ist ?

    Wie Klaus oben schrieb ergibt es keinen Sinn den UDP Port 6419 zu ändern.

    Muss man ja auch nicht


    Einfach der Netzwerkkarte eine 2. IP geben und die 2. vdr Instanz an diese binden.

  • Der UDP-Port sollte eigentlich nicht kollidieren, wenn mehrere VDR-Instanzen auf der gleichen Maschine laufen. Es wird auf diesem Port ja nur "gehorcht" bzw. Broadcasts verschickt. Die eigentliche Kommunikation erfolgt über den TCP-Port, und da muss (und kann) natürlich jede Instanz ihren eigenen haben. Es gibt aber wohl noch ein Problem in der Ecke, das ich gerade am debuggen bin...


    Klaus