CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

  • OK, dann werde ich mir das anschauen 8)


    Ich hatte noch keine Zeit, weil ich mal geschlafen habe, aber nur ein paar Gedanken von heute Morgen:
    Mein CI Modul funktioniert in einer TechnoTrend TT-budget S2-3200 HDTV-S2. Diese hat einen anderen Chip für das CI Interface (denke ich).
    Der en50221 Protokoll Treiber ist seit Jahren wenig angepasst worden, also scheint der zu funktionieren, sieht man mal vom ev. Fehlerhaften Error Handling ab, welches ich mir noch anschauen werde.


    Also liegt die Vermutung nahe, dass der Write Error aufgrund eines Kommunikationsproblems am PCMCIA Interface auftritt. Das wiederum wird durch die Parameter beim Setup des cxd2099ar eingestellt. Hier nun kommt der cxd2099 Treiber ins Spiel. Abgesehen vom Datenblatt, hat irgend jemand einen guten Draht zu Digital Devices, damit mir der dortige Entwickler ev. die Initialisierung der Register des Chips schicken könnte, wie das unter Windows gemacht wird (oder den Source Code ;D). Ich überprüfe das dann mit dem Linux Treiber und schau mal ob sich dort das Problem finden lässt. Ich unterschreibe auch ein NDA!
    Es kann doch nicht sein, dass wir Linux Entwickler immer das Rad neu erfinden müssen und ich ev. ein Oszilliskop an die PCMCIA Schnittstelle anhängen muss um das Timing zu überprüfen? Hier könnte DD durchaus Daten liefern, wenn ich schon meine Zeit investiere und das Ding zum Laufen bringen möchte :O


    LG
    Jasmin


  • Also liegt die Vermutung nahe, dass der Write Error aufgrund eines Kommunikationsproblems am PCMCIA Interface auftritt.


    ORF ist hell!!! Mein CAM funktioniert mit meinem Patch 8)
    Die Patchbeschreibung findet man hier.


    Wenn ich wieder ausgeschlafen bin und Zeit habe, dann werde ich mir mal das ddci Plugin von Lars installieren und die notwendigen Debug Ausgaben im Kernel einbauen, damit Lars, oder ich das Problem finden können.


    LG
    Jasmin

  • Hallo,


    ich durchforste nun schon seit einiger Zeit alle möglichen Threads zum Thema CineS2 und CI - erst mal vielen Dank an alle die sich da reinhängen!


    Da auch immer wieder von der TT3200 die Rede ist, ist mir nicht ganz klar welche Kombination(en) aus TV-Karte und CI aktuell funktionieren.


    Ich würde gerne einen DVB-S2 VDR mit 4 Tunern aufbauen mit dem ich auch ORF schauen/aufzeichnen kann.


    Wegen der Ausbaufähigkeit hätte ich als TV Karte die DigitalDevices Cine S2 V6.5 als Favoriten.


    Wenn ich da noch das DigitalDevices Common Interface und ein Alphacrypt CAM dazunehme - funktioniert dann die ORF Entschlüsselung (mit vorhandener ORF-Karte)?


    Vielen Dank!


    Viele Grüße
    Markus

  • An dieser Stelle... das CI ist immer nur mit einem Tuner verbunden. Sofern also nicht alle diese verschlüsselten Sender auf einem Transponder liegen wird es Probleme geben weil hin und wieder ein Sender nicht zu entschlüsseln ist.
    Dessen sollte man sich bewust sein.


    cu

  • Wenn ich da noch das DigitalDevices Common Interface und ein Alphacrypt CAM dazunehme - funktioniert dann die ORF Entschlüsselung (mit vorhandener ORF-Karte)?

    Wie Keine_Ahnung schon geschrieben hat, funktioniert derzeit nur die eindeutige Zuordnung zw. einem CI und einem Tuner. Alles andere geht derzeit im VDR nicht.
    Du brauchst also für jeden Tuner ein CI+CAM+Karte. Keine praktikable Lösung!


    Sorry, aber hier ist derzeit noch Arbeit nötig und ich bin momentan ganz unten im cxd2099 Treiber am werkeln. Genauer bin ich mit dem Entwickler in Kontakt, der das Datenblatt hat. Glücklich bin ich derzeit nicht damit.
    In den oberen Schichten, genauer im VDR stimmt auch was nicht, aber das suche ich erst, wenn es unten geht.


    Erst wenn die 1:1 Zuordnung zw. CAM und Tuner 100%ig funktiniert, kann man mit den ddci Plugin weiter machen, was dann die dynamische Zuordnung von CAMs und beliebigen Tunern erlaubt (oder der VDR kann das doch irgendwie jetzt schon?). Leider wird das auch einen stärkeren Prozessor brauchen, denke ich, weil der Stream nicht innerhalb des Kernels per DMA zw. CAM und Tuner übertragen werden kann, sondern über den UserMode und die Device Schnittstelle drüber muss. Zumindest habe ich das so verstanden (selbst Analysiert habe ich es noch nicht).

  • Vielen Dank für die schnellen Antworten!

    das CI ist immer nur mit einem Tuner verbunden

    Ich nehme an, diese Einschränkung gilt auch für andere Tv-Karten/CI - Kombinationen (wie die TT3200)?


    Sofern also nicht alle diese verschlüsselten Sender auf einem Transponder liegen wird es Probleme geben

    Ich könnte mit der Einschränkung nur einen Transponder entschlüsseln zu können vorerst leben (zumal die Hoffnung besteht, dass diese mal überwunden wird). Es darf halt kein Zufall sein ob der Tuner mit CI belegt wird oder nicht, der VDR müsste die Tuner "intelligent" belegen und nicht zufällig jenen mit CI für das erste FTA Programm nehmen obwohl noch 3 andere ohne CI frei sind.


    ich bin momentan ganz unten im cxd2099 Treiber am werkeln

    Ich hoffe, Du kommst voran und DigitalDevices unterstützt Dich dabei - fördert ja auch deren Absatz!


    Grüße
    Markus

  • Ich nehme an, diese Einschränkung gilt auch für andere Tv-Karten/CI - Kombinationen (wie die TT3200)?


    Ich verstehe die Frage nicht. Jasminj hat doch geschrieben, dass es eine Einschränkung des VDRs und nicht der Hardware ist.


    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

  • Bliebe noch die Frage mit der "intelligenten" Tuner - Belegung durch den VDR.


    Der vdr nimmt das ca-Device, das die gleiche Nummer wie das Frontend hat.
    Du musst also den Treiber so laden, dass alle Devices in einem Adapter angelegt werden. Und dann entscheidet es sich von ganz alleine, welcher Tuner das CAM zugeordnet bekommt.


    Für FTA-Sender versucht der vdr ein Device ohne CAM zu benutzen, für verschlüsselte geht dann nur das eine.
    Einfach mal in diesem und dem anderen Thread zum Treiber suchen uns lesen, Stichwort "redirect".


    Lars.

  • Wobei in meinem Posting vermutlich auch nicht so ganz klar rausgekommen ist was ich meinte...


    Um es nochmal deutlicher zu schreiben (auch für die stillen Mitleser):
    Angenommen ORF1 und ORF2 liegen auf verschiedenen Transpondern (ich kenne die genaue Östereich Pay-TV Verteilung nicht)... Startet eine Aufnahme auf ORF1 dann ist alles gut (es wird der Tuner mit dem CI genommen). Startet (während die erste Aufnahme noch läuft) eine weitere auf ORF2 dann wird sie scheitern, weil der Tuner mit dem CI schon mit dem ORF1 Transponder belegt ist.


    Es ist also erst mal das Problem das ein CI Modul nicht zwei Tuner gleichzeitig bedienen kann. Das ist generell bei CI so.
    Der Netceiver kann so etwas, allerdings ist mir jetzt nicht so ganz klar ob man hier Code benötigt der auf die speziellen Bedürfnisse der verschiedenen Verschlüsselungsysteme zugeschnitten ist. Hier müssen ja verschiedene Transportströme neu gemischt werden um einen zu erhalten den man durchs CI schickt.



    Eine Alterantive Lösung des Problems wäre wenn der VDR den vershclüsselten Datenstrom auf HDD speichern könnte. Dann würde (um beim obrigen Beispiel zu bleiben) die ORF2 Aufnahme verschlüsselt gespeichert und später (wenn das CI frei ist) durchs CI geschickt. Einige komerzielle Receiver machen es so. Und es ist vermutlich einfacher zu implementieren als der Multi-Transponder Support wie es der Netceiver bietet.


    cu

  • Ich hoffe, Du kommst voran und DigitalDevices unterstützt Dich dabei - fördert ja auch deren Absatz!

    Ich schrieb in meinem Post, dass ich mit dem Entwickler in Kontakt bin. Derzeit teste ich einen Patch, der meiner Meinung nach etwas verbessert hat, was anderes aber verschlechtert. Das Datenblatt habe ich nicht und bekomme es derzeit auch nicht. Weiß nicht mal ob ich es will, weil dann muss ich die Sache zum Laufen bringen. So kann ich mich auf den anderen Entwickler ausreden :D


    Ich verstehe die Frage nicht. Jasminj hat doch geschrieben, dass es eine Einschränkung des VDRs und nicht der Hardware ist.

    Also hier versuche ich mal einen "Qualified Guess". Die TT3200 und soweit mir bekannt (fast) alle anderen Karten ordnen das CI intern immer den Tuner der Karte selbst zu. Somit gibt es gar nicht die Flexibilität das CI der einen Karte vom Tuner einer andern zu benutzen. Erst das DD CI Modul kann so flexibel eingesetzt werden. Man möge mich hier korrigieren, wenn ich etwas falsches mit meinen spärlichen Informationen hinein interpretiere :O
    Für diese Flexibilität fehlt der Support im VDR. Deshalb auch die Sache mit dem redirect und dem adapter_alloc=3, damit die Karten von DD dem VDR wie alle anderen präsentiert werden.


    Es ist also erst mal das Problem das ein CI Modul nicht zwei Tuner gleichzeitig bedienen kann. Das ist generell bei CI so.

    Das ist meiner Meinung nach nicht in Stein gemeisselt. Ein CAM kann sehr wohl verschiedene Streams dekodieren, wenn es dafür gebaut wurde und der VDR kann damit auch umgehen. Zumindest fragt er bei der CAM Initialisierung ob es Multichannel fähig ist. Das weiß ich vom syslog, wo die entsprechende Ausgabe vom VDR kommt. Bei meinem neuen CAM sagt der VDR das jetzt.
    Die Schlüsselkarten können sowieso für viel mehr Channels Schlüssel generieren, sonst würden die ganzen bösen Dinge ja nicht funktionieren. Es gibt da zwar ein Limit in der Datenrate zw. CI Interface und CAM, aber es sollten sich mehr als 2..4 Streams gleichzeitig ausgehen.
    Woher der Stream kommt ist dem CAM prinzipiell egal. Wenn die HW es zulässt, wie die Karten von DD, dann können diese auch von beliebigen Tunern kommen und nicht nur von fix verdrahteten. Das Muss dann aber eine SW machen und hier kommt dann das ddci Plugin des VDRs zum Einsatz.


    Der Netceiver kann so etwas, allerdings ist mir jetzt nicht so ganz klar ob man hier Code benötigt der auf die speziellen Bedürfnisse der verschiedenen Verschlüsselungsysteme zugeschnitten ist. Hier müssen ja verschiedene Transportströme neu gemischt werden um einen zu erhalten den man durchs CI schickt.

    Weiß nicht was du damit meinst? Vom Verschlüsselungssystem hängt das gar nicht ab, soweit ich weiß. Man muss aber irgendwelche IDs umdrehen, damit mehrere Channels pro CAM funktionieren. Das hat Lars irgendwo mal erklärt, ist aber vorerst Zukunftsmusik, weil derzeit ja nicht einmal ein einziger Channel per SW durch ein CAM gejagt werden kann, weil das ddci Plugin noch nicht tut. Derzeit geht es eben nur durch die Fixe Zuordnung vom Tuner zum CI innerhalb des Kernels, wo es mit DMA gemacht wird (soweit ich flüchtig gesehen habe).


    Eine Alterantive Lösung des Problems wäre wenn der VDR den vershclüsselten Datenstrom auf HDD speichern könnte. Dann würde (um beim obrigen Beispiel zu bleiben) die ORF2 Aufnahme verschlüsselt gespeichert und später (wenn das CI frei ist) durchs CI geschickt. Einige komerzielle Receiver machen es so. Und es ist vermutlich einfacher zu implementieren als der Multi-Transponder Support wie es der Netceiver bietet.

    Na ja, dann musst du aber auch die entsprechenden Key Infos (sorry weiß jetzt nicht wie der Fachbegriff ist) mit speichern und einiges im VDR Programmieren, was es jetzt noch nicht gibt. Außerdem weiß ich nicht wie du bei einer Karte die HW mäßig den Tuner mit dem CI verkoppelt, nachträglich den Stream und die Keys rein bringen willst? Das würde wieder nur mit dem DD CI funktionieren und dafür fehlt derzeit der SW Support, womit sich die Katze in den Schwanz beißt.


    LG
    Jasmin

    Einmal editiert, zuletzt von jasminj ()

  • Moin!


    Weiß nicht was du damit meinst? Vom Verschlüsselungssystem hängt das gar nicht ab, soweit ich weiß. Man muss aber irgendwelche IDs umdrehen, damit mehrere Channels pro CAM funktionieren. Das hat Lars irgendwo mal erklärt, ist aber vorerst Zukunftsmusik, weil derzeit ja nicht einmal ein einziger Channel per SW durch ein CAM gejagt werden kann, weil das ddci Plugin noch nicht tut. Derzeit geht es eben nur durch die Fixe Zuordnung vom Tuner zum CI innerhalb des Kernels, wo es mit DMA gemacht wird (soweit ich flüchtig gesehen habe).


    Und hier mein Halbwissen:
    Ein TS enthält u.a. eine PMT, in der die Programme mit ihren PIDs stehen. Irgendwo gibt's dann noch Infos zu den CA-IDs (ich glaub, das Ding heißt CAT). Die PIDs und CA-IDs müssen dem CAM mitgeteilt werden, damit das die entsprechenden Schlüssel herausrückt, mit dem der Stream dann entschlüsselt werden kann. Wenn man jetzt die Streams von verschiedenen Transpondern gleichzeitig entschlüsseln will, muss man diese ganzen IDs natürlich aus allen zusammensammeln und entsprechend an das CAM weiterreichen. Und hier kann es (theoretisch) zu einem Problem kommen, wenn verschiedene Programme auf verschiedenen Transpondern die gleichen PIDs für ihre Elementary Streams benutzen. Dann muss die Software den TS umschreiben und die PIDs so manipulieren, dass sie eindeutig sind, damit das CAM nicht durch'n Tüdel kommt.


    Bei den "alten", festverdrahteten CIs ist es so, dass die Hardware (Demod und CI) den Transfer des TS selbst übernehmen (oder der Treiber, so genau weiß ich das nicht), so dass der vdr nur das CAM konfigurieren und steuern muss. Auf dem dvr-Device kommen dann automatisch die entschlüsselten Daten an.


    Das DD CI ist losgelöst von einer DVB-Karte. In der v4l/dvb-Spezifikation ist solche Hardware noch überhaupt gar nicht bedacht, so dass es leider noch keinen Standardweg gibt, um mit solcher Hardware zu kommunizieren. Deshalb hat der Treiber einfach ein altes, nicht mehr benutztes Device (sec) recycelt, in das man den verschlüsselten Stream schreiben kann, um ihn aus dem selben Device wieder lesen zu können (jeweils mit einem writeonly und einem readonly descriptor, wurde mir gesagt). D.h. aber, dass der ganze Transfer über den Userspace läuft. Außerdem müssen immer ganze TS-Blöcke geschrieben werden. Das ist ziemlicher IO-Aufwand, weshalb die CPU-Last da stark ansteigt.


    Da sind also viele kleine Teilprobleme, die angegangen werden müssen. Macht in der Summe schon einen ziemlichen Brocken. :)
    Und da mein Wissen eben nur halb ist und es auch sonst noch keiner getan hat, bei dem man abgucken könnte (wenn ich mich irre, bin ich über jeden Link dankbar), ist die größte Arbeit also erst mal, überhaupt das Wissen zu entdecken und zu verstehen...


    Lars.

  • Ein CAM kann sehr wohl verschiedene Streams dekodieren, wenn es dafür gebaut wurde und der VDR kann damit auch umgehen. Zumindest fragt er bei der CAM Initialisierung ob es Multichannel fähig ist. Das weiß ich vom syslog, wo die entsprechende Ausgabe vom VDR kommt. Bei meinem neuen CAM sagt der VDR das jetzt.
    Die Schlüsselkarten können sowieso für viel mehr Channels Schlüssel generieren, sonst würden die ganzen bösen Dinge ja nicht funktionieren. Es gibt da zwar ein Limit in der Datenrate zw. CI Interface und CAM, aber es sollten sich mehr als 2..4 Streams gleichzeitig ausgehen.


    Wenn ich jetzt nicht komplett daneben liege bezieht sich das (Multichannel, VDR Logausgabe) nur auf die Möglichkeit mehere Sender eines Transponders gleichzeitig zu entschlüsseln. Das könen AFAIK nicht alle CI-Module.


    Das Problem was ich ansprach sind ja mehere Programme verschiedener Transponder. Das ist ja wieder ein komplett anderer Fall.


    Na ja, dann musst du aber auch die entsprechenden Key Infos (sorry weiß jetzt nicht wie der Fachbegriff ist) mit speichern und einiges im VDR Programmieren, was es jetzt noch nicht gibt. Außerdem weiß ich nicht wie du bei einer Karte die HW mäßig den Tuner mit dem CI verkoppelt, nachträglich den Stream und die Keys rein bringen willst? Das würde wieder nur mit dem DD CI funktionieren und dafür fehlt derzeit der SW Support, womit sich die Katze in den Schwanz beißt.


    Das war ja jetzt auch kein konkreter Vorschlag, das war eher so allgm. nen Ansatz wie man das Prolbem "Multitunersystem mit einem CAM" legal lösen könnte. Also meines wissens nach wäre das die einzig brauchbare Richtung um das Problem zu lösen.


    cu

  • Wenn ich jetzt nicht komplett daneben liege bezieht sich das (Multichannel, VDR Logausgabe) nur auf die Möglichkeit mehere Sender eines Transponders gleichzeitig zu entschlüsseln.

    Das denke ich auch, sonst wäre das ddci Plugin nicht notwendig.


    Das könen AFAIK nicht alle CI-Module.

    Deshalb habe ich mir extra um ca. 100 Euronen das Alphacrypt Classic zugelegt, damit ich Multichannel testen kann. Mein altes Irdeto kann zwar nur einen Channel dekodieren, aber es hat die Fehler im cxd2099 Treiber und im Layer drüber getriggert. Somit ein gutes Modul zum Testen.


    LG
    Jasmin

  • Mit kernel-3.8.0 lassen sich leider die DD Treiber nicht bauen. :(



    Code
    vdr01_64 ~ # uname -a
    Linux vdr01_64 3.8.0-gentoo #1 SMP PREEMPT Fri Feb 22 20:44:52 CET 2013 x86_64 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz GenuineIntel GNU/Linux
    vdr01_64 ~ #
  • Ich habe hier keinen aktuellen Kernel, aber könnte dir das helfen.
    Wenn du es bis Sonntag nicht schaffst, kann ich vielleicht was machen. Muss nur erst alles runterladen.
    Mal sehen, ob es mit dem media-tree staging/for_v3.9 auch auftritt, weil den habe ich ausgecheckt.

    2 Mal editiert, zuletzt von jasminj ()

  • THX @ jasmini.


    S:oren hat dort geschrieben:


    __devinit, __devexit and __devexit_p attributes and macros have been removed in linux-3.8, and so they also must be removed in all drivers (or defined empty as compatibility fix).


    Regards,
    S:oren


    Leider aber weiss ich nicht, wass ich damit anfangen soll.

  • Leider aber weiss ich nicht, was ich damit anfangen soll.

    Es gab da schon im November einen Patch für neuere Kernels. yaVDR 0.5.0 benutzt aber Ubuntu als Basis und somit Kernel "3.2.0-36-generic #57-Ubuntu". media-experimental ist primär für diese Distribution gedacht (denke ich). Die von media-experimental benutzte Version des ddbridge Treibers ist vom 14.9.2012, somit vor dem oben angesprochenen Patch.


    Mein medie-tree (staging/for_v3.9) baut gerade. Werde dann den ddbridge vom media-experimental dort rein kopieren und mal schauen wie ich dir das löse, weil wir abhängig von der Kernel Version die fehlenden Defines erzeugen müssen, oder nicht, damit wir ein media-experimental für ältere und neuere Kernels haben können.
    Der ddbridge Treiber in media-experimental kommt von "ngene-octopus-test/linux/drivers/media/dvb/ddbridge". Im Verzeichnis "ngene-octopus-test" sind viele verschiedene Treiber für verschiedene Karten. Ich habe keine Zeit alles zu patchen. Ich kann dir nur ein Pattern liefern, das du dann verwenden kannst, in welchem Treiber auch immer das Problem auftritt.

  • Werde dann den ddbridge vom media-experimental dort rein kopieren und mal schauen wie ich dir das löse, ..

    Der Fehler war bei mir nicht reproduzierbar, weil in meinem Tree die defines noch da sind.
    Im 3.8er Repo sind die defines in include/linux/init.h entfernt worden. In meiner Version sind die Zeilen noch da. Kommentiere ich das dort nämlich aus, kann ich deinen Fehler reproduzieren.


    Du kannst einfach folgende Zeilen in "include/linux/init.h" vor der Zeile /* Used for HOTPLUG_CPU */ rein kopieren. Dann müssten alle Treiber in media-experimental wieder bauen:

    Code
    #define __devinit
    #define __devinitdata
    #define __devinitconst
    #define __devexit
    #define __devexitdata
    #define __devexitconst

    Patch mach ich dir keinen, weil der ev. in zukünftigen Versionen nicht mehr applied, weil media-experimental wird sicher noch eine Weile so bleiben, wie es ist, denke ich.
    Alternativ kannst du die Defines nur in den betroffenen Files am Beginn rein geben (nach der include Orgie), was aber mühsamer sein wird, weil sicher auch andere Files von media-experimantal betroffen sind.


    LG
    Jasmin

    Einmal editiert, zuletzt von jasminj ()


  • Du kannst einfach folgende Zeilen in "include/linux/init.h" vor der Zeile /* Used for HOTPLUG_CPU */ rein kopieren. Dann müssten alle Treiber in media-experimental wieder bauen:

    Code
    #define __devinit
    #define __devinitdata
    #define __devinitconst
    #define __devexit
    #define __devexitdata
    #define __devexitconst


    Patch mach ich dir keinen, weil der ev. in zukünftigen Versionen nicht mehr applied, weil media-experimental wird sicher noch eine Weile so bleiben, wie es ist, denke ich.
    Alternativ kannst du die Defines nur in den betroffenen Files am Beginn rein geben (nach der include Orgie), was aber mühsamer sein wird, weil sicher auch andere Files von media-experimantal betroffen sind.


    Eigentlich gehören die Module gerichtet. Wenn man es neu definiert, dann bitte so:

    Code
    #define __devinit  __init
    ....


    Es gehört dann in compat.h rein.


    Gruß
    e9hack

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!