Beiträge von vdrjoe

    Hallo, ich habe zur Zeit einen ähnlichen Wunsch nach einem VDR-SAT_IP-Server und dachte zunächst, dass es bereits ein SAT-IP Ausgabe-Plugin gäbe. Aber minisatip und plugin-sat-ip scheinen nur zwei Seiten derselben Medallie zu sein. OSD nutze ich seit dem Umstieg von einzelnen VDRs auf vomp nicht (mehr) und vermisse das nur, weil es ohne OSD auf dem Headless-VDR-Server schwieriger wird, Plugin-Parameter zu setzen. Denn die OSD-Optionen verstecken sich oft hinter andersnamigem Einträgen in der setup.conf. Ich würde einen VDR-SAT-IP -Server als Alternative zu einem DD Octopus-Net Server sehen, speziell, da dort MTD-Nutzung nicht möglich ist, das vdr-plugin-ddci2 dieses aber bietet. Das Streamdev-Server-Plugin als bereits vorhandene IP-Server-Alternative als SAT-IP Quelle für einen weiteren VDR mit dem plugin-IP-TV funktioniert bei unverschlüsselten Sendern recht gut, bei verschlüsselten Sendern allerdings überhaupt nicht; der empfangende VDR crached bei dem Versuch. Mit dem Streamdev-Client-Plugin funktioniert das Entschlüsseln über den ersten VDR (der mit dem Streamdev-Server-plugin) nur gelegentlich. Der VDR-Manager auf dem Android-Device (nutzt auch Streamdev) scheint allerdings deutlich stabiler mit einer solchen Konfiguration umgehen zu können. Bleibt offenbar nur der Octopus-Net Receiver mit seinen bekannten Einschränkungen als IP-Server-Alternative. Oder ev. TVHeadend, das ich nur vom Namen her kenne.


    Edit: minisatip ist offenbar tatsächlich doch ein SAT-IP-Server um lokale DVB-x Streams per IP-TV weiterleiten zu können, allerdings völlig ohne VDR Funktionen, da es kein VDR-Plugin ist. Korrigiert mich, wenn ich hier Mist erzähle.

    Der Zugriff auf den Http-Stream auf Port 3000 des Servers klappt per VLC.

    Der Streamdev-Server läuft also.

    edit:

    Ein erneuter restart des VDR-B mit dem Streamdev client hat den Erfolg gebracht.

    Keine Ahnung warum es vorher nicht lief?

    VDR ist also offenbar schlau genug den DVB-C Kanal dem stramdev-server(client) zuzuordnen.


    Würde das auch funktionieren, wenn nun z.B. ein weiterer VDR mit DVB-T2 seine Kanäle per Streamdev bereitstellen würde?

    Hallo zusammen,

    ich versuche gerade Kanäle eines VDR A (mit DVB-C Karte) über die Kombi Streamdev-Server auf A und Streamdev-Client auf VDR B (SAT) zu empfangen.

    Im Wiki steht zulesen, man solle einfach die channels.conf (oder Teile davon) des Streamdev-Servers zur channels.conf des Clienten hinzufügen.

    Der SAT VDR B hat dann also eine Channels.conf mit zusätzlichen DVB-C Einträgen.

    Leider bekomme ich keine Verbindung auf dem betreffenden Kanal.

    Beide VDRs laufen headless die betreffenden Einträge in den jeweiligen setup.conf sollten passen:


    Streamdev-Server:




    im Syslog des VDR B (streamdev-client) erscheint beim Versuch den kopierten Kanaleintrag auf Kanal 272 zu tunen folgendes:


    frontend 0/0 irritiert mich hier etwas, ich dachte das wäre lokal?


    Aber laut "ls /dev/dvb" habe ich nun zwei adapter mehr als vorher,

    Wer kann mir auf die Sprünge helfen?

    Danke und Gruß

    Zitat

    Funktioniert das Ding jetzt an der ngene-Karte? Hint: In eigenen Tests habe ich diverse Male festgestellt, dass das CI gerne mal das gesteckte ACL@One4All CAM total unmotiviert "ausgewürgt" hat und dann bis zum Neuladen des ngene-Treibers keine Reaktion mehr auf dem CAM-Slot gezeigt hat. Versprich' Dir davon also bitte nicht zuviel.

    Also, ich habe es eben aufgegeben. Habe nun die Cine V7 C2T2 zusätzlich eingebaut und das FlexCI dort angeklemmt. Das funktioniert sauber.

    An der / den alten Cine S2 wurde mir wahlweise das CI angezeigt ohne CAM, mal auch alles inkl. ACL, aber kein Bild.

    Mit einer der anderen V5.5 Karten dann auch keine ad-hoc Funktion, aber auch kein "Channel unavaílable", nur tiefste Nacht.

    Ev. wäre das Bild noch gekommen, wenn ich geduldiger gewesen wäre.


    Die cax-Einträge sind dabei zum /dvb/adapter? mit gewandert. Ich war mir dann nicht sicher, ob das CAM dann auch eine andere Nummer bekommt, und dementsprechend in der cam.data eingetragen werden muss. Der VDR oder das DDCI2_plugin tragen bei erfolgreichem Kanaltuning über ein anderes CAM dieses zusätzlich in die cam.data Zeilen ein. Ich vermute, dass VDR das dann auch in dieser Reihenfolge versucht und möglicherweise in ein Timeout läuft, bzw. meint, der erste Eintrag ist per default richtig (weil eigentlichg selbst eingetragen??)


    Mit dem CI an der ansonsten bisher ungenutzen DVB-T2-Karte geht es, nun auch mit dem bösen Plugin.

    Wenn ich 'mal viel Zeit habe, baue ich eine der Cine S2 V5.5 Karten aus und teste das nocheinmal separat in einem anderen PC.

    Danke an alle für die Hilfe und die Beseitigung der Bildstörungen beim Empfang über die alte Cine S2 V5.5.

    Jörg

    Der VDR schreibt da selbst hinein (z.B. ändert er die (bei mir falsche) CAM #5 wieder selbstständig in #1, wenn das DDCI2-Plugin an erster Stelle steht.

    Da sich die Daten aber nicht so häufig ändern, geht Deine Methode dann.

    Mein weiches CAM hat laut syslog (mit meinen Einstellungen) die Nummer 2, also werde ich Deinem Beispiel folgen und die Sender manuell in die cam.data eintragen.

    Danke für die Tipps!

    Jörg

    Also, bei mir klappt das nicht.

    Zunächst ist es offenbar doch der VDR, oder ein Plugin, welches die cam.data füttert.

    Das Weiche als erstes gestartet => funktioniert, aber die Sender auf dem Harten werden nicht dekodiert, es auch keine Einträge in der cam.data

    Dann die Reihenfolge umgedreht:

    Das DDCI2-Plugin startet als erstes ( und funktioniert), die Sender werden mit CAM Nummer 1 eingetragen. Die Sender auf dem Weichen funktionieren nicht.

    Nun VDR gestoppt, in der cam.data die 1 in eine 5 geändert

    Rehenfolge wieder geändert und Vdr gestartet => das weiche funktioniert wieder, das Harte allerdings nicht.


    Da der cache ja offenbar dynamisch geschrieben wird, schlägt eine manuelle Zuordnung doch auch spätestens bei einm Transponderwechsel eines Senders fehl?

    1-4 fürs weiche entspricht Deiner O**** Server config? oder ist das default im plugin?

    und was verhindert, dass vdr daran herumspielt?

    weil nur funktionierende Zuordungen neu geschrieben werden?

    d.h. wenn es durch das manuelle Einstellen passt, wird auch nichts verstellt? Ist das so?

    Klingt spannend;)

    Danke

    Okay, ich dachte, der VDR verwaltet diese Datei selbsttätig, (verändert sie also ggf. auch?)?


    Wie werden die CAMs durch nummeriert? (also speziell das weiche CAM)?


    Das ist die funktionierende Variente ohne DDCI2:

    Das funktioniert auch, nur wenn beide aktiv sind geht beides nicht.

    Ich werde mir mal die cam.data ansehen.

    Danke!

    Hallo,

    nachdem nun mein FlexCI in Verbindung mit dem Plugin DDCI2 und den aktuellen Treiber von nst störungsfrei arbeitet, stört mich, dass das böse Plugin nicht mehr mag, wenn ich es wieder aktiviere.

    Sobald dvba** geladen wird, funktioniert auch das Dekodieren per Smartcard und CAM über DDCI2 nicht mehr.

    Bin aber der Meinung, dass das schon einmal ging (mit Bildstörungen beim HW CAM, also alten ngene-Treibern)

    Es gibt auch Hinweise, dass es reicht DDCI2 als erstes Plugin zu laden.


    Meine erste Frage: woher weiss der VDR oder das DDCI2 Plugin, welches Smardcard auf welchem Weg zu nutzen ist?


    Der VDR und seine Plugins (ohne das unausprechliche)

    Die Version vom bösen Teil kann ich gerade nicht checken (bzw. das Plugin aktivieren), da eine Aufnahme läuft.

    Um störungsfreien Empfang über den ngene-Treiber und DDCI2 zu erhalten habe ich wie hier beschrieben, media-build von nst installiert.

    Hallo,

    ich führe mein doch eher spezielles Problem von hier ngene-Treiber: Unterstützung für (fast) alle DuoFlex-Module, kleinere Verbesserungen

    in einem neuen Thread weiter:


    Zur Situation:

    DD Flex-CI mag weder an einer Octopus Bridge V3 noch direkt an einer Cine S2 V5.5 laufen.

    Ein DuoFlex Duo-CI läuft aber problemlos an der Octopus-Bridge (leider nicht an der Cine S2, laut Treiber readme).


    Ein Hinweis in dmesg:


    Das CI wird also "im Prinzip" erkannt, aber: CXD2099AR attach failed


    CI defekt?

    oder Treiber (fehlender Parameter?)?


    Ich habe die betreffenden CI Komponenten gebraucht bei ebay erstanden. Kann daher im Nachhinein leider nicht sicher sagen, ob das Single CI vor update auf nsts neuen Treiber überhaupt funktioniert hat, oder ob ich zuvor immer nur das DuoFlex-CI in Betrieb hatte.

    Da das an der Cine S2 V5.5 aber gar nicht laufen soll, ist es doch wahrscheinlich, dass es vorher einmal ging,

    Da mir die Smartcard nur sporadisch zur Verfügung steht, liegt der erste Test leider schon etwas zurück.


    any hints?


    Jörg

    Danke für den Tipp,

    das war es leider auch nicht, obwohl auch bei meinem Single CI das weiße Halter sehr weit nach vorn verschoben war, also durch das Abziehen bedingt,


    Habe nun das Single CI (mit cxd2099 Chip) an die Octopus-bridge gehängt, geht auch nicht:

    Das ist ein Ausschnitt aus dmesg:

    Das CI wird also "im Prinzip" erkannt, aber: CXD2099AR attach failed


    CI defekt?

    oder Treiber (fehlender Parameter?)?

    Okay, Danke für die Rückmeldung.


    Das heisst, das DDCI2-Plugin benötigt zwingend ddbridge, bzw. die zugehörige Hardware?

    Ein CI läuft also nicht direkt an einer alten Cine V5.5 angeschloßen?

    Das Duoflex-CI nicht wegen der Einschränkungen im Treiber, aber warum nicht ein Single Slot-CI?

    Oder habe ich die folgende Sätze nur völlig falsch interpretiert?

    Zitat
    • Es werden jetzt so ziemlich alle derzeit erhältlichen DuoFlex-Module erkannt und unterstützt (an den Expansion-Connector der v5.5 angeschlossen), inkl. aller DuoFlex CT2/C2T2/C2T2I und der DuoFlex S2 V4. Ausnahme: Die DuoFlex Twin-CI Adapter. => Flex-CI geht also??
    • Der Treiber beschwert sich nicht mehr, wenn kein CI-Flex angeschlossen ist. ==> wenn's denn angeschlossen ist, geht es dann per DDCI2-Plugin oder nicht?


    War da nicht etwas mit geänderter I2C-Adresse?

    Jörg

    Okay, scheint eher ein Selbstgespräch zu sein ;)

    Das letzte Zitat bezieht sich auf den ddbridge Treiber, welche zwar ebenfalls geladen, aber nicht benutzt wird?

    wie auch


    Ich schweife mal kurz etwas ab:

    Ich besitze sowohl ein Flex-CI (single slot, cxd2099) wie auch ein DuoFlex-Dual CI (cxd_irgendetwas, ist zur Zeit nicht verbaut).

    Sind die zueinander bzw. zu meiner alten Cine S2 V5.5 und den Duoflex-PCI-Bridges kompatible?

    Sollte ich das Flex-CI gegen das DuoFlex-CI tauschen, damit der ddbridge Treiber überhaupt genutzt wird?


    Gesagt, getan. Da das DuoFlex Dual CI ja nicht vom ngene-Treiber unterstützt wird habe ich eine Mini-PCIe Bridge genommen, und daran das DuoFlex CI mit dem CAM angeschlosssen.

    Nun wird das CAM erkannt:

    Also mit der Octopus bridge und dem dort angestecktem Dual-Ci klappt alles, die ursprünglich vorhandenen regelmäßigen Bildfehler sind verschwunden.

    So weit, so gut.

    Warum das single-CI nicht direkt an der CineS2 V5.5 läuft weiß ich nicht. Die Variante, das Dual_CI direkt an der Cine S2 V5.5 anzuschliessen, brauche ich ja gar nicht erst auszuprobieren, laut Readme zu nsts-Treiber.

    Ob das Single-CI auch an der Octopus bridge läuft, kläre ich später.

    Danke für's Zuhören ;)

    Jasmin sagt im Readme zum DDCI2-Plugin:

    Zitat
    Code
    1. Pitfalls
    2. --------
    3. If you see this messages in syslog: DDCI-Inf: no DD CI adapter found
    4. and/or DDCI-Err (ddci2.cpp,110): Couldn't open /dev/dvb/adapterX/ciY with mode 0x800: Device or resource busy
    5. then you might forget to remove the redirect assignment in the driver.

    Das "in the driver" bezieht sich auf den hier beschreibenen Treiber, in meinem Fall den ngene, richtig?

    und das folgende

    Zitat
    Code
    1. This plugin obsolets the redirect method of the ddbridge kernel driver.
    2. The Kernel driver must not started with option "adapter_alloc=1|2|3"!

    redirect method <=> eine der Driver-Optionen "adapter_alloc=1" oder "..2" oder "..3" ??

    Ist also keine dieser Optionen gesetzt, wird auch die redirect methode nicht angewendet?

    sehe gerade:

    ich habe ein aktuell nicht mehr erhältliches Flex-CI (single-Slot) , kein Duoflex-CI

    Zitat
    • Es werden jetzt so ziemlich alle derzeit erhältlichen DuoFlex-Module erkannt und unterstützt (an den Expansion-Connector der v5.5 angeschlossen), inkl. aller DuoFlex CT2/C2T2/C2T2I und der DuoFlex S2 V4. Ausnahme: Die DuoFlex Twin-CI Adapter.


    also sollte der hier beschriebene Treiber passen, oder? (habe ja kein DuoFlex Twin-CI, sonder ein Flex-CI (Artikel-Nr: 092003) (single Slot)


    ein

    Code
    1. lsmod | grep cxd
    2. cxd2099 20480 0

    zeigt offenbar, das das Flex-CI gefunden wird, aber nicht genutzt.


    edit:


    Die cine C2/T2 V7 (ddbridge) hatte ich zwischenzeitlich entfernt, das hat aber auch nicht geholfen

    das sagt DDCI-Inf im syslog: