4250 replies to this topic

[deleted]

9.61Mhz toch maar even geprobeerd, zie hier het resultaat:

9.61Mhz - ECM 240à250ms
8.00Mhz - ECM 250à260ms
6.86Mhz - ECM 260à270ms
4.80Mhz - ECM 300à310ms
3.20Mhz - ECM 330à340ms

Van wat ik gelezen heb, aangezien ons seca3 kaartje eigenlijk een nagra kaartje is zou 8 of 10Mhz geen probleem mogen zijn????
Ik weet wel niet wat het op lange termijn gaat doen....

En wat denken jullie, op naar de 12Mhz?

[rytec]

de mhz, en een smargo smartreader

In Oscam op Ubuntu server met smartreader Mhz 480 en cardmhz 357 draait prima

[mysat]

En wat wil jij? Wat voor een probleem heb je dan? Wees eens duidelijk!

Seca2 en Irdeto2 hebben sowiezo geen probleem.

"Kaartje" omruilen? Waarom dan?

Mijn SECA2 draait als een tierellier in een DM800 (net zoals TVV en TNTSAT). Indien ik de kaarten centraal in een server steek, doet ze het allemaal prima, behalve de SECA2 C+ kaart. Ik zie wel de entitlements in Oscam (server kant natuurlijk), maar krijg constant het antwoord "not found" terug. Gek dat ie het dus wel doet i.c.m oscam.dvdapi maar aan de serverkant in een smargo het nog niet doet....

Indien dit een bug met low prio zou zijn, zou ik wel overwegen om de kaart om te ruilen omdat ik de indruk heb dat een SECA3 het wel in een server doet

Edited by mysat, 6 February 2012 - 17:55.

[christophecvr]

Aangaande clockspeed and ecm time.

Het tabelletje van Ocram klopt.

Maar hoewel de ecm times korter zijn met hogere klockspeed, duurt het soms langer bij zappen. Ook ontstaan er af en toe meer not ok ecm's bij de hogere snelheden.

na zeer vele testen heb ik vastgesteld dat de seca3 (of nagra tunneled seca) kaart het beste werkt met 480. je kan 500 500 zetten, dan neemt hij 480 effectief.

Dit is nu ook net de standaard speed van dat type kaart lijkt mij daarom geen toeval.

Indien je niets zet neem oscam nu 480 480 voor deze kaart. Werkt perfect.

Eric heeft naar mijn mening gelijk.

Een viacces 4 kaart werkt het beste met 800 800 in smartreader. op pc.
Als je met een pcsc reader werkt kan je geen speed zetten. De viaccess in ominkey pcsc reader geeft echter ecm times die overeenstemmen met 800 800 op smartreader.
In een smartreader werkt deze kaart het best met 800 800 off 600 600. Als je niets zet neemt hij echter 347 bij viaccess in smartreader en dat werkt maar niet zo goed voor die kaart.

Edited by christophecvr, 6 February 2012 - 18:41.

[theparasol]

Mijn SECA2 draait als een tierellier in een DM800 (net zoals TVV en TNTSAT). Indien ik de kaarten centraal in een server steek, doet ze het allemaal prima, behalve de SECA2 C+ kaart. Ik zie wel de entitlements in Oscam (server kant natuurlijk), maar krijg constant het antwoord "not found" terug. Gek dat ie het dus wel doet i.c.m oscam.dvdapi maar aan de serverkant in een smargo het nog niet doet....

Indien dit een bug met low prio zou zijn, zou ik wel overwegen om de kaart om te ruilen omdat ik de indruk heb dat een SECA3 het wel in een server doet

Dat maakt het wat duidelijker. Kan het zijn dat je clients wellicht geen seca2 ecm's aanvragen bij de seca2 reader maar seca3 ecm's?
Dan zou je met een whitelist voor seca2 moeten gaan werken maar dan komt je seca3 weer in de knoei.

[theparasol]

