[Announce] vdr-plugin-satip-0.3.3 - Make your VDR to a SAT>IP Receiver. [updated]

  • Hallo,

    ich habe jetzt auch eine Telestar Digibit R1. Da das satip Plugin ganze Transponder von der R1 holt, ist mein Raspberry mit seinem lahmen Ethernet für den Stream etwas überfordert. Und auch aus anderen Gründen habe ich mir überlegt einen VDR mit streamdev dazwischen zu schalten.

    Nun habe ich Probleme beim Umschalten. Ich habe das satip Plugin auf dem Server mit "-d 1" gestartet. Der VDR hat also nur ein virtuelles Device. Schalte ich nun von Programm 1 (Das Erste HD) auf 2 (ZDF HD) um, passiert es häufig, dass der Bildschirm schwarz bleibt. Wenn ich dann auf dem Server im SVDRP "chan" eingebe, sagt er noch, er wäre auf 1. D.h. er hat irgendwie den Transponder nicht gewechselt. Im Log des Raspberry ist ohne FilterStreaming nichts anderes zu sehen, als bei den erfolgreichen Umschaltversuchen. Bei aktivem FilterStreaming stürzt der VDR oft sofort ab, da er vermutlich einfach den falschen Transponder filtert. Mit der gleichen streamdev-server Version auf meinem VDR mit TT-6400 funktioniert das Umschalten immer (dort ist allerdings eine ältere VDR Version im Einsatz).

    Andererseits, wenn ich per SVDRP ohne Streamdev-Client per "chan 2" und "chan 1" umschalte, sieht es jedes Mal erfolgreich aus (dort ist nur das dummydevice aktiv, daher kann ich nicht sehen, ob es wirklich klappt).

    Hat jemand eine Idee?

    Viele Grüße

    Tim

  • Ich habe das Problem das nach dem Einschalten des VDR´s es etwa ~1min dauert bis das Plugin den SAT>IP Server im Netzwerk findet.
    Gibt es eine Möglichkeit statt dieser Dynamischen Erkennung ihn per IP festzuschreiben mittels Konfig, da 1min schon recht störend ist?
    Wenn ich mittels DVB Viewer darauf zugreife ist sofortiger Zugriff möglich.

  • In den Vorraussetzungen steht

    Code
    - Libcurl >= 7.36.0 - the multiprotocol file transfer library with RTSP support
      http://curl.haxx.se/libcurl/

    leider hat Ubuntu 12.04.4 LTS aktuell die Version 7.22.0 umd wie ich feststellen durfte sind dagegen sehr viele Pakete gebaut.

    Ist es unbedingt erforderlich die Libcurl Version >= 7.36 einzusetzen, bauen konnte ich es auch genen 7.22.0? Welche Einschränkungen ergeben sich hierduch?

    Gruß
    Frodo

    Meine VDR Hardware

    YaVDR 0.6: Intel DQ67SW, Digital Devices Octopus Duo CI, 2x DD DuoFlex S2 V4, NVIDIA GT 610 (GF119), IMON VFD

    YaVDR 0.6: Asus Z170I PRO GAMING, NVIDIA GT 1030 (GP108-A), SilverStone ML02B-MXR, IMON LCD

    YaVDR 0.6: Intel DH67CF, TT S2-6400, NVIDIA GTX 1050 (GP107-A)

    YaVDR 0.5: Intel DH67BL, TT S2-6400, TT S2-3200, NVIDIA 210 (GT218)

    YaVDR 0.6: Zotac D2550ITX, NVIDIA GT 610 (GF119) onboard, IMON VFD

  • Hi Frodo,

    In den Vorraussetzungen steht

    Code
    - Libcurl >= 7.36.0 - the multiprotocol file transfer library with RTSP support
      http://curl.haxx.se/libcurl/

    leider hat Ubuntu 12.04.4 LTS aktuell die Version 7.22.0 umd wie ich feststellen durfte sind dagegen sehr viele Pakete gebaut.

    Ist es unbedingt erforderlich die Libcurl Version >= 7.36 einzusetzen, bauen konnte ich es auch genen 7.22.0? Welche Einschränkungen ergeben sich hierduch?

    wohl schon. Bau Dir doch Dein curl nur für satip bspw. so:

    Code
    /usr/local/src/curl-7.37.0 # ./configure --prefix=/usr/local/satip

    Und starte dann den VDR mit

    Code
    LD_LIBRARY_PATH=/usr/local/satip/lib vdr blahblah

    So mache ich das immer. :)

    Viele Grüße

    EDIT: Du musst natürlich das Plugin dann auch so bauen:

    Code
    LD_LIBRARY_PATH=/usr/local/satip/lib make plugins install

    Und im satip-Plugins Makefile:

    Code
    ### Includes and Defines (add further entries here):
    
    
    INCLUDES += -I/usr/local/satip/include
    LDFLAGS += -L/usr/local/satip/lib
  • Ist es unbedingt erforderlich die Libcurl Version >= 7.36 einzusetzen, bauen konnte ich es auch genen 7.22.0? Welche Einschränkungen ergeben sich hierduch?

    Ja, ist es, sonst kann es zu unvorhergesehenen Fehlern beim Abgreifen der Stream vom SAT>IP Server kommen. In "yavdr/main" bzw. auch meinem "fnu/main-fnu" findest Du eine 7.36.0 zurückportiert aus den Debian Repository.

    Wenn Du 7.22.0 nutzt, ist es am Ende Deine Entscheidung.

    Regards
    fnu

    PS.: Ebenso findest Du dort das dringend empfohlene pugixml für Precise, backported aus dem Trusty Repository ...

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

    Edited once, last by fnu (July 4, 2014 at 12:06 PM).

  • fnu
    Wenn man das LibCurl von Dir benutzt wird doch das 7.22.0 er Curl ersetzt, gibt das keine Probleme mit den anderen Paketen welche die ältere Version zum kompilieren verwendet haben?

    tehlers
    Das ist für eine Paket basierte Installation so nicht umsetzbar, danach müssete ich alles händisch bauen.

    Gruß
    Frodo

    Meine VDR Hardware

    YaVDR 0.6: Intel DQ67SW, Digital Devices Octopus Duo CI, 2x DD DuoFlex S2 V4, NVIDIA GT 610 (GF119), IMON VFD

    YaVDR 0.6: Asus Z170I PRO GAMING, NVIDIA GT 1030 (GP108-A), SilverStone ML02B-MXR, IMON LCD

    YaVDR 0.6: Intel DH67CF, TT S2-6400, NVIDIA GTX 1050 (GP107-A)

    YaVDR 0.5: Intel DH67BL, TT S2-6400, TT S2-3200, NVIDIA 210 (GT218)

    YaVDR 0.6: Zotac D2550ITX, NVIDIA GT 610 (GF119) onboard, IMON VFD

  • Wenn man das LibCurl von Dir benutzt wird doch das 7.22.0 er Curl ersetzt, gibt das keine Probleme mit den anderen Paketen welche die ältere Version zum kompilieren verwendet haben?

    Nein, nicht wirklich.

    Das läuft ja hier schon längers so, ist ja abwärtskompatibel und "nur" eine Bibliothek und nicht gcc. Pakete aus dem Ubuntu Repository werden gegen die Version von libcurl aus diesem gebaut, funktionieren aber mit 7.36.0. Die yaVDR Pakete bzw. auch meine eben gegen libcurl aus main(-fnu) ...

    Regards
    fnu

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

    Edited once, last by fnu (July 4, 2014 at 2:45 PM).

  • Gibt es mit 0.3.3 bekannte Probleme mit EPG Scan?
    Habe die entsprechende Option im Plugin aktiviert (also dass EPG Scan erlaubt ist), aber selbst wenn ich beim vdr einen EPG Scan erzwinge (aus dem Menu oder per svdrpsend) passiert nichts. Wechsel ich hingegen auf einen Kanal auf dem ich vorher kein EPG hatte, wird dieses sofort empfangen und benutzt.
    Es handelt sich um einen vanilla VDR 2.1.6 (selbstkompiliert mit wenigen Plugins) unter Debian Squeeze (als chroot auf meinem NAS). Davor hatte ich lange einen Netceiver, seit kurzem eine OctopusNet mit 4 Tunern, 2 davon für diesen vdr.

    Das ist recht ärgerlich, da ohne aktuelles EPG meine Suchtimer nicht funktionieren...

  • Gibt es mit 0.3.3 bekannte Probleme mit EPG Scan?

    EPG background Scan funktioniert hier, obwohl der entsprechende VDR oft nur 1x am Tag für 30min läuft.

    Du startest das Plugin schon mit "-d 2" wenn Du 2 Tuner Deines Octopus nutzen möchtest?

    Regards
    fnu

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

  • ja und gleichzeitige Aufnahmen auf zwei unterschiedlichen Transpondern funktionieren auch (laufen gerade)... gibt es normalerweise einen Logeintrag wenn der EPGScan startet?


    Also bei mir geht Bakcground EPG Scan mit VDR 2.1.6 (selbstkompiliert) weder auf OpenSuse, noch auf Raspbian noch auf Arch LInux. Eine Analyse des Netzverkehrs mit dem Octopus läßt mich vermuten, dass bei EPG Scan das "PLAY" Kommando and den RTSP nicht geschickt wird, deshalb schickt der Octopus auch keine Daten.

    Wenn ich einen Kanal aufnehme oder angucke, wird das EPG dieses Kanals (und aller anderen Kanäle auf dem gleichen Transponder) emfpangen und gespeichert.

    Natürlich tritt das Phänomen nur auf, wenn keine "echte" DVB Karte im System steckt.

    Hat jemand eine Idee? Sollen wir es an Rolf weitergeben, ich kann gerne bei mir mal den Debugger anschmeißen oder zusätzliche Outputs einbauen, hab das auf einem Test System isoliert? fnu hat doch einen guten Draht zu Rolf, kannst Du da helfen?

  • fnu hat doch einen guten Draht zu Rolf, kannst Du da helfen?

    Kann sein das er nun wieder etwas mehr Zeit hat und einige bekannte Issues behoben werden, er liest hier aber auch mit ... ;)

    Regards
    fnu

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

    Edited once, last by fnu (September 21, 2014 at 10:25 AM).

  • Eine Analyse des Netzverkehrs mit dem Octopus läßt mich vermuten, dass bei EPG Scan das "PLAY" Kommando and den RTSP nicht geschickt wird, deshalb schickt der Octopus auch keine Daten.
    Hat jemand eine Idee?


    Unfortunately I'm too busy to check this out by myself at the moment, but if no PLAY command is sent during the EIT scan, the plugin misses core VDR's SetPid commands. There are also some open bugs in device selection code and those might be also root causes for EIT scan problems.

    In other words, I'd take a closer look at methods cSatipDevice:: SetPid() (some pids are set on) and SatipDevice:: SetChannelDevice() (correct device is selected) while running the EIT scan. The plugin should send a RTSP/PLAY command always after any pid changes.

Participate now!

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