4250 replies to this topic

[Erik Slagter]

Ik sta er toch elke keer weer van te kijken hoe een simpele instelling als request_mode zóveel operationele invloed heeft. Daar moet echt een keer opruiming in gehouden worden, zodat die alleen doet wat die moet doen.

Ik verdenk cccam er overigens van het equivalent van request_mode = 1 te doen, waar ik dan ook niet helemaal blij mee ben.

[theparasol]

Hier de diff

Weer wat geleerd!

Attached Files

•  cdsnlpatch.zip   1.14KB   31 downloads

[Erik Slagter]

Diffjes hoeven niet in een zip Het leest veel makkelijker als je die gewoon als code in je bericht zet.

Die eerste patch is exact gelijk aan die van mij, klopt dat? Die tweede is dan inderdaad de besproken code.

Index: module-dvbapi.c
===================================================================
--- module-dvbapi.c (revision 6451)
+++ module-dvbapi.c (working copy)
@@ -606,14 +606,12 @@
  demux[demux_id].pidindex = demux[demux_id].curindex;
 
  for (j=0; j<demux[demux_id].ECMpidcount; j++) {
- if (demux[demux_id].curindex == j || (demux[demux_id].ECMpids[demux[demux_id].curindex].CAID == demux[demux_id].ECMpids[j].CAID
- && demux[demux_id].ECMpids[demux[demux_id].curindex].PROVID == demux[demux_id].ECMpids[j].PROVID
- && demux[demux_id].ECMpids[j].PROVID > 0)) {
-
+ if (demux[demux_id].curindex == j) {
+
  if (demux[demux_id].curindex != j) {
  if (demux[demux_id].ECMpids[j].status < 0 || !demux[demux_id].ECMpids[demux[demux_id].curindex].streams)
  continue;
-
+
  dvbapi_start_filter(demux_id, j, demux[demux_id].ECMpids[j].ECM_PID, 0x80, 0xF0, 3000, TYPE_ECM, 0);
  }

Index: reader-seca.c
===================================================================
--- reader-seca.c (revision 6451)
+++ reader-seca.c (working copy)
@@ -220,10 +220,26 @@
static int32_t seca_do_ecm(struct s_reader * reader, const ECM_REQUEST *er, struct s_ecm_answer *ea)
{
  if (er->ecm[3] == 0x00 && er->ecm[4] == 0x6a) { //provid 006A = CDNL uses seca2/seca3 simulcrypt on same caid
- int ecm_type = er->ecm[1] >> 4; //ecm_type 0 is seca2, ecm_type 3 is seca3
-   int seca_version = reader->availkeys[0][1]; //misusing availkeys to store seca_version
- if ((ecm_type == 0 && seca_version == 3) || (ecm_type == 3 && seca_version == 2))
+ int ecm_type = 0;
+ int seca_version = reader->availkeys[0][1]; //misusing availkeys to store seca_version
+ if (seca_version == 3) { //assume ecm type same as card in reader
+ ecm_type = 3;
+ }
+ if (seca_version == 2) { //assume ecm type same as card in reader
+ ecm_type = 2;
+ }
+ if (er->ecm[8] == 0x00) { //this is a mediaguard 3 ecm request
+ ecm_type = 3;
+ }
+ if (er->ecm[8] == 0x10) { // first seca2 request byte found
+ if (er->ecm[9] == 0x01) {//second seca2 ecmrequest byte found
+ ecm_type = 2;
+ }
+ }
+ if (ecm_type != seca_version){ //only accept ecmrequest for right card!
+ snprintf( ea->msglog, MSGLOGSIZE, "Invalid ecm for card!" );
  return ERROR;
+ }
  }
 
   def_resp;

Edited by Erik Slagter, 25 February 2012 - 11:40.

[Erik Slagter]

Een heleboel qua layout e.d. is kwestie van persoonlijke smaak, maar maak van die twee if's wel even één: if ((er->ecm[8] == 0x10) && (er->ecm[9] == 0x01))

[theparasol]

Ik sta er toch elke keer weer van te kijken hoe een simpele instelling als request_mode zóveel operationele invloed heeft. Daar moet echt een keer opruiming in gehouden worden, zodat die alleen doet wat die moet doen.

Ik verdenk cccam er overigens van het equivalent van request_mode = 1 te doen, waar ik dan ook niet helemaal blij mee ben.

Het is anders wel lekker snel om alles ineens op te vragen. Nadeel is dat als je een card server systeem hebt met meerdere kaarten je die belast met onbedoelde aanvragen.
Je bent voor mijn patch helaas requestmode 1 nodig omdat op de SD kanalen de seca2 ecmpid eerder in de PMT staat.
Als die met requestmode 0 het spul 1 voor 1 afvraagt krijgt hij bij 0100:00006a:seca2 een afwijzing van de reader en slaat hij de 0100:00006a:mediaguard3 over omdat die exact dezelde caid:provid heeft (blacklist!!!!)
Wil het voor simulcrypt goed werken met requestmode 0 zal oscam de blacklist moeten gaan baseren op CAID:PROVID:ECMPID
Dat lijkt me nogal ingrijpend

[mika-nl]

Ik sta er toch elke keer weer van te kijken hoe een simpele instelling als request_mode zóveel operationele invloed heeft. Daar moet echt een keer opruiming in gehouden worden, zodat die alleen doet wat die moet doen.

Ik verdenk cccam er overigens van het equivalent van request_mode = 1 te doen, waar ik dan ook niet helemaal blij mee ben.

Het is anders wel lekker snel om alles ineens op te vragen. Nadeel is dat als je een card server systeem hebt met meerdere kaarten je die belast met onbedoelde aanvragen.
Je bent voor mijn patch helaas requestmode 1 nodig omdat op de SD kanalen de seca2 ecmpid eerder in de PMT staat.
Als die met requestmode 0 het spul 1 voor 1 afvraagt krijgt hij bij 0100:00006a:seca2 een afwijzing van de reader en slaat hij de 0100:00006a:mediaguard3 over omdat die exact dezelde caid:provid heeft (blacklist!!!!)
Wil het voor simulcrypt goed werken met requestmode 0 zal oscam de blacklist moeten gaan baseren op CAID:PROVID:ECMPID
Dat lijkt me nogal ingrijpend

Zijn hier mee ook de MTV live HD en VH1 problemen over ?
die zappen namelijk erg traag.
Lijkt wel of hij niks doet met sommige I: regels

dvbapiau (0100&000084/6FF0/64:59C9): timeout (9801 ms) - VH1
en in de dvapi staat I: 0100:000084

MiKa

Edited by mika-nl, 25 February 2012 - 11:59.

[theparasol]

Een heleboel qua layout e.d. is kwestie van persoonlijke smaak, maar maak van die twee if's wel even één: if ((er->ecm[8] == 0x10) && (er->ecm[9] == 0x01))

Is gekomen omdat het kreng nog niet deed wat ik wilde, heb toen uiteindelijk complete if blocken gemaakt met text output van de variabelen om de boel te bewaken.
Mijn eerste code was veel eenvoudiger en efficienter.

Omdat ik jouw input van tijdje terug mbt dvbapi gelezen had heb ik daar ook zitten speuren en onafhankelijk van jou uiteindelijk *exact* dezelfde aanpassing gemaakt.
Dat was de "key" om het correct te laten werken.

Ben zo'n beetje de hele nacht bezig geweest vooral worstelend met het "lezen" van de C++ code, editten,compilen,testen en als het niet werkte mezelf afvragend of ik wat ik wilde wel in correcte C++ code vertaald had. Ik mis vooral debug functie. Liefst ga ik "single" step door de code waarbij ik continue de variablen kan inspecteren en de if en for conditions.

Blijf het toch leuk vinden dat coden, zelfs dat SVN verhaal met diffs ed begin ik nu onder de knie te krijgen

[theparasol]

Zijn hier mee ook de MTV live HD en VH1 problemen over ?
die zappen namelijk erg traag.
Lijkt wel of hij niks doet met sommige I: regels

dvbapiau (0100&000084/6FF0/64:59C9): timeout (9801 ms) - VH1
en in de dvapi staat I: 0100:000084

Een logje van VH1 met mijn aangepaste oscam:

2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 0] CAID: 0B00   ECM_PID: 07C6   PROVID: 000000
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 1] CAID: 0100   ECM_PID: 04C2   PROVID: 000084
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 2] CAID: 0100   ECM_PID: 17EE   PROVID: 004106
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 3] CAID: 0100   ECM_PID: 179D   PROVID: 000085
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 4] CAID: 0100   ECM_PID: 1911   PROVID: 00006A
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 5] CAID: 0100   ECM_PID: 191B   PROVID: 00006C
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 6] CAID: 0100   ECM_PID: 1925   PROVID: 00006D
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 7] CAID: 0D00   ECM_PID: 04C1   PROVID: 000000
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 8] CAID: 1810   ECM_PID: 17EA   PROVID: 000000
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 9] CAID: 0500   ECM_PID: 1B5D   PROVID: 042500
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 10] CAID: 0D05  ECM_PID: 17D9   PROVID: 000000
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 11] CAID: 1817  ECM_PID: 1911   PROVID: 00006A
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 12] CAID: 1818  ECM_PID: 191B   PROVID: 00006C
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 13] CAID: 1819  ECM_PID: 1925   PROVID: 00006D
2012/02/25 12:04:42   59F2F8 c dvbapi: [ADD PID 14] CAID: 0500  ECM_PID: 1FAA   PROVID: 050600
2012/02/25 12:04:42   59F2F8 c dvbapi: new program number: 6FF0 (0B00:6FF0 unknown)
2012/02/25 12:04:42   59F2F8 c lokaal (0D05&000010/6FF0/9C:58FB): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (1817&00006A/6FF0/64:6E14): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (1818&00006C/6FF0/64:9CF0): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (1819&00006D/6FF0/64:FA30): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (0100&000084/6FF0/64:BDB7): not found (10 ms) by kaartlezer  (provider not found)
2012/02/25 12:04:42   59F2F8 c lokaal (0100&000085/6FF0/64:9F72): not found (11 ms) by kaartlezer  (provider not found)
2012/02/25 12:04:42   59F2F8 c lokaal (0D00&000010/6FF0/B4:2DFB): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (0B00&000000/6FF0/67:3EED): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (1810&000000/6FF0/89:D2F6): rejected group (1 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (0500&042500/6FF0/47:59D8): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c lokaal (0500&050600/6FF0/6C:106E): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:42   59F2F8 c dvbapi: Start descrambling PID #4 (CAID: 0100) 1
2012/02/25 12:04:42   59F2F8 c lokaal (0100&00006A/6FF0/64:6E14): found (282 ms) by kaartlezer
2012/02/25 12:04:42   59F2F8 c lokaal (0100&00006C/6FF0/64:9CF0): not found (294 ms) by kaartlezer  (provider not found)
2012/02/25 12:04:42   59F2F8 c lokaal (0100&00006D/6FF0/64:FA30): not found (294 ms) by kaartlezer  (provider not found)
2012/02/25 12:04:42   59F2F8 c lokaal (0100&004106/6FF0/64:E1ED): not found (258 ms) by kaartlezer  (provider not found)
2012/02/25 12:04:44   59F2F8 c lokaal (1817&00006A/6FF0/64:64AD): rejected group (0 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:44   59F2F8 c dvbapi: Start descrambling PID #4 (CAID: 0100) 1
2012/02/25 12:04:44   59F2F8 c lokaal (0100&00006A/6FF0/64:64AD): found (267 ms) by kaartlezer
2012/02/25 12:04:54   59F2F8 c lokaal (1817&00006A/6FF0/64:DC45): rejected group (1 ms) (0 of 0) (no matching reader)
2012/02/25 12:04:54   59F2F8 c lokaal (0100&00006A/6FF0/64:DC45): found (265 ms) by kaartlezer
2012/02/25 12:05:03   59F2F8 c lokaal (1817&00006A/6FF0/64:E031): rejected group (1 ms) (0 of 0) (no matching reader)
2012/02/25 12:05:03   59F2F8 c lokaal (0100&00006A/6FF0/64:E031): found (266 ms) by kaartlezer

Opent vlot, net als de andere kanalen (lege oscam.dvbapi, loadbalancer disabled, dvb requestmode 1, mijn aangepaste oscam)

MTV Live HD kan ik niet testen, geen HD abbo (per half maart wel!)

[Erik Slagter]

Het is anders wel lekker snel om alles ineens op te vragen. Nadeel is dat als je een card server systeem hebt met meerdere kaarten je die belast met onbedoelde aanvragen.

Nou, ik dacht meer aan je internetaansluiting .

Je bent voor mijn patch helaas requestmode 1 nodig omdat op de SD kanalen de seca2 ecmpid eerder in de PMT staat.

Het zou met request mode 0 dan toch ook moeten werken, zij het dan met een kleine vertraging? Dat was volgens mij de hele insteek van de originele patch van marley. De reader geeft een "not found" terug, zodat de dvbapi meteen de volgende caid kan proberen.

Als die met requestmode 0 het spul 1 voor 1 afvraagt krijgt hij bij 0100:00006a:seca2 een afwijzing van de reader en slaat hij de 0100:00006a:mediaguard3 over omdat die exact dezelde caid:provid heeft (blacklist!!!!)

Ah op die manier. Oscam kan principieel niet omgaan met meerdere ecm's met dezelfde caid:provid, dat is duidelijk. Misschien moeten we toch weer eens gaan klooien met die M:apping naar 1817, dan heb je in ieder geval niet dat probleem. Waar je alleen volgens mij tegen aan loopt is dat de reader uiteindelijk, ook vanwege emms, de kaart toch als 100:6a ziet. Je zou die in z'n geheel moeten kunnen mappen naar 1817. De ecm's voor 1817 en 100:6a (nagra) zijn exact gelijk, die kun je dus gewoon aan je kaart voeren, bij een nagra kaart.

Wil het voor simulcrypt goed werken met requestmode 0 zal oscam de blacklist moeten gaan baseren op CAID:PROVID:ECMPID
Dat lijkt me nogal ingrijpend

Dat zou ook kunnen. Hoe dan ook, de methode die M7 hanteert is niet zo handig voor softcams, misschien wel expres zo bedacht.

[Erik Slagter]

Er was iets met M:appings, die werkten dan toch ook juist weer niet in request_mode 0? Vaag hoor.

Er is wel een instelling bij een reader, zag ik, die suggereert dat je daar specifiek voor die reader ook een mapping kunt instellen.

[Erik Slagter]

Hier, had je daar al eens mee geexperimenteerd?

caid

parameter is optional

caid = <CAID>[&<mask>][:<target CAID>][,<CAID>[&<mask>][:target <CAID>]]...

define and mapping of CAIDs for reader, default:all CAIDs with mask FFFF

example:

caid = 0100
caid = 0200&ffee:0300
caid = 0400&ff00:0500,0600
caid = 0702,0722
caid = 0702&ffdf (shortcut for the example above)

Edited by Erik Slagter, 25 February 2012 - 12:20.

[Erik Slagter]

Dan kun je 100:6a weer gewoon compleet negeren met je nagra kaart!

[Erik Slagter]

Dat was de "key" om het correct te laten werken.

Begrijp jij nou wat de bedoeling van die code is? Eerst selecteer je aan de hand van allerlei regels (dvbapi, config, etc) een ecm pid, vervolgens ga je alle ecm pids aflopen en pak je de eerste die dezelfde caid:provid heeft. Dat is toch gewoon fout?

Ik mis vooral debug functie. Liefst ga ik "single" step door de code waarbij ik continue de variablen kan inspecteren en de if en for conditions.

Watje

Blijf het toch leuk vinden dat coden, zelfs dat SVN verhaal met diffs ed begin ik nu onder de knie te krijgen

Snap je straks git, moet je git weer leren (had ik last van...). Git is echt heel anders, maar wel heel mooi. Bij svn loop ik altijd te klooien om de patchset bij een bepaalde log entry boven water te krijgen, iets met svn diff -r6408:6409 en dat kan dan ook even duren. Bij git zeg je gewoon git show <id> waar <id> de log entry is (nou ja niet helemaal, maar wel het getal daar dus).

[theparasol]

Er was iets met M:appings, die werkten dan toch ook juist weer niet in request_mode 0? Vaag hoor.

Volgensmij om exact dezelfde reden. Je maakt dan via de mapping nog een extra 0100:00006A aan. Een afwijzing van een 0100:00006a aanvraag en het gaat fout.
Dat omzeil je met requestmode 1.

[theparasol]

Dan kun je 100:6a weer gewoon compleet negeren met je nagra kaart!

Komt het dan nog wel goed met emm updates?

De boel negeren, dat konden we altijd al maar de insteek was een auto seca2/mediaguard dvbapi zonder een ingewikkelde oscam.dvbapi

[Erik Slagter]

Dan is die mapping op het verkeerde niveau geimplementeerd

Ik had gehoopt dat hij de vertaling naar 100:6a op het allerlaatste moment zou kunnen doen, bij het aanbieden aan de fysieke kaart, vandaar ook dat ik dat stukje had aangehaald. We kunnen het in ieder geval even proberen...

[Erik Slagter]

Komt het dan nog wel goed met emm updates?

Waarschijnlijk niet Had ik ook al bedacht. Maar desnoods zet je dat eens in de twee maanden even om, of "patchen" we dat ook even.

[Erik Slagter]

Maar ik vind een mapping 100:6a -> 1817 in oscam.dvbapi, als dat goed werkt, op zich een nette oplossing.

[littlesat]

CAID:PROVID:ECMPID

Als je het echt goed doet dan neem je CAID:PROVID:SID:ECMPID.... dus 4 dingen.. Zover ik kan overzien doet Oscam heel veel met CAID en SID alleen (dus niet eens met de PROVID erbij)... dus dat wordt nog aangrijpener....

[theparasol]

Dat was de "key" om het correct te laten werken.

Begrijp jij nou wat de bedoeling van die code is? Eerst selecteer je aan de hand van allerlei regels (dvbapi, config, etc) een ecm pid, vervolgens ga je alle ecm pids aflopen en pak je de eerste die dezelfde caid:provid heeft. Dat is toch gewoon fout?

Het foute eraan is dat hij 1 een run twee filterpids maakt en vervolgens dus de mediaguard3 en seca2 ecmpid request.
De reader met mediaguard3 kaart replied een correct controlword maar direct daarop komt ook de 0000000 controlword tgv seca2 invalid ecm request terug en die wordt ook gewoon doorgegeven aan de tuner. Gevolg: alsnog zwart beeld.
Door het strippen van die condition in oscam.dvbapi vraagt hij efficient geen 2 ecms tegelijk meer op in geval van cds simulcrypt en komt dus ook die 000000 controlword niet meer door.
Ik durf zelfs te stellen dat die hele reader-seca.c aanpassing overbodig is en de dvbapi aanpassing an sich al voldoende is om het te laten werken.

Ik snap alleen net als jij ook niet waarom ze die extra condition in dvbapi gezet hebben. Het lijkt wel alsof iemand dat express gedaan heeft om CDS gebruikers het gebruik van oscam lastig te maken.