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

@ real_schorsch,

Wenn ich das richtig verstehe, dann braucht man "nur" den Patch auf vdr-1.7.x anzupassen und evtl ein paar Pfade bei den Includes?

Bei der "reel.h" habe ich gesehen, dass die auf die "reeldvb.h" zeigt.

#include "../../../kernel/reeldvb/reeldvb.h"

Gibt es zu der "reeldvb.h" auch einen direkten download Link?

Man müsste halt noch rausfinden, wie man bei den Tunerkarten die Datenstromverschaltung macht. Ich kenne die Karten halt nicht, daher kann ich dazu wenig sagen. Mit dem vdr-1.4 hat das jedenfalls bei der Lite geklappt, ich zweifele aber, dass die Portierung mit 1-2 Zeilen gemacht ist. Als "Inspiration" sollte es aber auf jeden Fall taugen.

> Gibt es zu der "reeldvb.h" auch einen direkten download Link?

svn://reelbox.org/testing/src/kernel/reeldvb/

Das ist aber "nur" der Kerneltreiber für das Lite-DVB-FPGA, vom .h werden da AFAIR nur die ioctl-Namen gebraucht.

Gibts die Reelsourcen eigentlich auch irgendwo per Web browsbar?

Ich hatte schon öfter mal geschaut obs da für das bgprogress Plugin was neues gibt. Aber irgendwie hatte ich es nie geschafft die Reel Quellen zu finden.

cu

Ich habe mir mal den Patch angesehen. Leider aber sind die Unterschiede zum aktuellen VDR für mein Verständnis viel zu groß. Da ich leider kein "C" kann und mich schon garnicht mit der Treiberentwicklung unter Linux auskenne, werden sich da wohl die Experten darum kümmern müssen.

Die Octopus Bridge ist ja auch ein FPGA. In wie fern man da was aus den von real_schorsch genannten Sourcen verwenden kann, kann ich aus den o.g. Gründen leider nicht sagen.....

Zum Thema : "Die Welt ist halt undankbar ..."

Tja, leider ist das nunmal so. Es ist halt wesentlich einfacher für "100KEUR" einen billig Receiver zu entwickeln und diesen dann 20 MIO mal für 19,99 zu verkaufen, als für das gleiche Geld etwas hochwertiges zu entwickeln, wo es nur wenige ausgesuchte Kunden (Bastler) gibt, die dann auch bereit sind, diesen Entwicklungsaufwand zu honorieren und vorallen auch entsprechend zu bezahlen....

> Gibts die Reelsourcen eigentlich auch irgendwo per Web browsbar?

Soviel ich weiss nicht... Aber einmal den Tree zB. ab testing/src/vdr-plugins (oder eins höher) auschecken beschleunigt das ganze schon etwas...

Zitat von C-3PO

Ich habe mir mal den Patch angesehen. Leider aber sind die Unterschiede zum aktuellen VDR für mein Verständnis viel zu groß. Da ich leider kein "C" kann und mich schon garnicht mit der Treiberentwicklung unter Linux auskenne, werden sich da wohl die Experten darum kümmern müssen.

Ich habe mir den Patch auch mal kurz angesehen, aber das da ein Treiber gepatcht wird, ist mir nicht aufgefallen. Ist doch alles VDR. Habe ich was übersehen?

Gerald

Zitat von gda

Ich habe mir den Patch auch mal kurz angesehen, aber das da ein Treiber gepatcht wird, ist mir nicht aufgefallen. Ist doch alles VDR. Habe ich was übersehen?

Bei dem Patch nicht, bei dem "..../kernel/reeldvb/ - Zeugs" aber schon.

Zitat von C-3PO

Zitat von »gda«



Ich habe mir den Patch auch mal kurz angesehen, aber das da ein Treiber gepatcht wird, ist mir nicht aufgefallen. Ist doch alles VDR. Habe ich was übersehen?

Zitat von C-3PO

Bei dem Patch nicht, bei dem "..../kernel/reeldvb/ - Zeugs" aber schon.

Also doch was übersehen, danke. Hatte das nur kurz überflogen und dachte das Plugin reicht.

Gerald

Zitat von real_schorsch

> Gibts die Reelsourcen eigentlich auch irgendwo per Web browsbar?

Soviel ich weiss nicht... Aber einmal den Tree zB. ab testing/src/vdr-plugins (oder eins höher) auschecken beschleunigt das ganze schon etwas...

Danke, das war hilfreich. Jetzt kann ich da schön stöbern.

cu

