TT S2-3200 und DiabloCam

[CiNcH]

Ich spiele hier in letzter Zeit etwas mit dem DiabloCam und es geht in diesem Thread eigentlich weniger um das Entschlüsseln von Programmen (schon gar nicht mit Emulator, bei meinen Experimenten mit dem DiabloCam geht es mir darum, einen universelle Lösung für diverse CA-Systeme und deren nicht existenten CAM-Lösungen zu finden, auch in Hinblick auf diverse NDS-Umstellungen), sondern um das TS-Handling allgemein, wenn das Modul oder andere kritischen Module gesteckt sind.

 

Problem:

In etwa 50% der Kanalumschaltungen bleiben Bild und Ton aus. Es spielt dabei keine Rolle, ob der geschaltete Kanal verschlüsselt (und mit Hilfe einer SmartCard entschlüsselt werden soll) oder unverschlüsselt ist. Die empfangenden Programme (sowohl getestet mit TT-Media Center bzw. MS Filter/Demuxer als auch DVBViewer) scheinen mit dem TS dann nichts anfangen zu können.

 

Beobachtungen:

Im Falle des Ausbleibens von Bild und Ton zeigt der DVBSource-Filter wirre Daten an, z.B. einen Videostream mit sehr sprunghaften Datenraten und Timestamps.

 

 

Führt man dann ein 'Rebuild Graph' durch, erscheinen Bild und Ton. Ich frage mich, was 'Rebuild Graph' im Detail macht? Wird hier lediglich der Wiedergabegraph neu gebaut, oder auch der BDA-Graph? Ist es nur der Wiedergabegraph, könnte man davon ausgehen, dass der Treiber die Daten korrekt liefert (bzw. das ab einem gewissen Zeitpunkt macht), der Wiedergabegraph bzw. der DVBSource-Filter im ersten Moment mit den gelieferten Daten aber nichts anfangen kann und sich auch nicht erholt, bzw. erst nach dem Rebuild.

Wenn ich anstatt 'Rebuild Graph' versuche weiterzuschalten, kann es sein, dass Bild und Ton wieder kommen, wobei das meines subjektiven Empfindens nach zu urteilen häufiger der Fall ist, wenn die Frequenz gewechselt wird (wahrscheinlich weil nur dann ein neuer TransportStream angefordert wird).

Außerdem interessant ist die Tatsache, dass wenn der DVBViewer gestartet wird, ich immer Bild und Ton erhalte, auch wenn auf einem verschlüsselten Kanal gestartet wird, wo gewartet werden muss, bis das CAM initialisiert ist und die Daten also bereits über das CI laufen, 10 von 10 Versuchen (ein weiteres Indiz für ein Timingproblem?).

 

Ansätze:

Ich habe versucht mit 'CheckTimeStamps' im DVB Source Filter den 'Rebuild Graph' zu triggern, aber der zeigt nur ununterbrochen 'Graph Too Late' und zählt in der Klammer hoch. Erst ein manuelle Neuaufbau des Graphs schafft Abhilfe.

 

 

Würde mich über eure Gedanken zu möglichen Fehlerquellen sehr freuen.

Edited April 3, 2008 by CiNcH

[Lars_MQ]

Wird hier lediglich der Wiedergabegraph neu gebaut, oder auch der BDA-Graph?

Das hängt davon ab. Wenn das gerät sonst nicht in gebrauch ist wird auch der bda graph geschlossen, ansonsten nur der wiedergabe graph. Das kannst Du recht einfach über die debug.log verfolgen.

Bei einem kompletten schliessen des device kommt:

Release Hardware ...
Destroy Hardware ...

Ansonsten fehlt das destroy.

 

Die empfangenden Programme (sowohl getestet mit TT-Media Center bzw. MS Filter/Demuxer als auch DVBViewer) scheinen mit dem TS dann nichts anfangen zu können.

Ein recht sicheres zeichen, das etwas bei der kommunikation CAM <-> treiber etwas schief läuft.

 

Beim schliessen (oder öffnen?) wird bei TT meines wissens ein CAM reset gemacht. Dort können eigentlich nur noch die treiber entwickler oder CAM entwickler sagen was dort intern schief läuft und was dieses verhalten hervorruft.

[CiNcH]

Erstmal vielen Dank für die Antwort.

 

...

Ansonsten fehlt das destroy.

 

Destroy wird ausgeführt. Wann wird ein Destroy gemacht und wann nicht?

 

