Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

gelöst HD05 Probleme mit den aktuellen oscam Versionen

    Nobody is reading this thread right now.
Danke für den Tipp. Das werde ich ausprobieren.

Edit:
So, bei mir läuft jetzt die 11583. Bin gespannt, wie sich die Karte die nächsten Tage verhält...

Gesendet von iPhone mit Tapatalk
 
Zuletzt bearbeitet:
läuft die HD05 wieder ziemlich genau für 24 Stunden bis zum nächsten EMM, der den Reader mit hoher Wahrscheinlichkeit abstürzen lässt
EMM's könntest du ja weglassen , das Valid to gibt dir ja da ein wenig Spielraum , so das du da locker über 24 Stunden kommen solltest.
Da wäre noch das 36 K CMD Problem , was bei der HD05 besteht und wenn dann kein richtiger Fastreinit erfolgt ist es schlecht. Scheint ja bei dir dann eher zu zu treffen, das da das Limit erreicht wird.
Code:
04.11.2020 07:02:11 5B5B97E3 r   (reader) HD05_2 [Nagra Merlin] 35378 CMD's left to FASTreinit
04.11.2020 07:02:11 0CC3E017 r   (reader) HD05 [Nagra Merlin] 35378 CMD's left to FASTreinit
04.11.2020 09:02:28 0CC3E017 r   (reader) HD05 [Nagra Merlin] negotiating new Session Key
04.11.2020 09:02:28 0CC3E017 r   (reader) HD05 [Nagra Merlin] OTP CSC No. of Keys: 00 01 
04.11.2020 09:02:28 0CC3E017 r   (reader) HD05 [Nagra Merlin] OTA CSC No. of Keys: 00 00 
04.11.2020 09:02:28 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] negotiating new Session Key
04.11.2020 09:02:28 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] OTP CSC No. of Keys: 00 01 
04.11.2020 09:02:28 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] OTA CSC No. of Keys: 00 00 
04.11.2020 09:02:28 0CC3E017 r   (reader) HD05 [Nagra Merlin] 32757 CMD's left to FASTreinit
04.11.2020 09:02:28 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] 32757 CMD's left to FASTreinit
04.11.2020 09:02:28 0CC3E017 r   (reader) HD05 [Nagra Merlin] Card is starting in GLOBAL Mode
04.11.2020 09:02:28 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] Card is starting in GLOBAL Mode
04.11.2020 09:02:29 0CC3E017 r   (reader) HD05 [Nagra Merlin] New AES: 5D A0 D0 C7 AC 2F 14 74 B2 CD 05 43 F7 6F 71 26 
04.11.2020 09:02:29 5B5B97E3 r   (reader) HD05_2[Nagra Merlin] New AES: 5B 5C 8F 58 92 74 A9 A4 0F 86 2A 6F AF E3 DE F5
Meine Beobachtungen gehen das eher dahin, das Reinit nicht richtig funktioniert und die Karte somit nicht richtig initialisiert wird, was man auch im Log erkennen kann, das die Entitlements nicht vollständig eingelesen werden.
Ich selbst und auch Smod nutzen genau den gleichen Refresh Entitlements Part aus dem Changeset 11584 und haben kein Problem damit, also muss die Ursache wie schon geschrieben an anderer Stelle liegen.
 
Zuletzt bearbeitet:
Ich würde jetzt nicht zu viel auf einmal ändern. Immer eins nach dem anderen. Er sollte die 11583 jetzt erstmal mit gleicher Konfig laufen lassen. Wenn man mehrere Dinge auf einmal ändert, zieht mal oft danach die falschen Schlüsse, was denn nun die Ursache war
 
Dem schliesse ich mich an. Mal sehen, wie lange die Karte ohne geblockte EMMs durchhält. Sobald mir hier belastbare Erkenntnisse vorliegen, folgt dasselbe Spiel nochmal mit geblockten EMMs.
 
der implementierte refresh ist der gleiche der beim starten der karte verwendet wird
add_job(reader->client, ACTION_READER_CARDINFO, NULL, 0);
das ist keine neue funktion der thread wird einfach nur gecallt

das ist die gleiche funktion die aufgerufgfen wird wenn mann refresh entitlement im webif aufruft

was ihr testen könnt ist die zeit zum refreshen zu verzögern obs dann besser wird
zb:
als einfachstes
if((gone_now > 3600*1000) || (gone_refresh > 12*3600*1000)) ändern in
if((gone_now > 2*3600*1000) || (gone_refresh > 24*3600*1000))

das verdoppelt die zeit bis zum refreshen denke ich
 
Ich kann mir durchaus vorstellen, dass aus Auslesen der entitlements, auch mit den gleichen Methoden wie beim Kartenstart oder aus dem WEBif, nach dem direktem EMM Schreiben ein Problem sein kann. Wenn es eins ist, dann würde dass auch beim Auslesen aus dem WEBif passieren, wenn kurz vorher ein EMM Schreibvorgang m passenden Zenster war. Die Wahrscheinlichkeit ist nur ganz anders und solange man das im WEBif nicht macht, kann ja auch nichts passieren. Wenn es aber getriggert durch einen EMM Schreibvorgang kurz danach dann problematisch ist, dann wird man in das Problem laufen. Das haben ja schon mehrere Nutzer so erlebt.

Vielleicht darf man das einfach eine gewissen Zeit lang nach dem Schreiben einer passenden EMM nicht machen, weil die Karte sich dann verklemmt, weil sie intern die EMM verarbeitet während dann ausgelesen wird.
 
ok ich lösch dann meinen beitrag darüber wenn der schon nicht gelesen wird
 
Ich habe ihn gelesen, aber der Vorschlag würde dann den refresh nur seltener aufrufen aber immer noch nach einem EMM write oder verstehe ich das falsch
 
nein nicht seltener ... er würde ihn verschieben um das doppelte an zeitraum das verhindert möglicherweise an zb lahmen vu boxen die den reader nicht schneller bekommen freezer
 
Habe nochmal in die Sourcen geschaut und bin nicht überzeugt, dass diese Verdopplung von 12 auf 24 das refresh verschiebt. Diese Abfrage passiert ja im EMM Write und das refresh wird dann je nach Ergebnis der genannten Abfrage dann direkt beauftragt, findet also immer noch kurz nach dem letzten EMM Write statt oder auch nicht. So verstehe ich diese Konstruktion . Und wenn das refresh kurz nach einem EMM Write eine Problem sein sollte, ist das dann immer noch ein Problem, egal ob der Faktor 12 oder 24 ist
 
Ich habe das Problem gar nicht. Kenne aber einige, die das Problem haben. Und die haben es nicht, wenn der autorefresh nicht aufgerufen wird.
 
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…