Oscam Versuch V13/NDS

[kasi45]

AW: Oscam Versuch V13/NDS

Hallo,
meine Frage, wieso gibt es zwischen diesen beiden Zeilen einen so großen Zeitunterschied?

2013/10/03 01:08:58 107A68 c dvbapi (0963&000000/FFFF/1133/5F:0EA9A72DDE4559B91A061497B1F43FF9): found (194 ms) by oscam_server
2013/10/03 01:09:05 107A68 c dvbapi: mcamsg: OPENXCAS_ECM_CALLBACK

die erste Zeile, das OK und die zweite Zeile der Beginn der nächste Abfage?
Der Logausschnitt von Gompf entspicht auch meinem Log bei kabelkarte 09C7.

vg kasimodo

 

[gompf]

AW: Oscam Versuch V13/NDS

@kasimodo : Das ist normal. Duerfte bei allen Karten gleich sein ja nach ECM Zeit, aber das Problem ist wirklich mit allen NDS Karten.

@dirtyharry : Das ist kein sprung, das sind ja zwei verschiedene aktionen die da laufen. aber von 58 nach 6 sind es einfach im Minimum 8sec nach adam riese, was eindeutig zu spaet ist. so spaet ist er aber nicht immer (trotzdem aber nie rechtzeitig). Ich bin aber genau da massiv am testen und codem im Moment. Mal sehen ob da was geht.

Was mich nervt ist das ich bei jedem neu einspielen der oscam das cam rebooten muss, was ewig dauert. weis da jemand eine Moeglichkeit wie man oscam im betrieb sauber runterfahren kann (also mca technisch) damit ich es im Betrieb tauschen kann ? Das spart ein paar Minuten pro versuch. ziemlich aergerlich mit einen change 3-4 Minuten zu warten bis zu test

/Gompf

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Also in deinem Log gehts von 58 auf 05, also genau 7 Sekunden (nach Adam Riese :emoticon-0143-smirk).
Das Problem sind ja nicht die 7 Sekunden zwischen den ECMs (und ich gebe dir Recht, dass es sehr wahrscheinlich daran liegt, dass die ECM zu lange vom CAM zu oscam braucht), sondern die Zeit die zwischen Senden der ECM und Wechseln des CWs liegt (Ich vermute mal unter einer Sekunde), also die Zeit die der Empfänger hat das CW zu entschlüsseln und zurück ans CA zu schicken.

Was das neustarten von oscam angeht, hat bei mir meistens folgender Trick funktioniert.
- Auf einen FTA-Sender schalten
- oscam neustarten
- Anschließend wieder auf einen verschlüsselten Sender (evtl. noch ein paar mal hin und her).

Das Problem mit dem Neustarten scheint zu sein, dass mcam weiter fleißig in die pipe reinschreibt, die aber irgendwann "überläuft", bei einem Wechsel auf FTA werden dann keine ECMs mehr geschrieben.

Grüße

dirtyharry123

 

[gompf]

AW: Oscam Versuch V13/NDS

Also in deinem Log gehts von 58 auf 05, also genau 7 Sekunden (nach Adam Riese :emoticon-0143-smirk).