Das heißt wohl, dass die Daten tatsächlich nicht anliegen, bzw. erst dann, wenn auch der BDA-Graph neu aufgebaut wird?

 

 

Dank deinem Vorschlag mit dem -debug Parameter ist mir nun aber ein Licht aufgegangen:

Letztes Wochenende, als ich den TT-Treiber 5.0.0.15 getestet habe, war eine deutliche Besserung des Problems festzustellen (ich teste mit dem Diablo nur ab und zu, z.B. mit neuem Treiber). Nach Neuinstallation des Systems war von dieser Besserung aber nichts mehr zu erkennen. Das hat mich seit gestern an den Rand der Verzweiflung getrieben.

Aber nun ging mir ein Lichtlein auf. Der Unterschied war, dass ich vor der Neuinstallation mit der Beta und dem -debug Parameter gearbeitet habe, was ein deutlich verbessertes Schaltverhalten mit sich bringt. Scheint wieder ziemlich timingsensitiv zu sein!? Wie man ja weiß ist das Schreiben in ein File nicht besonders schnell...

Edited April 3, 2008 by CiNcH

[Derrick]

Diabolo kenne ich nur vom namen, aber ich habe auch ein exotisches (schrott)modul. Nennt sich Matrix und funktioniert ganz gut mit meiner canal digitaal karte. Es gibt aber merkwürdige eigenschaften, die mich etwas an die beschriebenen symptome von @CiNcH erinnern. Das modul verändert andere streams ungefragt. So wird z.b. angezeigt, dass c+ auf astra entschlüsselt wird, was natürlich nicht der fall ist. Der stream wird aber verändert und das flag auf clear gesetzt. Auf der anderen seite wird der pcr_pid von den holländern hinterm cam als scrambled angezeigt, was er natürlich nicht ist. Bei gezogenem modul ist alles so wie es sein soll. Liegt sicher nicht am DVBViewer

[Lars_MQ]

Der Unterschied war, dass ich vor der Neuinstallation mit der Beta und dem -debug Parameter gearbeitet habe, was ein deutlich verbessertes Schaltverhalten mit sich bringt.

Wenn dem so ist, dann ist irgendwas im treiber ganz sicher nicht in ordnung, wenn das ganze so empfindlich ist. Wir reden hier von microsekunden bei einem auf 600 Mhz runtergetaktetem Pentium-M. Die schreibzugriffe auf das debug.log sind lowlevel und hochoptimiert.

 

Edit:

Hat sich die zitierte aussage auf alle CAMs bezogen oder nur auf das diabolo CAM? Ich bin mir jetzt nicht sicher, ob ich Dich richtig verstanden habe... Wenn es nur das Diabolo ist, dann mag das im Treiber zu korrigieren sein, ist aber nicht (wie meine obige aussage andeutet) ein wirkliches Treiberproblem.

[CiNcH]

Auch noch interessant ist die Tatsache, dass die Kanäle mit einer TT-budget S-1500 (und demselben Treiber, CI und CAM) stabil geschalten werden.

[Scan_Speedy]

Nur zur Info, legal unterstüzt das Diablo nur Conax.

Alles andere ist auch nur ne Emulation, in dem Fall des anderen Verschlüsselungssystems...

[Derrick]

..deshalb sind solche cams auch nicht geeignet, um CI-treiber zu testen. Reicht ja, wenn was rauskommt

[Lars_MQ]

Selbstverständlich gehe ich davon aus, dass cinch mit einem HardwareCAM nur testet was legal ist.

 

Aber ich fürchte an diesem Punkt sind wir jenseits dessen, was ich im Viewer lösen kann und will. Ich kann nicht jeden TT nutzer mit Strafpausen belegen, nur weil eine spezielle DVB-Karte das für ein spezielles CAM benötigt. Zumal sich das in der nächsten treiberversion wieder ändern könnte...

[Derrick]

Das war nicht der punkt.. ..ich wollte deutlich machen, dass manche module anders reagieren. Ein unverschlüsselter stream muss immer so bleiben und ein verschlüsselter kommt entweder unverändert raus oder in clear, wenn die berechtigung vorhanden ist.

 

..vergessen. bei dem von mir beschriebenen verhalten kann man übrigens auch die inkonsistenzen der PTSs beim source filter sehen.

Edited April 3, 2008 by Derrick

[Lars_MQ]

Meine antwort bezog sich nicht auf Dich Derrick, Du hast Dich dazwischen gedrängt

 

Aber ich weiss, was Du meinst.