@Bas: Ik heb even wat "clients" die de server als share gebruiken bijgeschakelt en het spulletje werkt zoals het hoort op mijn dm800HD PVR.
Ik krijg ook meldingen in de oscam log dat er actief ecm aanvragen >4 per 15 secs geblocked worden ttv de cooldown time
Bij mijn reader heb ik volgende momenteel toegevoegd:

ratelimitecm = 4
ratelimitseconds = 15
cooldown= 50,120

Wellicht wil iemand anders dit eens "onafhankelijk" proberen.

[theparasol]

Hier even een hap uit de source met actuele cooldown code gedeelte (oscam-reader.c), ik zie hier totaal geen aanleiding dat de share gaat haperen.

Ja, haperen uiteraard indien er meer dan de limiet aan ecm's aan de reader in cooldown gevraagd wordt. Maar dat is nog altijd beter dan een kaart in de M7 penalty stand
Cooldown zonder gebruik van ecmratelimit en ecmratelimitseconds parameters is natuurlijk geen goed geconfigureerd geheel dus zorg dat alle 3 de parameters erin zitten.

#ifdef WITH_CARDREADER
 if (reader->cooldown[0] && reader->ratelimitecm){
  if (!reader->cooldowntime)
   reader->cooldowntime = time((time_t*)0);
  time_t now = time((time_t*)0);
  if (reader->cooldownstate == 1) {
   if (now - reader->cooldowntime >= reader->cooldown[1]) {
	reader->cooldownstate = 0;
	reader->cooldowntime = now;
	cs_log("%s cooldown OFF", reader->label);
   }
  } else {
   if (now - reader->cooldowntime >= reader->cooldown[0]) {
	reader->cooldownstate = 1;
	reader->cooldowntime = now;
	cs_log("%s cooldown ON", reader->label);
   }
  }
 }
 if ((reader->ratelimitecm && !reader->cooldown[0]) || reader->cooldownstate == 1 ) {
  cs_debug_mask(D_READER, "ratelimit idx:%d rc:%d caid:%04X srvid:%04X",er->idx,er->rc,er->caid,er->srvid);
  int32_t foundspace=-1;
  int32_t h;
  for (h=0;h<reader->ratelimitecm;h++) {
   if (reader->rlecmh[h].srvid == er->srvid) {
	foundspace=h;
	cs_debug_mask(D_READER, "ratelimit found srvid in use at pos: %d",h);
	break;
   }
  }
  if (foundspace<0) {
   for (h=0;h<reader->ratelimitecm;h++) {
	if ((reader->rlecmh[h].last ==- 1) || ((time(NULL)-reader->rlecmh[h].last) > reader->ratelimitseconds)) {
	 foundspace=h;
	 cs_debug_mask(D_READER, "ratelimit found space at pos: %d old seconds %ld",h,reader->rlecmh[h].last);
	 break;
	}
   }
  }
  #ifdef HAVE_DVBAPI
  //overide ratelimit priority for dvbapi request
  if ((foundspace < 0) && (cfg.dvbapi_enabled == 1) && (strcmp(er->client->account->usr,cfg.dvbapi_usr) == 0)) {
   if(reader->lastdvbapirateoverride < time(NULL) - reader->ratelimitseconds){
	time_t minecmtime = time(NULL);   
	for (h=0;h<reader->ratelimitecm;h++) {
	 if(reader->rlecmh[h].last < minecmtime){
	  foundspace = h;
	  minecmtime = reader->rlecmh[h].last;
	 }
	}
	reader->lastdvbapirateoverride = time(NULL);
	cs_debug_mask(D_READER, "Prioritizing DVBAPI User %s over other watching client on reader %s.",er->client->account->usr, reader->label);
   } else cs_debug_mask(D_READER, "DVBAPI User %s is switching too fast for ratelimit and can't be prioritized on reader %s.",er->client->account->usr, reader->label);
  }
  #endif
  
  if (foundspace<0) {
   //drop
   cs_debug_mask(D_READER, "ratelimit could not find space for srvid %04X. Dropping.",er->srvid);
   write_ecm_answer(reader, er, E_NOTFOUND, E2_RATELIMIT, NULL, "ECMratelimit no space for srvid");
   return;
  } else {
   reader->rlecmh[foundspace].last=time(NULL);
   reader->rlecmh[foundspace].srvid=er->srvid;
  }
 }
 cs_ddump_mask(D_ATR, er->ecm, er->l, "ecm:");
 struct timeb tps, tpe;
 cs_ftime(&tps);
 struct s_ecm_answer ea;
 memset(&ea, 0, sizeof(struct s_ecm_answer));
 int32_t rc = reader_ecm(reader, er, &ea);
 if(rc == ERROR){
  char buf[32];
  cs_log("Error processing ecm for caid %04X, srvid %04X (servicename: %s) on reader %s.", er->caid, er->srvid, get_servicename(cl, er->srvid, er->caid, buf), reader->label);
  ea.rc = E_NOTFOUND;
 } else
  ea.rc = E_FOUND;
 cs_ftime(&tpe);
 cl->lastecm=time((time_t*)0);
 cs_debug_mask(D_TRACE, "reader: %s ecm: %04X real time: %ld ms", reader->label, htons(er->checksum), 1000*(tpe.time-tps.time)+tpe.millitm-tps.millitm);
 write_ecm_answer(reader, er, ea.rc, 0, ea.cw, ea.msglog);
 reader_post_process(reader);