-> Ja aber wie erwaehnt das ist der CW Request fuer das naechste CW. ECM sind asyncron, sprich der dann gesetze (06) ist der von davor (58). Sprich die 05 interessieren nicht sondern die 06 (die beiden debug Zeilen haben im OSCAM rein garnichts miternander zu tun, die sind NICHT sequenziell. Damit sinds nach Adam Riese wieder 8 Sek. Aber das ist egal ich bin schon weiter

Das Problem sind ja nicht die 7 Sekunden zwischen den ECMs (und ich gebe dir Recht, dass es sehr wahrscheinlich daran liegt, dass die ECM zu lange vom CAM zu oscam braucht), sondern die Zeit die zwischen Senden der ECM und Wechseln des CWs liegt (Ich vermute mal unter einer Sekunde), also die Zeit die der Empfänger hat das CW zu entschlüsseln und zurück ans CA zu schicken.

-> So weit meine Vermutung, ja (7 sek code wechsel, bei delaytem ECM). Leider ist die Falsch. Ich habe jetzt eine OSCAM gemacht, welche das CW sofort an den descrambler schickt sobald es da ist (Ja und das geht auch...), das hat im Prinzip keine Aenderung gebracht, der Freezer ist immernoch der selbe obwohl der code nun ca. 1 Sekunde nach der codeanfrage anliegt, mcam kann den also sofort uebernehmen oder eben dann wenn er gebraucht wird (was die schlechtere Moeglichkeit waere). Sprich der Ansatz beweisst der code kommt trotzdem zu spaet und dass die OSCAM nicht die Schuldige ist, damit stehen nun die Zeichen auf die gute mcam. Ich gehe nun davon aus das NDS vielleicht noch ein paar Sachen im ECM stream macht (werde mal dne NDS reader studieren) die dazufuehren das es sich verhaspelt oder irgentwo busy ist und deswegen den cw wechel um ca. 500 ms verpasst oder es ist das CAM selbst. Was mich wieder zu meiner idee bringt das mcam ganz rauszuschmeissen und eine iso smartcard zu emulieren im oscam. Wie das nun laeuft, dafuer gibts im oscam ja genuegend readers, man muss es halt genau andersherum machen. Hoert sich toll an, ist aber sicher massiv Aufwand.

Das Problem mit dem Neustarten scheint zu sein, dass mcam weiter fleißig in die pipe reinschreibt, die aber irgendwann "überläuft", bei einem Wechsel auf FTA werden dann keine ECMs mehr geschrieben.

-> das mit dem FTA werde ich probieren. bisher habe ich einfach den stream abgestellt, aber wenn ich oscam neustarten haengt das ganz ganz early im startup..... und davon kommt es auch nicht wieder raus, und laesst sich nichtmal terminaten, ich denke es haengt in einem Lock, waerend es auf das file wartet oder so.

/Gompf

 

[2predator]

AW: Oscam Versuch V13/NDS

Moin

Könnte es auch sein das Controller und Arbeitsspeicher zufiel Zeit verstreichen lassen und die Abfrage von Schnittstelle zu oscam zu lange dauert?

Das würde auch die längeren Umschaltzeiten erklären, Die 3 Sekunden Differenz mögen bei betacrypt und co nicht ausmachen aber bei NDS zu Problemen führen.

Man könnte auch mal einen Test machen.
Ich ziehe eine s02 aus dem Receiver und schaue wie lange das bild noch bleibt, das selbe mach ich mit eine v13.

 

[gompf]

AW: Oscam Versuch V13/NDS

Könnte es auch sein das Controller und Arbeitsspeicher zufiel Zeit verstreichen lassen und die Abfrage von Schnittstelle zu oscam zu lange dauert?

-> Leider nein, denn mein test beweisst, dass das nicht der Grund ist.

Das würde auch die längeren Umschaltzeiten erklären, Die 3 Sekunden Differenz mögen bei betacrypt und co nicht ausmachen aber bei NDS zu Problemen führen.

-> Leider auch nicht, da der verschluesselte stream nur einmal da ist egal ob NDS or S02 erfolgt der ECM auch immer zur selben Zeit und liegt auch gleich lange an. eventualle differenzen beim ausloesen des ECM sind leider nicht der Grund.

Man könnte auch mal einen Test machen.
Ich ziehe eine s02 aus dem Receiver und schaue wie lange das bild noch bleibt, das selbe mach ich mit eine v13.

-> Ich vermute maximal 7 Sek, je nachdem wann du die Karte ziehst. Was ich damit sagen will ist, spar Dir den Test. das ist konzeptionell anders als Du denkst, oder aber ich habe nicht verstanden was Du eigentlich meinst.

/Gompf

 

[2predator]

AW: Oscam Versuch V13/NDS

OK versuch ichs mal anders

Du haste eine Unbekate verzögerung der ecm zeit X verursacht durch das marix modul, wenn x =2 000ms + die ecm zeit die durch das Sharing entsteht also 800 ms so sind das 2800 ms. das reicht aus um eine s02 z.B zu Sharen.
Bei einer v13 wären das 2050 ms da aber die nds Verschlüsselung mit wesentlich niedriger ecm Zeiten auskommen muss , reicht es einfach nicht.


Ich hoffe das ich jetzt keinen technischen quatsch erzählt haben. das würde aber auch die längeren Umschaltzeiten begründen. irgend woher müssen die ja herkommen.

 

[gompf]

AW: Oscam Versuch V13/NDS

Also das ist so, das eigentliche Programm ist nur einmal verschluesstlet. Egal ob Du eine S02 oder V13/V14 Karte hast. die Verschluesselung ist ein XOR mit einem entsprechenden Schluessel, und der ist immer gleich und muss zur gleichen Zeit kommen, bein CW wechsel. Es aendert sich alle 7 Sekunden (Bei SKY DE, andere sind anders) genau die Haelfte des schluessels (even oder odd). Das verfahren nennt sich ueberigens Simulcrypt.

Sprich egal welche Karte Du hast und wie die das CW berechnet, am Schluss kommen alle 7 Sekunden immer die selben CWs aus beiden Karten heraus und zwar zur selben Zeit.

Das es kein zuspaetgekommener ECM/bzwdessen Antwort im OSCAM sein kann habe ich verifiziert, indem ich die Antwortzeiten massiv gedrueckt habe, so dass der das jeweilige CW bereits 5 SEK vor codewechsel am Scrambler anlag und es ist nicht besser geworden, eher sogar schlechter (was mir auch etwas zu denken gibt). Mit einer S02 hat da weiterhin auch sauber getan. Jetzt muss man den zweiten Teil des Problems untersuchen, die mcam Applikation auf der Karte, die den CW den wir im OSCAM an den "scrambler" uebertragen haben auch an den scrambler weiterleitet und vorallem wann.

/Gompf

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Richtig, egal welche Vershlüsselung verwendet wird, es muss immer das selbe CW bei rauskommen.
Allerdings IIRC ist der Abstand zwischen den ECMS bei einer S02 dennoch 10 Sekunden und bei einer V13 7.
Das wiederum würde heißen, dass bei der V13 teilweise identische CWs in den ECMs stehen.
Dazu fällt mir auch wieder ein, dass ich bei meinen letzen Tests beobachten konnte,
dass der Freezer immer erst dann enstand, wenn das CW geschrieben wurde.
Das ließ mich damals vermuten, dass irgendwas mit der parity der CWs nicht stimmt.
Da kam ich aber auch nicht wirklich weiter.
Wenn man parallel eine S02 hat wäre es vielleicht einen Versuch wert, das CW von der V13 erst dann zu schreiben,
wenn das von der S02 geschrieben würde.

dirtyharry123

 

[2predator]

AW: Oscam Versuch V13/NDS

du könntest ja mal eine test machen und einen oscam Delay: von 2000 einstellen.
wenn dann deine s02 auch aussteigt obwohl der ecm bei 2700ms steht wüste man schon mehr.

 

[gompf]

Das Geruecht mit den 10 Sek ECM habe ich auch mal geglaubt weil ich keine hatte, aber das stimmt nicht (ist matemathisch auch nicht wirklich loesbar das Problem).

Bei Mir ECMed sie jedenfalls auch alle 7 Sek. Was auch Sinn macht. Dabei Faellt aber auch auf , das die S02 eher zu Frueh da ist waeren die V13 eher zuspaet kommt. Ich habe leider (noch) keine 2 Matrix MOdule die Ich miteinander racen lassen koennte auf dem selben Kanal.

Spoiler

2013/10/05 23:26:51 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:D4653BF20E53105E74804CCE939FD2F1): found (64 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:26:57 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:06DD07901561AA5F780FEADF808638CB): found (77 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:03 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:36C1E46BE8D0632528269183B9747FC2): found (100 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:10 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:405FCF44502D1574E975788A6C6D5ACB): found (728 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:17 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:111F3EFB75D9A34888226828140229A8): found (134 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:23 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:3AA3E7538118BD70C1E8C2C2F994C9F7): found (146 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:30 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:6F7207801088D7CE9234491A9E7946D7): found (185 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:27:37 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:9930761542C8A09500DA147F3E1B9B1A): found (93 ms) by Reader-10 - Spiegel Geschichte

Allerdings kann das mit den 10Sek auch hierher kommen, denn das Timing des CAM ist immer noch schlecht. Man vergleiche die Logs. Bei mir behautet CAM das es alle 4-6 Sek ECMed. Meine Matrix Laeuft seit einigen tagen und das Timing ist dahin... Wobei es auch beim start nicht wirklich stimmt, also vorallem die ECM Intervalle.

Spoiler

CAM:
2013/10/05 21:25:08 40202098 c dvbapi (1702&000000/0000/0034/93:0494034D4ECE41608BFCF8DA469371C4): found (101 ms) by oscam_server - Spiegel Geschichte 
2013/10/05 21:25:13 40202098 c dvbapi (1702&000000/0000/0034/93:3354B99C41201E8FABBBA99F048F2A84): found (126 ms) by oscam_server - Spiegel Geschichte 
2013/10/05 21:25:18 40202098 c dvbapi (1702&000000/0000/0034/93:0621E4E7B8FF12C9E76FAC467B9BF0D9): found (77 ms) by oscam_server - Spiegel Geschichte 
2013/10/05 21:25:23 40202098 c dvbapi (1702&000000/0000/0034/93:A03F73EC7DA6DA97C7FC1E7DF80F9CDE): found (89 ms) by oscam_server - Spiegel Geschichte 
2013/10/05 21:25:26 40202098 c dvbapi (1702&000000/0000/0034/93:94EF3053410625711CE9007A4AB9293F): found (79 ms) by oscam_server - Spiegel Geschichte 
2013/10/05 21:25:30 40202098 c dvbapi (1702&000000/0000/0034/93:02445AC517FEC15BE7F5DCE73AFA217B): found (84 ms) by oscam_server - Spiegel Geschichte 