Ich habe hier ein Technisat CAM, das muss ich nur in meine fireDTV stecken und aus jedem Kanal (egal ob fta oder verschlüsselt) wird eine Diashow.

Die KNC One weigert sich das teil zu erkennen, die TT mag das teil nur, wenn FTA nicht ans CAM gesendet werden (das entspricht aber nicht den spezifikationen) und meine Twinhan stirbt damit sang und klanglos bis zum nächsten reboot...

[CiNcH]

Selbstverständlich gehe ich davon aus, dass cinch mit einem HardwareCAM nur testet was legal ist.

Ich setze das DiabloCam nicht einmal produktiv ein, obwohl es in manchen Geräten ganz passabel funktioniert. Es handelt sich dabei lediglich um Tests (momentan teste ich nur FTA damit, weil das ja auch stecken bleibt...).

Im Alltäglichen Gebrauch habe ich Mascom Module (AlphaCrypt Classic und CryptoWorks) mit ORF CW-Karte und Premiere S02 Nagra-Karte.

 

Dennoch verurteile ich Systeme für die es keine offiziellen CAM-Lösungen gibt, weil DRM ja keine Nachteile für den ehrlichen User hat... Ich frage mich heute noch wie das Mascom mit der Nagra-Lizenz gemacht hat (also das reine Nagra, nicht mit BetaCrypt-Protokoll).

Edited April 3, 2008 by CiNcH

[CiNcH]

wenn FTA nicht ans CAM gesendet werden (das entspricht aber nicht den spezifikationen)

Wie ist das nun gemeint bzw. realisiert? Ich hab das immer noch nicht verstanden...

Edited April 3, 2008 by CiNcH

[Derrick]

Wie ist das nun gemeint bzw. realisiert?

Das ist der punkt aus dem anderen thread: "Nur verschlüsselte Sender an das CAM senden" d.h., dass für FTA keine CA_PMT gesendet wird, obwohl das im standard vorgeschieben ist.

[Lars_MQ]

Also wenn ein CAM im system ist, soll eigentlich JEDER tuning vorgang an das CAM weitergemeldet werden, auch wenn es nur FTA Kanäle sind, die eigentlich nichts mit dem CAM zu kriegen haben. Wenn man die entsprechende Option in den Hardware optionen anklickt werden nur noch tuningvorgänge von verschlüsselten kanälen an das CAM weitergereicht.

 

"an das CAM weitergereicht" bedeutet, die entsprechende Funktion des DVB-Karten treibers mit den entsprechenden Parametern (PMT, SID oder caPMT) aufrufen.

 

Ich bin am überlegen diese Option verschwinden zu lassen. Das war nur so ein (recht zweifelhafter) workaround, der die User verführt ihn zu wählen, weil dort CAM und verschlüsselt drinne steht, aber im zweifel alles nur schlimmer macht...

[CiNcH]

2 Fragen noch zu meinem Problem:

 

Macht der DVBViewer bei 'Rebuild Graph' prinzipiell immer ein Hardware Destroy?

 

Bei diesem Hardware Destroy wird, wie ich sehe, das TT-API bzw. das CI nicht neu initialisiert, oder? Jedenfalls laut Log nicht. Ich denke nicht, dass im Problemfall das DiabloCam abstürzt, denn sonst würden nach paarmaligem Umschalten (vor allem auf anderen Transponder) Bild und Ton nicht irgendwann wieder kommen (auch ohne 'Rebuild Graph')...

[Lars_MQ]

Macht der DVBViewer bei 'Rebuild Graph' prinzipiell immer ein Hardware Destroy?

Das hängt davon ab. Wenn das gerät sonst nicht in gebrauch ist wird auch der bda graph geschlossen, ansonsten nur der wiedergabe graph

 

Bei diesem Hardware Destroy wird, wie ich sehe, das TT-API bzw. das CI nicht neu initialisiert, oder?

Das device wird bei einem destroy komplett geschlossen. Alles abgeräumt. Alles wech.

[CiNcH]

Das hängt davon ab. Wenn das gerät sonst nicht in gebrauch ist wird auch der bda graph geschlossen, ansonsten nur der wiedergabe graph

 

Ahja, aber das Gerät ist doch eigentlich in Gebrauch? Trotzdem der Destroy? (bzw. definiere bitte mal 'in Gebrauch')

 

Das device wird bei einem destroy komplett geschlossen. Alles abgeräumt. Alles wech.

 

Aha, soweit ich mich erinnern kann (kann es im Moment leider nicht nachschauen), stand im debug.log aber nichts von neu öffnen und initialisieren des CI's. Oder wird das evtl. nur nicht geschrieben?

Edited April 4, 2008 by CiNcH

[Lars_MQ]

Ahja, aber das Gerät ist doch eigentlich in Gebrauch? Trotzdem der Destroy? (bzw. definiere bitte mal 'in Gebrauch')

= Aufnahme. Wir können natürlich einer aufnahme das gerät nicht unterm ar** wegziehen.

Das ganze ist doch ganz einfach. Jeder Programteil, der eine DVBHardware benötigt, fordert sie an. Und wenn er sie nicht mehr braucht, gibt er sie zurück. Wenn kein anderer programteil das ding mehr nutzt wird es freigegeben (destroy).

 

Aha, soweit ich mich erinnern kann (kann es im Moment leider nicht nachschauen), stand im debug.log aber nichts von neu öffnen und initialisieren des CI's.

Dann erinnerst Du dich falsch.

04.04.08 09:14:20 Release Hardware TechnoTrend BDA/DVB-S Tuner (2)
04.04.08 09:14:20 Destroy Hardware TechnoTrend BDA/DVB-S Tuner (2)
04.04.08 09:14:20 Settuner		 Start
04.04.08 09:14:20 Found TT Device  DeviceType: 1
04.04.08 09:14:20 Open BDA Device  Got handle for TT Device
04.04.08 09:14:20 TBDACITTModule:Create CloseCI: Das System kann das angegebene Laufwerk nicht finden
04.04.08 09:14:20 TBDACITTModule:Create OpenCI: Der Vorgang wurde erfolgreich beendet
04.04.08 09:14:20 Allocate Hardware TechnoTrend BDA/DVB-S Tuner (2)

 

Es müssen immer im pärchen auftreten: Open - Destroy und Allocate - Release. und open - destroy muss alle entsprechenden allocate - release umklammern. Ansonsten läuft was richtig falsch.

[CiNcH]

Ok, dann ist es nicht verwunderlich, dass die TS-Daten nach Rebuild Graph anliegen. Da ist das CI wahrscheinlich nicht so schnell initialisiert und die Daten laufen noch nicht darüber.

Die CI-Reinitialisierung scheint aber ganz schnell von statten zu gehen. Startet man den DVBViewer, sieht man nach wenigen Sekunden immer den kurzen Glitch, wenn das CI initialisiert wurde und die Daten ab dann durch das CAM laufen (4 Discontinuities ca.). Muss ich nochmal schauen wie das Verhalten bei Rebuild Graph ist. Auch im MMI hab ich da keinen Unterbruch feststellen können, das scheint also zustandslos zu sein.

[CiNcH]

Ok, du hast natürlich Recht. Ich hatte die Applikation nur zu schnell nach dem Rebuild geschlossen, hab dem CI also keine Chance mehr gegeben sich zu initialisieren.

 

Die CheckTimeStamps-Option macht dann in dem Fall nur einen Neuaufbau des Wiedergabegraphs, was hier eben nicht ausreicht, weil der Treiber eben wirklich keine Daten liefert.

 

Ein Absturz des CAM's ist auch auszuschließen. Nach dem Schalten auf einen anderen Transponder kommen Bild und Ton auch wieder (ohne Hardware neu zu initialisieren, ab und zu sind auch mehrere Schaltvorgänge notwendig). Schaltetvorgänge innerhalb eines Transponders helfen dann natürlich nicht, weil da kein neuer TransportStream angefragt wird sondern lediglich im aktuellen TransportStream geschaltet wird.

 

Hab nun genug Infos zusammen. Danke für die Hilfe.

[CiNcH]

Ach Kacke... doch noch eine Frage...

 

Laufen die TS-Daten erst dann über das CI, sobald es initialisiert ist (drum der Glitch von ca. 4 Discontinuities) oder sobald das Modul gesteckt ist? Denke mal dafür muss es schon zuerst initialisiert sein? Muss man da im Treiber zuerst über die Funktion 'bdaapiSetVideoport' den Datenstrom umbiegen? FTA-Kanäle werde ja auch angezeigt, wenn ein Modul zwar gesteckt ist, es aber nicht initialisiert ist...

[Lars_MQ]

keine ahnung, das ist komplett transparent für die app. Das CI wird immer initialisiert, sonst würden die Meldungen zu cam gesteckt oder karte gesteckt niemals ankommen. Irgendwann kommt die meldung CAM bereit, Karte vorhanden und dann werden die daten abgeschickt.

