[streamdev] Verschluesselte Kanaele werden bei VTP nicht vom Server entschluesselt

  • Hi,


    ich habe einen Server mit VDR 2.1.6 und einigen Plugins (unter anderem streamdev-server).


    Als Client habe ich einen Reel NetClient I, welcher aktuell noch meinen Reel NetCeiver zum Empfang verwendet. Den NetCeiver moechte ich aber in naher Zukunft loswerden und der NetClient soll dann eben das TV Signal vom VDR Server bekommen.


    Beim NetClient kann man in den Einstellungen das streamdev-client Plugin konfigurieren. Das funktioniert auch mit Free TV Kanaelen soweit (bis auf die nervige "Kein DVB Tuner gefunden" Fehlermeldung). Sobald ich jedoch auf einen Pay TV Kanal schalte (z.B. RTL HD) kann der Kanal nicht entschluesselt werden. Ich kann jedoch den verschluesselten Kanal problemlos in VLC ueber HTTP abspielen.


    Fuer mich sieht das so danach aus, als wuerde der Kanal bei Verwendung von VDR-zu-VDR (VTP) nicht funktionieren. Oder habe ich einfach irgendetwas in der Konfiguration vergessen?

  • Ich verwende 2.0.6 und bei mir funktioniert das ohne Probleme und ich kann mich nicht erinnern, da was Besonderes konfiguriert zu haben.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • hi, ich habe ähnliches problem auch schon festgestellt. mit 2.0.6 funktioniert es bei mir auch ,aber mit meinem 2.1.6 test systemen geht das auch nicht.
    benutze ich Vnsi, xvdr und lokales frontend funktioniert das , sobald der zugrif via streamdev kommt geht es genau einmal umschalten und danach kann ich nichts mehr machen.


    ich denke das ist darauf zurück zu führen
    streamdev stops when channel is not decryptable


    ich sehe die selben fehler im LOG und kurz danach hängt sich der vdr mit yavdr testing und auch mein vdr4arch mit 2.1.6 komplet weg




    gruß
    karsten

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf

    The post was edited 1 time, last by niedi_74 ().

  • ch denke das ist darauf zurück zu führen http://projects.vdr-developer.org/issues/1953


    Korrekter link


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Hi,


    ist das wegen des neuen CAM Handlings seit VDR 2.1.3?



    [Announce] VDR Developer version 2.1.3


    Gruß
    Viktor

  • Habe jetzt noch ein bisschen rumexperimentiert.


    Als Client habe ich mir heute mal auf einem Raspberry Pi raspbian, vdr 2.1.6, das rpihddevice plugin sowie den streamdev-client installiert.


    Ab und zu funktioniert das Entschluesseln. Aber meistens dauert es sehr lange, bis der Stream mal abgespielt wird. Bei SD funktioniert es, wie auch beim NetClient, problemlos.

  • Das Ticket habe ich aufgemacht. Mittlerweile gehe ich davon aus, dass es nicht am Cam-handling liegt, denn streamdev hat ja keinen Einfluss drauf. Ich schätze es liegt an dem ChannelChange.
    Wenn ich mir das bei plugin-xvdr anschaue, so sehe ich beim ChannelChange ein Detach und anschließend ein GetDevice was bei streamdev nicht der fall ist. Ausserdem wird auch vorher geprüft ob ein cam vorhanden ist (generell bei swictchannel) das den Sender auch entschlüsseln kann.
    Das ganze hängt vermutlich damit zusammen, dass der VDR neuerdings bei jedem geänderten PID ein re-tune durchführt was mMn. nur in den seltensten Fälle nötig ist (hat ja bisher auch so funktioniert).


    schmirl
    Falls du hier mitliest - kannst du dir das evtl. mal aschauen?



    Gruss
    tec

  • Leider kann ich das CAM-Zeug selber nicht testen und habe momentan auch keine Zeit für VDR. Interessant wäre aber, ob es sich um das gleiche Problem handelt, wegen dem ich kls schon angeschrieben habe. Kann mal jemand testen, ob das Problem verschwindet, wenn man diese Änderung aus VDR 2.1.4 rückgängig macht: Tester gesucht: Streamdev-Server mit VDR 2.1.4+ Funktion ChannelChange?


    tecfreak : Du schreibt im Ticket

    Quote

    Would be nice if streamdev could handle the cams like it was suggested by kls for vdr 2.1.x


    Worauf beziehst Du Dich da?

  • Auf eine Aussage von Manio auf seinem git-repo. Hab aber die ML und Changelogs durchforstet und nichts diesbezüglich gefunden.
    Denke dass das cam-handling damit nicht wirklich was zu tun hat und Manio in dem Punkt nicht ganz richtig lag mit seiner Vermutung.


    Hab vdr 2.1.6 auch mit xvdr getestet und da gab es keinerlei Probleme beim Umschalten. Den Fehler führe ich mittlerweile auch auf die channelchange Funktion zurück soweit ich das als Laie überhaupt beurteilen kann oder das erneute GetDevice ist nur ein workaround und das cam-handling des vdr seit 2.1.4 in der Tat nicht ganz korrekt. Ich teste das am WE mal und mach die Änderung aus 2.1.4 wieder rückgängig.



    Gruss
    rec

  • Ich nutze streamdev zusammen mit dem satip-Plugin. Gepatched habe ich nichts. Läuft bei mir jetzt problemlos. Vor 2.1.7 gings bei mir mehr schlecht als recht, was verschlüsselte Sender angeht. Muss aber dazu sagen, dass ich streamdev über http nutze und nicht über VTP derzeit.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • In VDR 2.1.7 hat kls einen Bug im neuen CAM-Code gefixt. Hatte schon jemand die Möglichkeit, das Problem mit 2.1.7 oder 2.1.8 zu testen (ohne den Patch)?


    läuft sehr gut mit 2.1.7 dem vdr4arch auf meinem zxyel 325 ... benutze momentan ausschließlich Http .


    gruß
    karsten

    Banana PI MLD server

    Banana PI Satip Server


    ESXI MLD 5.x




    Raspberry mit Kodi als Frontend , mit waf