Hi Leute,
Ich bin was mein Wissen über Programmierung und CS im Detail angeht weiß Gott kein Anfänger, nur dieses Problem lässt mich nicht in Ruhe.
Folgendes:
Derzeit verwende ich Acamd im DVBViewer mit 3 Lines, für jede CAID einzeln. Problem: teilweise gleich 3 Logins auf ein und dem selben User.
Nun Versuche ich es so ins laufen zu kriegen, wie ich es bisher auch bei vielen Receivern mit Newcamd (mgclient, extended Newcamd) mache, über einen Port mehrere CAIDs übertragen.
Acamd bietet hier die newcamd2-Line für an. Das funktioniert auch, bei allen Kartensystemen, die vollständige Kontrollwörter liefern.
Bei Sky (V14) jedoch, wird immer nur eine Hälfte des Kontrollwortes gesetzt. Nun scheint laut Monitor in Acamd das leere Kontrollword in den meisten Fällen durch ein Zufälliges aufgefüllt zu werden.
Somit kommt es bei jedem Keywechsel zu einem Freezer von etwa einer halben Sekunde, äußert sich wie schlechter Empfang.
In ganz wenigen Fällen, läuft es mal 3-4 Abfragen gut, dann wird der CW in Acamd mit Nullen aufgefüllt. Was auch korrekt ist.
Das Netzwerkprotokoll von Oscam habe ich bereits überprüft, es wird an den Client defnitiv das komplette Kontrollword übermittelt, die andere Hälfte ist jeweils als Nullbytes.
Beispiel Sky, geloggte CW:
Hier sieht man, dass die Kontrollwordhälften (odd und even) abwechselnd übertragen werden und die andere hälfte genullt ist.
Im gegensatz bei den HD+ sendern über die HD02 karte:
Hier wird zwar auch immer nur eine Hälfte aktualisiert, aber die andere hälfte wird "mitgeschleift" und nicht genullt sondern aktualisiert.
Die Logfile in Acamd sieht übrigens so aus bei Sky mit ganz normalen Newcamd, wo alles fehlerfrie läuft:
HD+:
Bei HD+ sieht es genauso aus, weil Acamd hier offenbar auch immer nur den teil aktualisiert, der gerade neu ist, bei Key sieht man das auch deutlich, dass hier das komplette CW immer vollständig ist.
bei newcamd2, sieht es dagegen anders aus.
SendDCW wird immer für odd und even ausgeführt. Dabei ist die gerade abgefragte hälfte korrekt, die andere immer irgendwie etwas zufälliges. Das Problem, die alte CW-Hälfte ist eine gewisse Zeit lang
noch gültig (ca 500ms, das timeout für die Sky v14 karte) Wenn jetzt aber das alte CW durch einen zufälligen ungültigen Wert getauscht wird ist es klar, dass dort Müll bei herauskommt:
Das einzige was bei Sky hilft, ist entweder warten, oder mehrfach auf "rescan" klicken, dann fängt er sich irgendwann für ein paar Minuten, bis dann das gleiche Problem erneut auftritt:
Ich habe hier einmal einen Ausschnit aus der Logfile,
Ist jetzt aus einer Logfile in der in ca 60 Sekunden 15MB zurecht gekommen sind, denn zu dem o.g. Problem kommt noch, dass Acamd jeden einzelnen EMM rausschickt, auch wenn dieser nicht zur Karte passt, alles was er empfängt.
Lustigerweise kommen diese bei Oscam nie an. Aufgrund der schieren Größe der Logdatei müssen die Zeitangaben nicht stimmen.
Wenn ich AU bei Acamd deaktiviere (habe ich einmal testhalber gemacht) kommt etwas anderes bei heraus. In dem Fall gibt es nur 2 SendDCW, nicht Drei, immer noch einer zu viel.
EMMs funktionieren bei HD+ ganz normal. Laut Logfile von Acamd werden die Seriennummern der Karten auch korrekt übertragen, für beide Karten.
Dennoch macht Acamd 6.2.0 Müll.
Alle anderen Clients mit Extended Newcamd-Protokoll funktionieren Fehlerfrei.
CCCam kommt für mich nicht in Frage, da Acamd hier beispielsweise bei Sky Select nur eine Abfrage macht, und Anschließend nicht mehr entschlüsselt, damit habe ich schonmal eine Sky Select Bestellung verhauen, hätte ich keinen Transponder-Dump angefertigt und nachträglich entschlüsselt.
Zusätzlich kann ich von Hadu auch nur abraten, da dieser nur CCCam kann. EMMs habe ich hier noch nicht getestet. Problem ist jedoch, dass bei mehr als 2 Instanzen (DVBViewer Recording-Service)
Fehler beim Entschlüsseln entstehen, das liegt an einer nicht Threadsicheren Implementierung des CSA-Algorithmus oder übrigen Komponenten von Hadu.
Das ist erst einmal eine Menge Stoff, aber vielleicht gibt es ja den ein oder anderen Experten hier, der mir weiter helfen kann, oder mir bescheid geben kann wo ich die Sourcen von Acamd zwecks weiterentwicklung / Fehlerkorrektur finde.
Gruß
t5b6
Nachtrag, ein ideales beispiel:
Oscam log:
Dazugehörende Acamd-Log
Die dort freigestellte Anfrage erzeugte keinen Freeze.
Hier wurde kein "zufälliger" Wert gesetzt.
Anhand der Oscam-Log kann genau gesehen werden, welche CWs falsch sind, ich habe diese der Einfachheit mal farblich markiert. Grün korrekt, Rot falsch.
Wie komme ich darauf, dass es zufällig ist?
-> Ganz Einfach, Klick auf den Rescan button forciert erneut einen SendDCW. Beide CW-Hälften werden geschrieben. Die korrekte, derzeit gültige Hälfte bleibt immer gleich, die andere hälfte variiert zufällig.
Ich bin was mein Wissen über Programmierung und CS im Detail angeht weiß Gott kein Anfänger, nur dieses Problem lässt mich nicht in Ruhe.
Folgendes:
Derzeit verwende ich Acamd im DVBViewer mit 3 Lines, für jede CAID einzeln. Problem: teilweise gleich 3 Logins auf ein und dem selben User.
Nun Versuche ich es so ins laufen zu kriegen, wie ich es bisher auch bei vielen Receivern mit Newcamd (mgclient, extended Newcamd) mache, über einen Port mehrere CAIDs übertragen.
Acamd bietet hier die newcamd2-Line für an. Das funktioniert auch, bei allen Kartensystemen, die vollständige Kontrollwörter liefern.
Bei Sky (V14) jedoch, wird immer nur eine Hälfte des Kontrollwortes gesetzt. Nun scheint laut Monitor in Acamd das leere Kontrollword in den meisten Fällen durch ein Zufälliges aufgefüllt zu werden.
Somit kommt es bei jedem Keywechsel zu einem Freezer von etwa einer halben Sekunde, äußert sich wie schlechter Empfang.
In ganz wenigen Fällen, läuft es mal 3-4 Abfragen gut, dann wird der CW in Acamd mit Nullen aufgefüllt. Was auch korrekt ist.
Das Netzwerkprotokoll von Oscam habe ich bereits überprüft, es wird an den Client defnitiv das komplette Kontrollword übermittelt, die andere Hälfte ist jeweils als Nullbytes.
Beispiel Sky, geloggte CW:
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Im gegensatz bei den HD+ sendern über die HD02 karte:
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Die Logfile in Acamd sieht übrigens so aus bei Sky mit ganz normalen Newcamd, wo alles fehlerfrie läuft:
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
HD+:
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Bei HD+ sieht es genauso aus, weil Acamd hier offenbar auch immer nur den teil aktualisiert, der gerade neu ist, bei Key sieht man das auch deutlich, dass hier das komplette CW immer vollständig ist.
bei newcamd2, sieht es dagegen anders aus.
SendDCW wird immer für odd und even ausgeführt. Dabei ist die gerade abgefragte hälfte korrekt, die andere immer irgendwie etwas zufälliges. Das Problem, die alte CW-Hälfte ist eine gewisse Zeit lang
noch gültig (ca 500ms, das timeout für die Sky v14 karte) Wenn jetzt aber das alte CW durch einen zufälligen ungültigen Wert getauscht wird ist es klar, dass dort Müll bei herauskommt:
Das einzige was bei Sky hilft, ist entweder warten, oder mehrfach auf "rescan" klicken, dann fängt er sich irgendwann für ein paar Minuten, bis dann das gleiche Problem erneut auftritt:
Ich habe hier einmal einen Ausschnit aus der Logfile,
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Ist jetzt aus einer Logfile in der in ca 60 Sekunden 15MB zurecht gekommen sind, denn zu dem o.g. Problem kommt noch, dass Acamd jeden einzelnen EMM rausschickt, auch wenn dieser nicht zur Karte passt, alles was er empfängt.
Lustigerweise kommen diese bei Oscam nie an. Aufgrund der schieren Größe der Logdatei müssen die Zeitangaben nicht stimmen.
Wenn ich AU bei Acamd deaktiviere (habe ich einmal testhalber gemacht) kommt etwas anderes bei heraus. In dem Fall gibt es nur 2 SendDCW, nicht Drei, immer noch einer zu viel.
EMMs funktionieren bei HD+ ganz normal. Laut Logfile von Acamd werden die Seriennummern der Karten auch korrekt übertragen, für beide Karten.
Dennoch macht Acamd 6.2.0 Müll.
Alle anderen Clients mit Extended Newcamd-Protokoll funktionieren Fehlerfrei.
CCCam kommt für mich nicht in Frage, da Acamd hier beispielsweise bei Sky Select nur eine Abfrage macht, und Anschließend nicht mehr entschlüsselt, damit habe ich schonmal eine Sky Select Bestellung verhauen, hätte ich keinen Transponder-Dump angefertigt und nachträglich entschlüsselt.
Zusätzlich kann ich von Hadu auch nur abraten, da dieser nur CCCam kann. EMMs habe ich hier noch nicht getestet. Problem ist jedoch, dass bei mehr als 2 Instanzen (DVBViewer Recording-Service)
Fehler beim Entschlüsseln entstehen, das liegt an einer nicht Threadsicheren Implementierung des CSA-Algorithmus oder übrigen Komponenten von Hadu.
Das ist erst einmal eine Menge Stoff, aber vielleicht gibt es ja den ein oder anderen Experten hier, der mir weiter helfen kann, oder mir bescheid geben kann wo ich die Sourcen von Acamd zwecks weiterentwicklung / Fehlerkorrektur finde.
Gruß
t5b6
Nachtrag, ein ideales beispiel:
Oscam log:
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Dazugehörende Acamd-Log
Du musst dich
Anmelden
oder
Registrieren
um diesen Inhalt sichtbar zu machen!
Die dort freigestellte Anfrage erzeugte keinen Freeze.
Hier wurde kein "zufälliger" Wert gesetzt.
Anhand der Oscam-Log kann genau gesehen werden, welche CWs falsch sind, ich habe diese der Einfachheit mal farblich markiert. Grün korrekt, Rot falsch.
Wie komme ich darauf, dass es zufällig ist?
-> Ganz Einfach, Klick auf den Rescan button forciert erneut einen SendDCW. Beide CW-Hälften werden geschrieben. Die korrekte, derzeit gültige Hälfte bleibt immer gleich, die andere hälfte variiert zufällig.
Zuletzt bearbeitet:
