DigitalRise / Twinhan und die lieben CAM Module

[maju]

Hallo,

 

Mehrfach wurde ja schon angedeutet, dass der DVBViewer keinen Einfluss auf den Umstand hat, ob ein Sender verschlüsselt ist oder nicht. Das soll ja alles vom Treiber bzw. vom SDK gemanagt werden.

 

Ich habe auf meinem System stets sowohl DVBViewer als auch die Originalsoftware "TwinhanDTV" installiert. Wenn man TwinhanDTV nach dem DVBViewer installiert, kann man auch beide Anwendungen problemlos nutzen. (Wenn man TwinhanDTV vor dem DVBViewer installiert, geht das nicht da der von DVBViewer registrierte thsource.ax nicht von TwinhanDTV angesprochen werden kann! Umgekehrt geht's aber problemlos!)

 

Ich hab' jetzt aber häufig den Fall, dass eine bestimmte Modul/Smartcard-Kombination zwar in der originalen TwinhanDTV läuft, aber nicht im DVBViewer. Woran kann das liegen? Wenn die ganze Entschlüsselung ausschließlich von der Hardware gemanagt wird und nicht von der Software, warum laufen dann manche Kombinationen in TwinhanDTV aber nicht im DVBViewer?

 

Aktuell geht es um eine originale ORF Karte mit einem chinesischen CryptoWorks Modul. In TwinhanDTV funzt diese Kombi problemlos, im DVBViewer leider nicht. Die gleiche ORF Karte aber in einem SCM Modul funzt hingegen sowohl in TwinhanDTV als auch im DVBViewer !?!

 

BTW: Ich verwende TwinhanDTV 2.64 ...

 

Martin

[Engelbert]

Danke für den Hinweis zur Installations-Reihenfolge. Muß man erstmal drauf kommen.

Bei meiner TH (02.2006) gings noch umgekehrt, auch noch mit der direkten WDM-Treiber-Nutzung.

 

Das Problem mit den CAMs würde ich vorerst den 'Flegeljahren' der PRO zurechnen; aber schon kommt ein weiteres Problem auf, indem Provider beginnen, ihre SmartCard nur mit dem eigenen Receiver zu verheiraten, was jede Nutzung der Karte im PC verhindert.

[maju]

Update: Wir haben's jetzt mal mit der neuen TwinhanDTV 3.0 Version getestet und siehe da: keine Unterschiede mehr zwischen DTV und DVBViewer! Zufall?

 

BTW: Für Kabelkarten mit Mantis Chipsatz ist die 3.0 ein Quantensprung. Hier scheinen die meisten Probleme nun verschwunden zu sein (CAM Erkennung, etc)

 

Martin

[maju]

... wollte mal anmerken, dass sich dieses Verhalten auch mit der neuesten Beta nicht geändert hat.

Nach wie vor werden zwar die meisten Module mit der mitgelieferten Software angezeigt, aber nicht mit DVBViewer Pro.

 

Martin

support.zip

[Engelbert]

CI etc. macht einfach (noch) Probleme, zumal die Nicht-Premiere-SAT-Fans sich darum bisher nur wenig gekümmert haben - es bestand halt kein Bedarf.

 

Vielleicht noch ein wenig Ungereimtes.

Mein AC Light ließ sich bisher mit dem alten WDM-Treiber meiner TH-Cab-CI (2031) immerhin einstellen, nach dem aktuellen ACL-Update bei Mascom nicht mehr.

Die aktuelle PRO-Beta V 3.5.0.100 (101!) zeigt noch das Menue, das wars dann.

 

Immerhin werden die verschlüsselten Sender freigeschaltet, wenn kein FSK18 (Jugendschutz) Merkmal den Bildschirm schwarz beläßt.

 

Manche halten das für HiTec.

Edited November 16, 2006 by Engelbert

[maju]

Bei ähnlichen Fragen wird immer darauf verwiesen, dass die CAM Unterstützung immer Hardware / Treibersache ist und aus Sicht der TV Anwendung herzlich wenig unternommen werden kann.

Wenn dem wirklich so wäre, dann müssten ja sowohl TwinhanDTV als auch DVBViewer Pro genau die selben CAM's erkennen und die selben Abokarten freischalten.

 

Ich habe aber CAM's hier, die mit TwinhanDTV und einer originalen ORF Karte die ORF Kanäle einwandfrei freischalten. Bei DVBViewer hingegen wird aber weder ein CAM Menü angezeigt noch die ORF Kanäle freigeschaltet. Der Menüpunkt für das CAM Menü ist aber verfügbar. Somit erkennt DVBViewer jedenfalls, dass ein CAM vorhanden ist ...

 

Martin

[hackbart]

Ich hatte vor langer Zeit mal deswegen bei Twinhan angefragt, aber immer nur die Bitte bekommen doch den BDA Treiber zu nutzen. Mit Alphacrypt und Viaccess bzw. meinem Conax Modul läuft das ganz gut, nur so zufriedenstellend ist es auch nicht wirklich

Die ganze Implementierung beschränkt sich übrigens auf eine Hand voll SDK Funktionen:

 

Das Dekodieren eines Senders wird über die SetPID Funktion realisiert und das CI wird über folgendes Interface angesteuert:

 

IDVBCIMenu = interface(IUnknown)

['{39d4fb19-934d-4884-bc31-4a2d0db874da}']

function GetCAMState(out pwCAM_Exist_Flag: Integer; out pwMMI_Info_Flag: Integer): HRESULT; stdcall;

function GetAppInfo(var AppInfo: TAppInfo): HRESULT; stdcall;

function InitMMI: HRESULT; stdcall;

function GetMMI(var MMIInfo: TMMIInfo; var pwType: integer): HRESULT; stdcall;

function Answer(var MMIInfo: TMMIInfo; wType: integer): HRESULT; stdcall;

function CloseMMI: HRESULT; stdcall;

end;

 

Mehr erlaubt das alte SDK nicht. Bei dem BDA Treiber ist das ganze ein bisschen komplexer und funktioniert mit meiner Karte wesentlich besser, da man alle in einer PMT liegenden Pids dekodieren kann (sprich mehrere Audiokanäle). Nichtsdestotrotz ist das MMI Interface am PC nicht wirklich toll.

 

Christian

[Engelbert]

Mit Verlaub halte ich die BDA-Treiber-Möglichkeiten für CI etc. bei meiner TH-Cab-CI für 'Murks'!

 

Allerdings habe ich keinen Anlaß, anzunehmen daß Christian nicht alles unternommen hat, was ihm möglich ist.

Sicher tut Griga gut daran, sich mit der CI-Implementierung noch zurückzuhalten.

 

Schließlich ist das Ganze ja wohl Microsofts Unfähigkeit zu 'danken', die einen weltweiten Standard eingeführt haben, der auf Krücken daherhumpelt.

 

Inzwischen habe ich auch mein Alphacryt Classic upgedatet zurück. Das zeigt zwar einige Positionen mehr an als das AC Light, aber einstellen läßt sich auch da eigentlich nichts.

[Derrick]

Schließlich ist das Ganze ja wohl Microsofts Unfähigkeit zu 'danken', die einen weltweiten Standard eingeführt haben, der auf Krücken daherhumpelt.

Inhaltlich stimme ich dem zu, aber eines ist so nicht ganz richtig. M$ mag zwar der grösste sein (ich bin gar kein gegner ) aber zum standard gehört mehr. BDA ist total proprietär. Es wird natürlich durch die verbreitung zum quasi-standard. Trotzdem kann man von standard laut definition nicht sprechen. Mich erinnert das irgendwie an avi aber dann auf dem stand von dos oder höchstens fat16

 

Nichtsdestotrotz draf sich nicht jede unzulänglichkeit beim CI hinter BDA verstecken. Die meinungen sind geteilt, wer für was verantwortlich ist. Und transparent ist es für interessierte user auch nicht. Absicht ?!

[maju]

Mehr erlaubt das alte SDK nicht. Bei dem BDA Treiber ist das ganze ein bisschen komplexer und funktioniert mit meiner Karte wesentlich besser, da man alle in einer PMT liegenden Pids dekodieren kann (sprich mehrere Audiokanäle). Nichtsdestotrotz ist das MMI Interface am PC nicht wirklich toll.

 

Das "alte" SDK? Du meinst das SDK zu den WDM Treibern?

Das wird ja bei BDA Treibern nicht mehr funktionieren ...

 

Bei BDA ist die ganze CI Behandlung "Handarbeit", oder?

Ich denke das ist auch der Grund wieso Twinhan die "MCE CI Console" programmiert hat.

Damit lassen sich dann PayTV Sender auch unter Anwendung wie MCE nutzen die kein eigenes CAM Handling haben ...... zur Info: Mit dieser Console kann ich genau die gleichen Module ansprechen wie mit der Originalsoftware. Und funktionieren tut sie ganz gut. Nur nicht für DVBViewer! Aber warum? Sieht danach aus als ob da doch ein eigenes CI Handling existiert das sich erheblich vom "Twinhan Handling" unterscheidet ...

 

Würde es Dir was nützen den Sourcecode zur MCE CI Console zu haben?

 

Martin

Edited November 17, 2006 by maju

[Engelbert]

Diese MCECIconsole.exe funktioniert bei mir kaum besser als mit der PRO.

 

Scheint mir bei SAT (Mantis) aktueller zu sein als bei Cab-Conexant (BDA),

mit WDM und aktuellen AC/ACLs geht nichts mehr.

[maju]

.... Bei dem BDA Treiber ist das ganze ein bisschen komplexer und funktioniert mit meiner Karte wesentlich besser, da man alle in einer PMT liegenden Pids dekodieren kann (sprich mehrere Audiokanäle). Nichtsdestotrotz ist das MMI Interface am PC nicht wirklich toll.

 

Also der Entwickler des nicht funktionierenden CAM Modules hat mir ein Dev Board geschickt um Logs der Kommunikation zwischen Hardware und CAM zu erstellen. Er hat die Logs analysiert und den Fehler gefunden was anscheinend DVBViewer "falsch" macht. Ich versuche das mal halbwegs als Laie zu übersetzen:

 

Aufgabe der Applikation ist es, einen sogenannten PMT Wert an das CAM zu schicken. Das ist ein Bit-codiertes Wert der verschiedene Dinge enthält. Einer dieser Werte enthält den "Stream Type". Dieser sollte für Audio 1-2 sein, für Video 3-4 und für Data 6. DVBViewer sendet aber ein 0 für den Stream Type. Dies ist aber eigentlich ein "reserved type". Andere CAM's ignorieren diesen Wert oder interpretieren diesen anders.

 

Dieses CAM analysiert diesen Wert aber und macht nicht weiter, wenn der Typ nicht stimmt. Somit gibt's bei DVBViewer kein Bild obwohl das CAM erkannt wird. Die Originalsoftware scheint den Typ richtig an das CAM zu senden weshalb es dort ein Bild gibt.

 

Christian, eventuell hilft Dir diese Information um die CAM Unterstützung in DVBViewer zu verbessern.

 

Martin

[Derrick]

Danke, das ist eine sehr interessante information. Ob es die eigentliche ursache ist, ist dabei gar nicht so wichtig. Es offenbart aber mal wieder, dass die CA_PMT doch nicht so ist, wie immer behauptet wird. So ein tool oder debug_log würde ich mir auch wünschen

[Guest Lars_MQ]

capmt[length] := 00; inc(length); //###### stream_type (apparently doesn't matter)

Scheint nicht so richtig zu sein Ich schau mal, also 1 für Audio, 3 für Video und 6 für data? weil 1-2 kann ich schlecht einstellen...

[maju]

Danke, das ist eine sehr interessante information. Ob es die eigentliche ursache ist, ist dabei gar nicht so wichtig. Es offenbart aber mal wieder, dass die CA_PMT doch nicht so ist, wie immer behauptet wird. So ein tool oder debug_log würde ich mir auch wünschen

 

Der Programmierer des CAM Moduls hat mir jetzt noch einen Gefallen getan um seine Vermutung zu untermauern. Er hat mir eine Firmware geschickt, die den Stream Type wie manche andere Module NICHT überprüft ... und siehe da, dass Modul läuft jetzt einwandfrei in DVBViewer!!!

 

Er hat mir dazu auch erklärt, dass viele Module auf diese Überprüfung verzichten, da es nicht zum "Critical Part" beim Descrambling gehört und deshalb manche Firmware diese Werte gar nicht überprüfen und hier konstante Werte verwenden ... aber richtig ist das aus seiner Sicht nicht (der Knabe ist ein kleiner Monk, muss man dazu sagen Bei dem muss immer alles zu 100% korrekt sein)!

 

Fazit: Da DVBViewer den Stream Type nicht richtig setzt, läuft der DVBViewer Pro momentan nur mit Modulen, die den "Stream Type" im PMT nicht überprüfen! Ich weiss aber nicht, ob dies nur für Twinhan Produkte gilt oder ein allgemeiner Bug ist ...

 

Martin

 

capmt[length] := 00; inc(length); //###### stream_type (apparently doesn't matter)

Scheint nicht so richtig zu sein Ich schau mal, also 1 für Audio, 3 für Video und 6 für data? weil 1-2 kann ich schlecht einstellen...

 

Ich denke er meint damit 1 oder 2 ... ich werd' ihn aber dezidiert danach fragen.

Wie ich gehört habe gibt's ja Unterschiede zwischen SD und HD Streams bei den CAM's.

Eventuell werden die unterschiedlichen Werte dafür benötigt ... und bei Audio zur Unterscheidung zwischen AC3 und MPEG ... ?

 

Martin

[Guest Lars_MQ]

maju checke mal deine PM dann wissen wir vielleicht mehr.

[maju]

maju checke mal deine PM dann wissen wir vielleicht mehr.

 

Hab' ich gerade gemacht und siehe da, das CAM läuft jetzt einwandfrei mit deiner Testapplikation!

... auch mit jenen CAM Versionen, die den Stream Type abfragen!

 

Somit liegt die Ursache definitiv darin, dass DVBViewer bisher dem CAM als Stream Type stets "0" übermittelt hat!

 

Martin

[Guest Lars_MQ]

Gut der code wandert dann zu christian.

 

Wäre trotzdem nett, wenn Du den entwickler mal fragst, was es mit dem 1-2 und 3-4 auf sich hat. Eventuell müssen wir dort noch nachbessern dann.

[maju]

Er ist jetzt schlafen gegangen ...

 

... aber er hat gesagt die Werte sind in den MPEG-2 Spezifikationen definiert. Er hat mir per MSN noch das Dokument genannt: 13389 oder 13839 oder so ähnlich.

Er wird mir das Dokument morgen per Mail schicken.

 

Aber wie im obigen Mail bereits angemerkt, sollte die Applikation den Stream Type aus dem TS ermitteln und den Wert 1:1 an's CAM weiterleiten. Es soll laut ihm nicht nötig sein, hier eigene Werte zu setzen.

 

Martin

[Guest Lars_MQ]

Alles klar, jetzt weiss ich was gemeint ist. Der Streamtype. 3=mp1, 4=mp2 (gibts für jeden ne dolle iso bezeichnung die kein schwein behält ) usw.

Ja das sollte eigentlich aus der PMT ausgelesen werden und wird es sicherlich auch, aber nunja das wird nicht unterschieden, sondern einfach auf audio oder video pid gemappt. Dort möchte ich auf keinen fall eingreifen, das ist legacy code...

 

Ich stufe das als nicht kritisch ein, da das teil scheinbar nicht wirklich genau prüft, sondern glücklich ist, wenn überhaupt ein annähernd passender wert dort ist.

 

Ich habe nämlich zielsicher beide Werte falsch angegeben (1 + 3) es müsste aber 2 und 4 sein

[Derrick]

Mir sind eigentlich 2 dinge unverständlich:

 

1. es sollte dem modul egal sein, welcher stream type zu entschlüsseln ist. Jedenfalls solange ein transport_stream_scrambling angewendet wird. Vielleicht gibt es ja einschränkungen, wenn ein PES_scrambling verwendet wird. Das gibt es laut standard aber gesehen wurde es noch nie..

 

2. dass der stream type nicht einfach aus der PMT genommen wird, da die doch geparst werden muss.

 

..als analogie passt es in die diskussion, ob recording als PS oder TS besser ist. Da fällt die antwort dann einfach aus. Beim TS kann zumindest kaum was falsch gemacht werden und können keine "legacy"_header eingebaut werden

[maju]

Ich stufe das als nicht kritisch ein, da das teil scheinbar nicht wirklich genau prüft, sondern glücklich ist, wenn überhaupt ein annähernd passender wert dort ist.

 

... und das ist wahrscheinlich das, was er als "not critical part" bezeichnet und viele CAM's deshalb ganz und gar auf die Überprüfung verzichten. Aber nett wäre es schon, wenn DVBViewer in Zukunft diesen Wert an das CAM weiterleitet um auch jene CAM's glücklich zu stimmen, die wider jeder Praxis doch einen Blick auf diesen Wert werfen ... und wenn die Variable einen nicht spezifizierten Wert enthält kein Descrambling machen.

 

Also seit gnädig liebe Programmiergötter und erzieht DVBViewer dahingehend, dass auch solche ganz genauen "Monk CAM's" mit DVBViewer laufen!

 

Martin

[Guest Lars_MQ]

@: maju

Die werte sind schon eingebaut, also in der nächsten beta. Dort allerdings die 2 und die 4 weil sie die realitäten in den allermeisten fällen wiederspiegeln.

 

Wenn Du willst, lass ich Dir eine entsprechende testversion mit den geänderten werten nochmal zukommen, damit du verifizieren kannst, dass die auch laufen.

[Benarty]

@: maju

Die werte sind schon eingebaut, also in der nächsten beta. Dort allerdings die 2 und die 4 weil sie die realitäten in den allermeisten fällen wiederspiegeln.

 

Wenn Du willst, lass ich Dir eine entsprechende testversion mit den geänderten werten nochmal zukommen, damit du verifizieren kannst, dass die auch laufen.

 

Der gebraucher soll einfach diese werte ein un ausschalten im ein minupunkt.

[Derrick]

Die werte sind schon eingebaut, also in der nächsten beta. Dort allerdings die 2 und die 4 weil sie die realitäten in den allermeisten fällen wiederspiegeln.

Was hindert den DVBViewer daran, einfach den standard anzuwenden anstatt irgendwelche eigenkonstruktionen einzubauen ?

[maju]

Die werte sind schon eingebaut, also in der nächsten beta. Dort allerdings die 2 und die 4 weil sie die realitäten in den allermeisten fällen wiederspiegeln.

 

Wenn Du willst, lass ich Dir eine entsprechende testversion mit den geänderten werten nochmal zukommen, damit du verifizieren kannst, dass die auch laufen.

 

Bitte gerne! Ich teste gerne nochmals eine Vorabversion.

 

... aber fix eingebaute Werte sind ja auch nicht ganz richtig! Wie der CAM Entwickler mir sagte - und ich weiter oben ausführte - sollte eine Applikation als "Stream Type" KEINE eigenen konstanten Werte setzen. Der Stream Type befindet sich im TS und sollte von der Applikation ausgelesen und an das CAM einfach weitergeleitet werden.

 

Ist das nicht möglich?

 

Martin

[Derrick]

... aber fix eingebaute Werte sind ja auch nicht ganz richtig! Wie der CAM Entwickler mir sagte - und ich weiter oben ausführte - sollte eine Applikation als "Stream Type" KEINE eigenen konstanten Werte setzen. Der Stream Type befindet sich im TS und sollte von der Applikation ausgelesen und an das CAM einfach weitergeleitet werden.

..das ist genau das, was ich schon etwas weiter oben beschrieben hatte

[Guest Lars_MQ]

Ist das nicht möglich?

Nicht ohne grössere (fehlerträchtige) Umbaumassnahmen, die alle anderen karten und das gesamte Program mit beeinflussen könnten, wenn was nicht hinhaut.

 

Zumal das "monk'sche" CAM Module ebenso inkonsequent ist.

[Derrick]

Das bedeutet aber, dass der CI-standard im DVBViewer nicht korrekt implentiert ist. Warum am stream type gespart wird, wenn die pmt doch tiefer für alle ES und ca_descriptors geparst werden muss, bleibt mir schleierhaft. Wenn ein modul auf dem standard besteht, liegt ja nicht dort der fehler

[maju]

Zumal das "monk'sche" CAM Module ebenso inkonsequent ist.

 

Das CAM Modul ist nicht inkonsequent. Im Gegenteil, dass Modul überprüft Werte sehr konsequent. Sogar so konsequent das Werte überprüft werden, die für das Descrambling gar nicht direkt benötigt werden. Somit ist das CAM Modul derart konsequent, dass es nicht nur als CAM verwendet werden kann, sondern sogar als "TS Checker"!

 

... und mit diesem TS Checker wurde herausgefunden, dass DVBViewer sich nicht 100%ig an die ISO 13818-1 hält. D.h. DVBViewer sendet den konstanten Wert "0" als Stream Type der eigentlich als "reserved" gilt.

 

Aus diesem Grund sollte man früher oder später darüber nachdenken, diese kleine "Unschönheit" nicht nur durch einen Workaround zu beheben, sondern durch eine Lösung die der ISO 13818-1 entspricht.

 

Martin

Edited November 23, 2006 by maju

[Guest Lars_MQ]

Jau wird der Viewer sicherlich irgendwann mal machen. Ich glaube, das wird der fall sein, wenn sich auch alle anderen in der gesamten verarbeitungskette zu 100% an die isos etsis und ias halten.

[Engelbert]

Ob das dem seitherigen Ansehen der DVBViewer hilft?

[Derrick]

Wenn man glück hat, wird dieser spezielle fehler beim DVBViewer vermieden. In der CA_PMT bei der FireDTV scheint der stream type korrekt gesetzt zu sein

 

Als beispiel das premiere sport portal, das u.a. mit meinem abo hell wird. Die analyzer.xml davon im anhang.

 

Die ca_pmt ist gefiltert d.h. nur ca_ids, die mit modul/karte entschlüsselt werden können, sind drin (hier nur betacrypt_getunneltes aladin aber kein reines nagra). So sieht das aus:

 

03 11 00 D3 00 11 01 09 06 17 22 F0 11 00 11 09

06 17 02 F0 11 00 11 06 00 20 00 00 02 00 FF 00

00 04 01 00 00 00 04 01 01 00 00 06 01 03 00 00

05 0B 12 00 00 63

 

die elementary_stream_pids mit dem zugehörigen stream type sind fett:

 

02 00 FF -> ISO/IEC 13818-2 Video

04 01 00 -> ISO/IEC 13818-3 Audio

04 01 01 -> ISO/IEC 13818-3 Audio

06 01 03 -> AC-3

 

 

[maju]

Wenn man glück hat, wird dieser spezielle fehler beim DVBViewer vermieden. In der CA_PMT bei der FireDTV scheint der stream type korrekt gesetzt zu sein

 

D.h. diese "Unschönheit" tritt nicht immer auf, sondern nur beim Einsatz von Twinhan Hardware?

D.h. nur die Twinhan CI Unterstützung ist noch nicht ganz 100%ig ausprogrammiert?

 

... oder habe ich da jetzt was falsch verstanden?

Edited November 24, 2006 by maju

[Derrick]

kann ich ohne twinhan nicht sagen..

[Guest Lars_MQ]

Ich bin Derricks halbwissen langsam leid.

 

@maju: ja es tritt nur bei der Twinhan aus. und nein das ist nicht unsauber programmiert, jede dvb-karte und CI muss gesondert behandelt werden.

 

Ich habe inzwischen durch diese diskussion insgesamt das interesse an der CI unterstützung verloren. Ich besitze keine firedtv, meine twinhan läuft, ich habe kein CI und auch keinerlei subscription. Ich helfe gerne aber ich muss mir derricks halbgewalktes gerede und spezifikationen gereite über dinge deren inneren wirkweisen er nicht begreifen will, nicht mehr antun.

 

Es gibt eine lösung, sie scheint zu funktionieren und ich verstehe warum Griga sich weigert CI zu integrieren.

 

Ich für meinen teil muss meine freizeit nicht weiter damit verplempern.

[Derrick]

Es gibt objektiv beweisbare bugs. Dieser thread zeugt davon. Halbwissen scheint eher pate bei der implementierung gestanden zu haben. Im standard steht nicht, wie der programmierer prgrammieren muss oder in welcher sprache. Nur das ergebnis zählt und das ist mangelhaft.

 

Grigas entscheidung ist sicher weise. Wenn der DVBViewer aber mit anderen auch in zukunft mithalten will, gehört das CI als immer wichtigerer bestandteil dazu und müssen die alten "legacy" zöpfe raus.

[hackbart]

@Lars: Mir geht das genauso. Irgendwie trollt "unser" Derrick seit geraumer Zeit quer durch das Forum und versucht unfrieden zu stiften.

 

Christian

[Engelbert]

Als schlichter User sehe ich das allerdings nicht so, obwohl ich auch manche Rüge einzustecken hatte.

 

Wenn nach dem dankenswerten Einsatz von User maju eine Fehlerquelle einzukreisen war, sollte man diese Erkenntnisse doch wirklich nutzen.

 

Im Gegensatz zu den SAT-Usern haben die Kabelnutzer seit Jahresbeginn keine Möglichkeit mehr, außer den ÖR-Sendern etwas anderes zu empfangen, wenn sie keine Karte mit CI-Funktionalität verwenden. DSVB-T? Na, ja!.

 

Da neben den TechniSat-Karten als erste die TwinHan-Geräte hier empfohlen wurden, sollte es für den DVBViewer eine Selbstverständlichkeit sein, diesem Manko gründlich abzuhelfen, zumal es derzeit kaum eine Alternative (zu kaufen) gibt.

[Guest Lars_MQ]

Engelbert: Ich denke, es gibt zeiten, da sollte man als user auf die aussagen eines echten insiders (nicht Derrick!!) vertrauen. Es sei denn du möchtest riskieren, das deine TS aufnahmen die nächsten beta versionen lang nicht mehr so gehen wie erwartet und auch andere dinge sich nicht mehr so fügen wie gewollt.

 

Ich muss mich an dieser stelle nochmals von derricks aussagen distanzieren. Er hat weder das nötige hintergrundwissen noch den willen, um wirklich zu beurteilen, was wirklich ein fehler oder nur ein verständnissproblem seinerseits ist.

 

Und ich entschuldige ich auch bei allen Usern für das ungebührliche und verunsichernde verhalten das ein Mod hier verursacht. wir werden dies aber nicht öffentlich, sondern intern diskutieren.