SERVER:
2013/10/05 23:36:00 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:0494034D4ECE41608BFCF8DA469371C4): found (92 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:36:08 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:3354B99C41201E8FABBBA99F048F2A84): found (127 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:36:15 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:0621E4E7B8FF12C9E76FAC467B9BF0D9): found (66 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:36:23 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:A03F73EC7DA6DA97C7FC1E7DF80F9CDE): found (78 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:36:29 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:94EF3053410625711CE9007A4AB9293F): found (70 ms) by Reader-10 - Spiegel Geschichte 
2013/10/05 23:36:36 6C40F8 c MatrixCAir-01-0 (1702&000000/0000/0034/93:02445AC517FEC15BE7F5DCE73AFA217B): found (70 ms) by Reader-10 - Spiegel Geschichte

/Gompf

Also das mit der Parity habe ich auch ausgelotet da ich da zunaechsteinmal auch den bisher einzigen wirklichen unterschied erkennen kann (S02 sendet ganze CWs also auch den gerade nicht gewechselten mit, waerend NDS nur das zu wechselnde halbe CW sended und das andere auf NULL gesetzt ist), ich sehe da nicht wirklich was (jedenfalls nicht im Moment) aber wie gesagt da liegt bisher auch der einzige wirkliche Unterschied bei einer V13/NDS Karte und einer S02/Nagra Karte.

V13/NDS

Spoiler