> Also doch was übersehen, danke. Hatte das nur kurz überflogen und dachte das Plugin reicht.

Fast, aber irgendwie/wer muss doch die CAMs hardwaremässig an die verschiedenen Tuner binden. Das ist eher was für den Kerneltreiber der jeweiligen Karte.

Zitat von real_schorsch

irgendwie/wer muss doch die CAMs hardwaremässig an die verschiedenen Tuner binden.

Ein Stückchen Bindfaden reicht da wohl nicht??

Wenn ich hier alles richtig gelesen habe kann man mit der CI/CAM-Schnittstelle nachträglich einen Stream entschlüsseln.
Also

Terminal 1:
dd bs=188 if=test_enc.ts of=/dev/dvb/adapter2/sec0

Terminal 2:
dd bs=188 if=/dev/dvb/adapter2/sec0 of=test.ts

Leider kann der VDR ja nicht verschlüsselt aufzeichnen.
ansonsten könnte man das ja als Postprocessing über die Aufname laufen lassen.

Wie sieht das eigentlich aus wenn ich folgendes durchführen würde

Terminal 1:
dd bs=188 if=test_enc.ts of=/dev/dvb/adapter2/sec0
Terminal 2:
dd bs=188 if=test2_enc.ts of=/dev/dvb/adapter2/sec0
Terminal 3:
dd bs=188 if=/dev/dvb/adapter2/sec0 of=test.ts

Geht das? Bzw. wie genau ist das multistream decoding realisiert.
Interesse daran dafür etwas zu entwickeln hätte ich schon legales KabelTV decoding mit mehreren karten ist ansonsten halt sehr teuer ( 1 CAM+Chipkarte je Tuner).
Ich dachte da an so einen art virtuellen FF DVB adapter d.h VDR oder auch TVHeadend sehen das CAM nicht sondern tunen auf den channel und bekommen den ohne cam/ci steuerung dekdiert raus.
Das device fasst beliebige DVB devices und ein CI/CAM zusammen.

Gibt es zu dem ganzen CI/CAM kram Aublauf, APIs etc irgendeine docu oder ist die mal wieder der Source.

Zitat von UFO

Warum habe ich nur das Gefühl, daß so etwas sehr schnell in Richtung illegaler Aktivitäten abdriften könnte?

Du weist das einige seriöse Rceiverhersteller sowas ganz legal in ihre Receiver einbauen (z.B. Humax)? Ist keine inovative neue Idee sondern ein alter Hut.

Das ist nämlich durchaus eine Möglichkeit das "ein CAM und viele Tuner" Problem zu umgehen ohne auf Kartenleser zurückgreifen zu müssen.

cu

morgen,

hat hier eigentlich nochmal einer weiter an dem CI von DD gespielt?

Nosti

Morgen.

Wenn man die ganze OT Diskussion mal aussen vor lässt.

Wenn ich die Mailingliste richtig verstanden habe heisst das Gerät nicht mehr sec0 sondern caio0 (CA-I/O) - wenn dem nicht so ist möge man mich korrigieren.

Was ich mich frage (ich kann es nicht umsetzen, nein), - woher weiss man das ein entsprechendes Gerät vorhanden ist ? Gibt es eine entsprechende Logik ? (z.B. Wenn sich der Name wirklich geändert hat, würde es reichen auf das vorhandensein des caio devices zu überprüfen und danach versuchen das ca zu initialisieren, wenn erfolgreich benutze dies ?)

Ansonsten wird man (wahrscheinlich vor dieser Prüfung) beim Start in die DVB Geräte hängen müssen wie es andere Plugins auch tun. Hier fehlt wahrscheinlich nur das Besitzer einer solchen Karte mit PayTV und CAM UND Fähigkeit es umzusetzen. Betrifft diese Technik alle DigitalDevices kompatiblen Geräte (ddbridge/ngene Karten) ?

Moin!

Ich habe eine FlexDuo mit C/T-Doppeltuner und CI-Modul und wäre bereit, den vdr anzupassen. Ich hatte auch schon ein CAM inkl. Karte im CI, aber trotzdem sagt ddbridge, dass kein Modul am Tap2 wäre.
Stromversorgung hab ich mehrmals kontrolliert. Nächste Woche kann ich Logs liefern.

Ich bräuchte also nur eine kurze Übersicht über die Verwendung der Devices...

Lars.

wenn interessierte Entwickler noch CI´s brauchen und natürlich die PCIe Module dazugeben

Guten Morgen

Viele Grüsse
Bernhard