Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

gelöst ORF EMM Verlängerungs-Problem bei 0D98 Crypto-Karten - (NEU: ohne needsglobalfirst)

Die shared EMMs für die P4-Karten scheinen sich vor ein paar Tagen geändert zu haben. Sie können jetzt anscheinend auch geschrieben werden, wenn zuvor kein global EMM geschrieben wird.

Der erste Test der Verlängerung einer ORF-P4 Karte (0D98) mit komplett gesperrten global EMMs (blockemm-g = 1, d.h. es werden nur noch shared EMMs geschrieben) sieht erfolgreich aus.
Die 01/02er IDs wurden zumindest schon mal problemlos verlängert.

Werde das ganze jetzt noch die nächsten Tage so laufen lassen.

Es sieht z.Zt. danach aus, dass die Funktion needsglobalfirst nicht mehr erforderlich ist.

Evtl. könnt ihr das auch mal prüfen.
 
Zuletzt bearbeitet:
Das wäre super, ich musste vor ein paar Wochen die Funktion needsglobalfirst deaktivieren, da zu viele global geschrieben wurden und es dadurch zu ruckler kam. Ich werde das auch gleich testen.
 
needsglobalfirst deaktivieren, da zu viele global geschrieben wurden und es dadurch zu ruckler kam.
Das kann ich nicht nachvollziehen.
Die Funktion schreibt genau nur ein global EMM pro zu schreibenes Shared EMM. Also maximal so viele global EMMs wie auch shared EMMs.
Das ist doch überhaupt kein Problem und führt auch nicht zu Freezern.

Wird die Funktion deaktiviert und blockemm-g = 0 gesetzt, wird die Karte nur so mit global EMMs bombardiert. Dann gibt es Freezer.
Egal.

Teste das mal mit komplett geblockten global EMMs.
 
Wie gesagt ich hatte Aussetzer. Ich hatte danach die funktion deaktiviert, also alles geblock und dann ging es wieder. Da ich nicht so viel Zeit hatte habe ich hier nichts geschrieben und konnte mich nicht mehr damit beschäftigen.
 
wenn ich jetzt "needsglobalfirst" raus nehme, brauch ich dann noch diese block-einträge?

[reader]
label = Local/ORF-ICE_0D98
enable = 1
detect = cd
protocol = mouse
device = /dev/ttyUSB2
caid = 0d98
ident = 0D98:000000,000004,000008,00000C,000010
services = orf_cw
mhz = 358
cardmhz = 358
pincode = none
inactivitytimeout = 1
reconnecttimeout = 30
emmcache = 1,1,2,0
audisabled = 0
au = 1
#needsglobalfirst = 1
blockemm-unknown = 1
blockemm-u = 1
blockemm-s = 0
blockemm-g = 0

lb_weight = 200
group = 3
 
Der erste Test der Verlängerung einer ORF-P4 Karte (0D98) mit komplett gesperrten global EMMs (blockemm-g = 1, d.h. es werden nur noch shared EMMs geschrieben) sieht erfolgreich aus.

Für den Test brauchst du (ab svn 11457) nur den folgenden Parameter setzen:

Code:
blockemm-g = 1

Dann werden alle global EMMs geblockt. Es spielt dabei keine Rolle, ob der Parameter needsglobalfirst gesetzt ist oder nicht.
 
ok, dann mache ich das mal für 24h und poste morgen abend das ergebnis.
 
also würde das ganze dann so aussehen?

[reader]
label = Local/ORF-ICE_0D98
enable = 1
detect = cd
protocol = mouse
device = /dev/ttyUSB2
caid = 0d98
ident = 0D98:000000,000004,000008,00000C,000010
services = orf_cw
mhz = 358
cardmhz = 358
pincode = none
inactivitytimeout = 1
reconnecttimeout = 30
emmcache = 1,1,2,0
audisabled = 0
au = 1
needsglobalfirst = 1
blockemm-g = 1
lb_weight = 200
group = 3

ich hab z.zt. oscam svn 11505 drauf.
 
Setzte das mal so:

Code:
needsglobalfirst = 0
blockemm-unknown = 1
blockemm-u = 1
blockemm-s = 0
blockemm-g = 1
Danach oscam neu starten und ein paar Tage laufen laufen.
Zwischendurch prüfen, ob sich die Enti's entsprechend verlängern.
 
Richtig, hier auch.
Teste seit gestern Mittag, bis jetzt alles okay. Enti's werden ordungsgemäß verlängert.

Code:
0 / 0 / 51 / 0           0 / 0 / 53 / 0                0 / 36010 / 0 / 0

Edit:
Habe das Thema mal wieder bis zur entgültigen Klärung angepinnt.
 
Zuletzt bearbeitet:
Ich habe es nun über nacht laufen gelassen und es wurden 4 IDs verlängert. 1, 2, FFE0 und 7FFB.

Kann mir jemand sagen für was 7FFB ist? Bei mir steht 30 Tage.
 
bei mir siehts nun so aus:

mouse3788 (100.00 %)0 (0.00 %)0 (0.00 %)0 / 00 / 0 / 0 / 00 / 0 / 11 / 00 / 0 / 24 / 00 / 1832 / 0 / 0

TypeCaidProvidIDClassStart DateExpire DateName
chid0D98000004000000000000FFE0000000002019-04-022019-12-09ORF
chid0D980000040000000000000001000000002019-04-032019-12-10ORF
chid0D980000040000000000000002000000002019-04-032019-12-10ORF
chid0D980000040000000000007FFB000000002019-03-242019-04-23ORF
chid0D98000008000000000000FFE1000000002019-03-302019-12-060D98@000008 unknown
chid0D98000010000000000000FFE3000000002019-04-032019-12-100D98@000010 unknown
chid0D98000010000000000000002A000000002019-04-032019-06-030D98@000010 unknown
chid0D98000010000000000000002B000000002019-04-032019-06-030D98@000010 unknown
chid0D98000010000000000000002C000000002019-04-032019-06-030D98@000010 unknown
chid0D98000010000000000000002D000000002019-04-032019-06-030D98@000010 unknown
chid0D980000100000000000007FF8000000002019-03-202019-04-190D98@000010 unknown
 
Zurück
Oben