[CiNcH]

Die Funktion 'bdaapiSetVideoport' wird also vom DVBViewer nie aufgerufen?

[Lars_MQ]

Nein. Aber Du könntest mir mal genauer erklären, was der videoport sein soll, die Doku schweigt sich wie bei vielem vornehm dazu aus.

Aber das wird sicherlich nicht für den normalen betrieb gebraucht.

[Derrick]

Laufen die TS-Daten erst dann über das CI, sobald es initialisiert ist (drum der Glitch von ca. 4 Discontinuities) oder sobald das Modul gesteckt ist?

..ziemlich sicher sobald das modul gesteckt ist.

[CiNcH]

Nein. Aber Du könntest mir mal genauer erklären, was der videoport sein soll, die Doku schweigt sich wie bei vielem vornehm dazu aus.

 

Doku? Ach du meinst die Auflistung der Prototypen...

Ich dachte, das wären Ports am SAA, dass bdaapiSetVideoport true den Port wählt, wo das CI dran hängt und false den TS direkt auf den PCI legt. Dem scheint aber wohl dann nicht so zu sein!? Aber vielleicht setzt der Treiber den Port automatisch, wenn ein CI gesteckt ist und man kann es dann manuell ändern?

 

..ziemlich sicher sobald das modul gesteckt ist.

 

Beim CI-Init tritt ja der kurze "Glitch" auf. Dachte, er würde da dann eben umschalten und erst dann die Daten übers CI routen. Ich glaube immer noch, dass der Treiber dann den Videoport auf CI setzt .

Edited April 4, 2008 by CiNcH

[Derrick]

Probier doch mal einen transponder mit freien und verschlüsselten kanälen, für die deine karte gilt. Dann nimmst du den ts von einem unverschlüsselten kanal auf und schaltest auf einen verschlüsselten. Da kannst du dann das modul initialiseren oder sonstwas machen, nur nicht rausziehen . Gleichzeitig oder hinterher kannst die aufnahme mit dem tsplayer abspielen und beim source filter gucken, ob es glitches gibt.

[Lars_MQ]

Doku? Ach du meinst die Auflistung der Prototypen...

Somit weisst Du über die ganze TT/CI genausoviel wie ich. Das ist meine Arbeitsgrundlage.

[CiNcH]

Hier mein Problembericht an TT:

 

TT-budget S-3200 und DiabloCam Light

 

Danke nochmal für eure Hilfe und Gedanken.

[CiNcH]

Hier mal ein Blockdiagramm des SAA-Referenzdesigns:

 

 

IMHO ist der linke Anschluss am SAA der FTA- und der rechte Anschluss der CI-Port. Diese lassen sich über die Funktion 'bdaapiSetVideoport' switchen. D.h. man könnte eventuell FTA dem CI bzw. CAM vorenthalten.

 

TTBDADRVAPI TYPE_RET_VAL bdaapiSetVideoport(HANDLE hOpen, BOOL bCIMode, BOOL* bCIOut)

 

Switch the videoport between CI- and FTA-mode in drivers that support common interface.

Parameters:
hOpen		  Is the handle returned by one of the open functions.
bCIMode		Is the desired CI-mode.
				TRUE set to CI
				FALSE set to FTA
*bCIOut		Is a the mode that the driver has set.
				TRUE is set to CI
				FALSE is set to FTA

Returns:
Value of type TYPE_RET_VAL

 

Der Treiber scheint den Modus bzw. Port zu setzen, kann aber geändert werden!?

Edited April 4, 2008 by CiNcH

[Derrick]

D.h. man könnte eventuell FTA dem CI bzw. CAM vorenthalten.

Es ist alles oder nichts. Entweder alles übers CI oder alles direkt zur bridge. Mischen lässt sich das nicht, weil immer der gesamte mux geroutet wird. Schaltet man hin und her, wären die unverschlüsselten kanäle auch jedes mal durch kurze unterbrechungen betroffen (eine testmöglichkeit habe ich weiter oben beschrieben).

[CiNcH]

Also ich bin mir nun ziemlich sicher, dass die Daten erst dann über das CI laufen, wenn es initialisiert ist. Hab nun nämlich das etwas längere CI-Kabel (40cm) dran und da drüber gehen einige Daten verloren. Und das passiert nicht, wenn das Modul gesteckt ist, sondern wenn es initialisiert ist (und der Treiber wahrscheinlich den Videoport umgebogen hat).