2013/10/06 11:08:45 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:6702C8D63270280EDCE8BF896E3A43D1): found (121 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:08:49 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (DE1AE0D8448A6F3D0000000000000000) 
2013/10/06 11:08:49 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (DE1AE0D8448A6F3D38B0250D454936C4) of controlword 
2013/10/06 11:08:49 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:32D2A77D45D2A90D711FE6638015C21A): found (120 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:08:53 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (00000000000000002A0B053A6F49BC74) 
2013/10/06 11:08:53 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (DE1AE0D8448A6F3D2A0B053A6F49BC74) of controlword 
2013/10/06 11:08:53 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:11D07179D020A662DEC9B9BCC425CBBA): found (108 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:08:58 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (81389C55D3F2975C0000000000000000) 
2013/10/06 11:08:58 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (81389C55D3F2975C2A0B053A6F49BC74) of controlword 
2013/10/06 11:08:58 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:38F25CC5716CD58B2D31BBECD3D6F95E): found (114 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:02 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (0000000000000000881FAB52D90B361A) 
2013/10/06 11:09:02 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (81389C55D3F2975C881FAB52D90B361A) of controlword 
2013/10/06 11:09:02 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:C2A644A7BC1B027DA1D5BBDBE4D5BC1D): found (118 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:06 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (199B5A0ED7B754E20000000000000000) 
2013/10/06 11:09:06 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (199B5A0ED7B754E2881FAB52D90B361A) of controlword 
2013/10/06 11:09:06 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:98E50D98A6AFD17BA6AFEFA520920515): found (108 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:11 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (00000000000000005509E745F8C2DF99) 
2013/10/06 11:09:11 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (199B5A0ED7B754E25509E745F8C2DF99) of controlword 
2013/10/06 11:09:11 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:F64429741A5EAD2E492F6081281B7104): found (112 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:16 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (423E98189E798DA40000000000000000) 
2013/10/06 11:09:16 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (423E98189E798DA45509E745F8C2DF99) of controlword 
2013/10/06 11:09:16 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:A20A012A28B62B77AAAA07BCBE5B702F): found (123 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:20 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (0000000000000000BC2412F2D0670B42) 
2013/10/06 11:09:20 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (423E98189E798DA4BC2412F2D0670B42) of controlword 
2013/10/06 11:09:20 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:71BE7932E50A8CF4C1542015A84BF33C): found (115 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:09:24 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (48BF080F330C2A690000000000000000) 
2013/10/06 11:09:24 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (48BF080F330C2A69BC2412F2D0670B42) of controlword 
2013/10/06 11:09:24 10F3D0 c dvbapi (09C4&000000/0195/0034/B3:10C5EF5B1BF5229B64DD60DE776CA8E7): found (114 ms) by oscam_server - Spiegel Geschichte

S02/Nagra

Spoiler

2013/10/06 11:12:16 10F3D0 c dvbapi (1702&000000/0000/0034/93:2353562208B8A367A4C9238AB8A5E5A1): found (22 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:18 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (1301B8CC088EEA80F1BCE794106AC23C) 
2013/10/06 11:12:18 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (1301B8CC088EEA80F1BCE794106AC23C) of controlword 
2013/10/06 11:12:18 10F3D0 c dvbapi (1702&000000/0000/0034/93:9960A5EB3DA5DA0255C497769FD841B2): found (21 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:22 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (1301B8CC088EEA8057B4838E356BBD5D) 
2013/10/06 11:12:22 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (1301B8CC088EEA8057B4838E356BBD5D) of controlword 
2013/10/06 11:12:22 10F3D0 c dvbapi (1702&000000/0000/0034/93:83CE09D24354ABC99DA02D438C4A0FAA): found (22 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:26 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (09AFECA435634AE257B4838E356BBD5D) 
2013/10/06 11:12:26 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (09AFECA435634AE257B4838E356BBD5D) of controlword 
2013/10/06 11:12:26 10F3D0 c dvbapi (1702&000000/0000/0034/93:6374BA2FDECE0175C87367FDE8C838A8): found (22 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:31 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (09AFECA435634AE2928AF814681CF478) 
2013/10/06 11:12:31 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (09AFECA435634AE2928AF814681CF478) of controlword 
2013/10/06 11:12:31 10F3D0 c dvbapi (1702&000000/0000/0034/93:EEA18FFF422ED285E80737CC13337718): found (22 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:36 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (4F18CB32EE23B3C4928AF814681CF478) 
2013/10/06 11:12:36 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (4F18CB32EE23B3C4928AF814681CF478) of controlword 
2013/10/06 11:12:36 10F3D0 c dvbapi (1702&000000/0000/0034/93:0853EBC83E600F0CA9BF2D87E2C910B7): found (112 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:41 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (4F18CB32EE23B3C4DCB40F9FD69D1184) 
2013/10/06 11:12:41 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (4F18CB32EE23B3C4DCB40F9FD69D1184) of controlword 
2013/10/06 11:12:41 10F3D0 c dvbapi (1702&000000/0000/0034/93:2445EA97F4FB5FC550C83E2A15E6A033): found (20 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:46 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (EA35CCEBF77F8C02DCB40F9FD69D1184) 
2013/10/06 11:12:46 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (EA35CCEBF77F8C02DCB40F9FD69D1184) of controlword 
2013/10/06 11:12:46 10F3D0 c dvbapi (1702&000000/0000/0034/93:F51454325330B3585CC937BDB309DD81): found (20 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:49 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (EA35CCEBF77F8C028D19670DC08690D6) 
2013/10/06 11:12:49 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing even part (EA35CCEBF77F8C028D19670DC08690D6) of controlword 
2013/10/06 11:12:49 10F3D0 c dvbapi (1702&000000/0000/0034/93:89A44598422616F857AE26C590889AAA): found (21 ms) by oscam_server - Spiegel Geschichte 
2013/10/06 11:12:54 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 current cw receiv (9D25D698831190248D19670DC08690D6) 
2013/10/06 11:12:54 10F3D0 c dvbapi: [DVBAPI] Demuxer #0 writing -odd part (9D25D698831190248D19670DC08690D6) of controlword

Die geposteten CWs sind natuerlich nur zur Referenz und entsprechend abgaendert und damit useless bevor sich hier wer aufregt.

/Gompf

 

[dirtyharry123]

AW: Oscam Versuch V13/NDS

Könnte es sein, dass hier zum Teil odd und even vertauscht sind bei der V13?
Und kannst du bestätigen, dass die Freezer immer erst dann kommen, wenn das CW geschreiben wird?

dirtyharry123

 

[vortex]

AW: Oscam Versuch V13/NDS

Ich beteilige mich mal am brainstorming..
was mir aufgefallen ist, ist, dass der Prozess "mcam mca test" immer auf peak ist, und es dann ruckelt...

wielleicht ist einfach nur die Übergabe an die Schnittstelle nicht wirklich einwandfrei...

 

[powerpaul]

AW: Oscam Versuch V13/NDS

Wurde ja schon mehrmals geschrieben das es eher eine Firmware Problematik ist, als ein reines Software/Oscam Problem..

 

[gompf]

AW: Oscam Versuch V13/NDS

Könnte es sein, dass hier zum Teil odd und even vertauscht sind bei der V13?
Und kannst du bestätigen, dass die Freezer immer erst dann kommen, wenn das CW geschreiben wird?

dirtyharry123

Das kann sein, aber es muesste aber keine permanent Vertauschung sein denn sonst wuerde es ja garnicht gehen so wie es im Moment aussieht. Aber ja ich kann es bestaetigigen, der Freez kommt immer dann wenn das CW geschrieben wir. Das kann ich hier aber mal tracen, auch wenn das etwas Aufwand ist.

/Gompf

/Update: Even/Odd scheint ok zu sein, habe ich mit einem Trippletrace mit entsprechend debug (1702 vs 2 09C4 clienten) ueberprueft.