#endif

[mysat]

Mijn SECA2 draait als een tierellier in een DM800 (net zoals TVV en TNTSAT). Indien ik de kaarten centraal in een server steek, doet ze het allemaal prima, behalve de SECA2 C+ kaart. Ik zie wel de entitlements in Oscam (server kant natuurlijk), maar krijg constant het antwoord "not found" terug. Gek dat ie het dus wel doet i.c.m oscam.dvdapi maar aan de serverkant in een smargo het nog niet doet....

Indien dit een bug met low prio zou zijn, zou ik wel overwegen om de kaart om te ruilen omdat ik de indruk heb dat een SECA3 het wel in een server doet

Dat maakt het wat duidelijker. Kan het zijn dat je clients wellicht geen seca2 ecm's aanvragen bij de seca2 reader maar seca3 ecm's?
Dan zou je met een whitelist voor seca2 moeten gaan werken maar dan komt je seca3 weer in de knoei.

Is dan de conclusie dat een seca3 hier alleen de degelijke oplossing biedt juist ? (los van het feit dat ik natuurlijk die whitelist functionaliteit nu verder ga uitzoeken). Heeft iemand deze kaart (C+ NL SECA2) überhaupt werkend in een server met readers ? Of ben ik de eerste met dit probleem. Leuk dan dat ik de onmogelijkheden van server sharing voor deze toko dan openlijk documenteer.....Daar wil ik dan wel $$$ voor hebben

[polarbear]

@Bas: Ik heb even wat "clients" die de server als share gebruiken bijgeschakelt en het spulletje werkt zoals het hoort op mijn dm800HD PVR.
Ik krijg ook meldingen in de oscam log dat er actief ecm aanvragen >4 per 15 secs geblocked worden ttv de cooldown time
Bij mijn reader heb ik volgende momenteel toegevoegd:

ratelimitecm = 4
ratelimitseconds = 15
cooldown= 50,120

Wellicht wil iemand anders dit eens "onafhankelijk" proberen.

Ik verbaas me over jullie serieuze inzet, edoch met al het positivisme denk ik dat vooralsnog de eerste stap zou moeten zijn om het exacte algoritme van de ecm-beperking boven water te krijgen.
Alleen dan kun je adequaat hierop reageren en parameters binnen oscam goed instellen.
Ik lees limieten van 4/10 of 3/10, 4/15 en cooldowns van hoog naar laag. Ik denk dat je in een cirkeltje draait en, met alle respect, helaas zo geen steek verder komt.

Voorstel: Bouw als test een soort van autozap-script op enigma2 met in te stellen pauze en zap-tijden en test dan met een minimum van 3 of 4 enigmaboxen op 1 kaart. Probeer dan daarmee vast te stellen wanneer en hoe de ecm-overflow-penalty in werking komt. Ik acht jullie best daartoe in staat. Zelf heb ik helaas te weinig actuele programmeerkennis.
Iedereen probeert nu iets, maar zonder enige lijn blijf je volgens mij zo jaren bezig.
Polarbear

[theparasol]

Zo ingewikkelt is het allemaal niet, dus jaren moet meer iets van dagen zijn:

Het aantal van 4 moet correct zijn (gezien aantal terugkoppelingen op diverse fora dat dit werkt)
Alleen de tijdsbestek waarin dit duurzaam afgenomen kan worden moet bepaald worden. Dit moet een waarde ergens tussen de 10 en de 15 seconden zijn.
De cooldown moet in te zetten zijn als zap-burster oftewel als onbeperkt momentum. Er moet een sprake zijn van een korte periode waarin dit toegestaan is en daarna moet er een periode zijn van duurzaam maximaal 4 ecm's afnemen per die 10-15 seconden.
Ik verwacht dat als de ratelimitseconds op 15 staat je sowiezo in de veilige zone zit met 4 ecms. Daarna is het proefondervindelijk verhogen/verlagen cooldown waardes.

Een autozappert werkt niet, immers als je kaart in de penalty mode schiet moet je hem er met de hand weer uithalen door 1 ecm gedurende periode straftijd te vragen weer te unlocken.

4 "clients" die duurzaam de veilige 4 ecms blijven afnemen zorgen voor de benodigde standaard load, als die duurzaam goed gaan heb je de ratelimitecm en ratelimitecmtijd goed.
Daarna is het kwestie van 1 client erbij schakelen om de cooldown waardes experimenteel vast te stellen.

Uit de reacties op diverse fora lijkt het erop dat een ecm aanvraag aan de kaart die een "not found" oplevert ook meegenomen wordt als een ecm voor de max van 4. Het is dus zaak om de services correct te zetten op de reader zodat kaart niet onnodig een extra ecm tik krijgt die bij voorbaat toch al niets oplevert.

[polarbear]

Het aantal van 4 moet correct zijn (gezien aantal terugkoppelingen op diverse fora dat dit werkt)
Alleen de tijdsbestek waarin dit duurzaam afgenomen kan worden moet bepaald worden. Dit moet een waarde ergens tussen de 10 en de 15 seconden zijn.

Dat ben ik absoluut niet met je eens, omdat de ecm-lifecycle-time ongeveer (misschien zelfs wel exact) 10.00 seconden bedraagt. Dus wanneer je 4 clients op 1 kaart hebt, dan heb je genoeg aan 4 sids/10 seconden, maar dan mag er geeneen gaan zappen. Als er toch 1 zapt, wordt het logischerwijs gesproken: 5 sids gevraagd /10 seconden en gaat er dus minimaal 1 van de clients haperen bij een instelling van 4/10 door de beperking die is ingesteld in oscam. Hoe het zit met de daadwerkelijke penalty van de card staat hier helemaal los van en dat is ook wat ik nu juist bedoel met "je moet het algoritme boven water krijgen".
Ik heb in de praktijk gemerkt dat 4/10 niet werkt bij 4 clients op 1 kaart, hij gaat dan na ongeveer 20 minuten stotteren, maar ook geen 3/10 en ook geen 4 /15, kortom je kunt in de praktijk niet meer dan 3 clients per kaart kwijt zonder problemen. Maar dat is natuurlijk wel iets heel anders dan eindeloos constant 4 sids vragen van je kaart. Dat zal geen enkel probleem opleveren. Dus laten we eerst eens onderscheid maken tussen het aantal clients dat we op een kaart zetten, of het aantal sids dat we van de kaart vragen!

[theparasol]

Ik snap wat je bedoelt: 4 clients vertonen ander gedrag dan duurzaam 4 ecm's per tijdsinterval opvragen. Als er idd 1 of meer gaan zappen gaat de boel uiteindelijk stotteren.
Maar efficient vraag je dan per tijdsinterval meer dan 4 ecm's op.
Vraagje: hoe herken je dat stotteren? Zwart beeld op 1 van de clients? Of op alle clients duurzaam zwart?

[polarbear]

Ik snap wat je bedoelt: 4 clients vertonen ander gedrag dan duurzaam 4 ecm's per tijdsinterval opvragen. Als er idd 1 of meer gaan zappen gaat de boel uiteindelijk stotteren.
Maar efficient vraag je dan per tijdsinterval meer dan 4 ecm's op.
Vraagje: hoe herken je dat stotteren? Zwart beeld op 1 van de clients? Of op alle clients duurzaam zwart?

Morgen meer..Het is me nu te laat.

[polarbear]

Ik snap wat je bedoelt: 4 clients vertonen ander gedrag dan duurzaam 4 ecm's per tijdsinterval opvragen. Als er idd 1 of meer gaan zappen gaat de boel uiteindelijk stotteren.
Maar efficient vraag je dan per tijdsinterval meer dan 4 ecm's op.
Vraagje: hoe herken je dat stotteren? Zwart beeld op 1 van de clients? Of op alle clients duurzaam zwart?

Ik probeer met alle middelen bij de clients "zwart" te voorkomen. In mijn zoektocht ben ik daarmee niet verder gekomen dan maximaal 3 normale tv-kijkers per kaart. Doe je er meer,dan gaat de boel inderdaad na verloop van tijd op op zwart, ofwel door de ingestelde oscam beperkingen, ofwel door de card-penalty. Je zult dus naast het onderscheid tussen clients/kaart of aantal sids/kaart ook nog onderscheid moeten maken tussen kijken (en dus af en toe zappen) of alleen opnemen en dus uitsluitend 1 sid vragen gedurende een lange tijd. En ik mis dat hier in alle tot dusver gedane tests.

Indien je minder dan, laten we zeggen 6 a 7 MG-3 kaarten (oranje) ter beschikking hebt lijkt het me alleen haalbaar om uit te gaan van clients/kaart. Bij 3 clients/kaart kun je in dat geval overwegen om loadbalancing in te stellen. Echter hoe minder kaarten, hoe groter de kans dat alle "plekken" bezet zijn (prime time-alle clients kijken tv en ook nog eens naar verschillende zenders) Wil je toch gegarandeerd beeld moet je dus deze waardes niet overschrijden.
Toch moet er bijna meer inzitten dan 3 clients/kaart. Laten we zeggen bijvoorbeeld 3.5 client per kaart. Als je dan 2 kaarten hebt zou je er in theorie bijvoorbeeld 7 gebruikers op kunnen laten lopen, Echter ik heb gemerkt dat de overgang van zo'n 7e client van kaart a naar kaart b ook met loadbalancing -voor deze client - niet helemaal soepel verloopt. Als je met usergroepen werkt /kaart, dus usergroep 1 (3clients) op kaart 1, usergroep 2 (3 clients) op kaart 2, enzovoort zie ik nog iets anders, nl binnen de usergroep/kaart combinatie wordt wel gecached, maar daarbuiten niet! Dus groep 1 maakt geen gebruik van de cache van groep2. en dat is weer heel jammer. Let wel, het gaat hier om slechts 1 instance van oscam, intern sharen!! Weet iemand hoe het toch mogelijk is om de caching zo in te stellen dat groep 1 users CW's uit de cache van groep 2 users kunnen halen?

[Erik Slagter]

Ik probeer met alle middelen bij de clients "zwart" te voorkomen. In mijn zoektocht ben ik daarmee niet verder gekomen dan maximaal 3 normale tv-kijkers per kaart. Doe je er meer,dan gaat de boel inderdaad na verloop van tijd op op zwart, ofwel door de ingestelde oscam beperkingen, ofwel door de card-penalty.

Precies mijn ervaring. Zodra ik limiteer op vier gaat het fout, hoe dan ook. Maar volgens mij zijn er nogal wat mensen die hetzelfde ervaren btw. Ik heb zelfs CCcam uit de (stoffige) kast gehaald en daar ervaar ik dat óók mee (tot zover de opmerking die ik wel eens lees dat het allemaal "fout" is geimplementeerd in oscam).

[doglover]

Heb CCcam 2.3.0 in gebruik met de SID limiet van 4 11 en hier kon ik continue 4 SID's mee opvragen zonder dat er iets gaat stotteren of op zwart gaat.
bv. 3 opnames en zappen met de 4 de. Of 4 opnames (heb een VU+ duo en DM7025 - intern geshared)

Met Oscam is mij dit nog niet gelukt. Vanaf dat ik een vierde opname start (of een vierde zender aanspreek) krijg ik haperingen of zwart beeld (Vooral haperingen)

Willy

[Erik Slagter]

Het is mij, zoals ik al schreef, nog niet gelukt mijn schoonouders, als ze komen oppassen, een hele avond van ongestoorde televisie te voorzien, noch met CCcam, noch met Oscam (waarbij sid limit = 4, tijdwaardes diverse). Vaak lopen er dan twee, soms drie opnames en dan gaat het gewoon fout, beeld een kwartier tot een half uur zwart... Da's niet de cam....

[polarbear]

Heb CCcam 2.3.0 in gebruik met de SID limiet van 4 11 en hier kon ik continue 4 SID's mee opvragen zonder dat er iets gaat stotteren of op zwart gaat.
bv. 3 opnames en zappen met de 4 de. Of 4 opnames (heb een VU+ duo en DM7025 - intern geshared)

Met Oscam is mij dit nog niet gelukt. Vanaf dat ik een vierde opname start (of een vierde zender aanspreek) krijg ik haperingen of zwart beeld (Vooral haperingen)

Willy

Ook hier weer: Maak een duidelijk onderscheid tussen normaal tv-kijken en opnames. Dit zijn wezenlijk 2 verschillende dingen.
Een tv-kijker zapt nu eenmaal af en toe; een opname doet dat niet !!!!

[christophecvr]

@Polarbear

Dat van die groepen is zo en is ook bedoeling.
Bij mij heeft elke reader andere group. Dan heb je véél flexibiliteit.
Maar het is logisch dat de cache ook wordt uitgebklokt zo.

Wat je zou kunnen doen is voor de client 2 users maken .

vb locale reader 1 group1 en locale reader 2 group2

vb client 1
User client1 naar group 1 (enkel)
User cleint1cache naar group 1 en 2 maar met cacheex = 1 (zal enkel cached ecm's kunnun gebruiken)

vb client 2
User client2 naar group 2 (enkel)
User client2cache naar group 1 en 2 maar met cacheex= 1 (zal enkel cached ecm's kunnen gebruiken)

[polarbear]

@Polarbear

Dat van die groepen is zo en is ook bedoeling.
Bij mij heeft elke reader andere group. Dan heb je véél flexibiliteit.
Maar het is logisch dat de cache ook wordt uitgebklokt zo.

Wat je zou kunnen doen is voor de client 2 users maken .

vb locale reader 1 group1 en locale reader 2 group2

vb client 1
User client1 naar group 1 (enkel)
User cleint1cache naar group 1 en 2 maar met cacheex = 1 (zal enkel cached ecm's kunnun gebruiken)

vb client 2
User client2 naar group 2 (enkel)
User client2cache naar group 1 en 2 maar met cacheex= 1 (zal enkel cached ecm's kunnen gebruiken)

Thats a good one, nog niet aan gedacht.... Ga ik vandaag in de loop van de dag nog proberen.

Bedankt voor de tip.