[Derrick]

..und warum probierst nicht einfach mal, was ich vorgeschlagen habe? Wenn die im hintergrund laufende fta_aufnahme beim initialisieren nicht unterbrochen wird, wird der mux auch nicht umgeschaltet.

[CiNcH]

Ich versteh den Sinn dahinter nicht. Ich weiß schon, dass der komplette TS immer entweder über das CI oder eben nicht läuft und dass der TS nicht erst über das CI läuft, wenn man einen verschlüsselten Kanal schaltet.

 

Ich sag nur, dass solange kein CAM initialisiert ist, der TS nicht darüber läuft. Erst wenn das CAM initialisiert ist, scheint der Treiber die Daten umzulenken.

[Derrick]

Wenn du den sinn nicht verstehst, verstehst du anscheinend auch nicht die funktionsweise eines CI_CAMs Der mux, der reingeht, kommt mit einer gewissen verzögerung wieder raus. Umschalten direkt/modul ist nicht störungsfrei. Auch nicht für die freien programme.

 

5.5. Operational Example

To illustrate some of the features described above consider this example of the processes that occur when a PC Card

module is plugged into a host. The PC Card initialisation commences with sensing of the module being plugged in by

sense pins on the interface. The host then reads the Card information Structure residing in the Attribute Memory of

the module. This contains low-level configuration information for the module, such as PC Card read and write

addresses used by the module, and indicates to the host that it is a DVB-conformant module. The host now turns off

the Transport Stream Interface bypass link and allows the transport packets to flow through the module. This introduces

a delay, and consequently a short gap in the Transport Stream data, but this is unavoidable. At the same time

the physical layer interface initialisation process takes place to negotiate the buffer size to be used for communication.

At this point the physical layer initialisation process is complete and the upper-layer initialisation process, common to

all physical implementations, commences with the host creating a Transport Layer connection to the module. This

process and the rest of the upper-layer initialisation process are described elsewhere in this document.

[CiNcH]

Ähm ja, da steht ja genau, dass nach der Initialisierung erst der TS über das Modul geroutet wird und dieser Schaltvorgang eben mit einem Delay verbunden ist. Und das sind dann doch die Diskontinuitäten, die unmittelbar nach der Initialisierung zu beobachten sind.

Edited April 5, 2008 by CiNcH

[CiNcH]

Ja, habe nie behauptet, dass der Port-Switch störungsfrei sei. Und mir ist auch klar, dass wenn man auf einem Transponder mit verschlüsselten und unverschlüsselten Komponenten (und halt auch den Port) dann parallel Sachen machen will, man dann beim Port-Switch einen kleinen Unterbruch hat... Irgendwie reden wir aneinander vorbei .

 

Aha, man versteht die Funktionsweise von CI/CAM also nur, wenn man die Specs bis ins kleinste Detail auswendig kennt . Hab da nie reingeschaut, bzw. nur einmal, weil ich die Pinbelegung der Module gebraucht habe (Mod für direkte Stromzufuhr vom Netzteil).

Edited April 5, 2008 by CiNcH

[Derrick]

Der text ist beispielhaft und beschreibt den vorgang beim stecken des moduls. Keine frage, dass es dabei zu einer kurzen unterbrechung kommt, die den gesamten mux betrifft. Die frage ist aber, ob das auch der fall ist beim (re)initilisieren eines bereits gesteckten moduls. Nochmal, wenn die fta_hintergrundaufnahme dabei ungestört weiterläuft, ändert sich nichts am weg, den der mux nimmt.

[CiNcH]

Update:

 

TT konnte das Problem mit dem Diablo und der S2-3200 wohl nachvollziehen, die Ursache dafür aber nicht finden. Es wurde mit der dem TT-API beiliegenden BDA-API-Demo gecheckt, ob TS Pakete verloren gehen. Das war nicht der Fall (der DVBViewer zeigt ja auch keine Diskontinuitäten an). Trotzdem läuft hier was schief.

 

Ob die BDA-API-Demo das richtige Werkzeug ist, weiß ich nicht. Ich habe mir mal den Code angeschaut und es wird nirgends das CI geöffnet bzw. initialisiert. Die Demo lässt aber das Switchen des Videoports zu (FTA <-> CI). Aber ob die Daten dann wirklich über das CAM laufen (bei Videoport CI), wenn es nicht initialisiert ist, kann ich im Moment nicht beurteilen.

Edited April 10, 2008 by CiNcH