131 replies to this topic

[HPPli]

Het bleek dat er stiekem heel wat meer ecms aangevraagd werden en de kaart noteerde er dan extra strafpuntjes voor.

Dit weet ik al langer....
Maar dus eigenlijk is deze fix een soort symptoom bestreiding ipv de echte oorzaak aan te pakken...

Wat moet je anders, gelijk jullie maken toch ook vele patches (gelukkig) om de VU+DUO nog steeds aan de praat te houden ????
Terwijl VU+ ( de veroorzaker dus) simpel deze patches/symptoom bestrijding van jullie kunnen oplossen door de Drivers aan te passen,
maar die (VU+) reageren niet en/of moeizaam. .............. Laat dat nu net bij CD ook het geval zijn.

[HPPli]

En op die 'extra' ecm's komt nu geen antwoord meer, dus nog steeds zwarte opnames.

Heb dit nog niet ervaren en/of gemerkt. Waarom denk je dit ?

[littlesat]

En op die 'extra' ecm's komt nu geen antwoord meer, dus nog steeds zwarte opnames.

Of niet... als die extra ECMs door een bug veroorzaakt worden en zo wie zo een NOK opleveren... Ach ja... dan gaat juist de goede ECM binnen dat tijdsslot op zwart

Edited by littlesat, 28 February 2013 - 12:39.

[theparasol]

Weer een update erbij:

http://www.streamboa.../changeset/8444

Nu alles flexibel ingesteld en kapen van slots kan nu ook voorkomen worden.

De truuk met de ecm is relatief eenvoudig. In een klein lan share netwerkje heb je bv 4 boxen staan en in 1 box zit een kaart.
Nu lopen die boxjes lang niet allemaal in de maat. Box 1 vraagt op moment a een ecm aan, box 2 op moment b, box 3 op moment c, box 4 op moment d.
De controlword cycle is 10 seconden. Als box 1 een ecm stuurt en box 2 een ecm stuurt maar een seconde later, box 3 nog ietsje later en box 4 stuurt hem weer ietsje later:
4 verschillende ecm's zijn er verstuurd. Ook al decoderen ze allemaal 1 en zelfde kanaal de ecm's van die verschillende momenten blijken te verschillen.
Wat doet de truuk: block de ecm aanvraag van alle ongewenste momenten.
Stel box 1 vraagt als eerste: deze ecm wordt uniek gemaakt en de controlword cycle gaat lopen. Box 2 vraagt seconde later met ander ecm: pech, jij wacht maar totdat je in sync loopt met box 1. Voor de overige boxen geldt zelfde. De boxen blijven wel ecm's sturen, totdat ze geluk krijgen en vanaf dat moment lopen ze in sync met box 1 en voortaan sturen ze alle 4 dezelfde emc's voor dat ene kanaal.
Tja en mocht er een hardnekkig geval tussen zitten die hardleers is dan gaat die inderdaad op zwart. Maar dat lijkt me altijd beter dan dat je kaart in strafmode komt te staan en geen enkele box meer beeld heeft.

[hemertje]

Oscam ontwikkelingen graag op het Oscam board bediscussiëren

[littlesat]

Maar waar komen die extra ECMs nu vandaan? Daar ben ik zo nieuwsgierig na????

Edited by littlesat, 28 February 2013 - 23:14.

[HPPli]

Maar waar komen die extra ECMs nu vandaan? Daar ben ik zo nieuwsgierig na????

Staat volgens mij hier in het voorbeeld van @theparasol;

De truuk met de ecm is relatief eenvoudig. In een klein lan share netwerkje heb je bv 4 boxen staan en in 1 box zit een kaart.
Nu lopen die boxjes lang niet allemaal in de maat. Box 1 vraagt op moment a een ecm aan, box 2 op moment b, box 3 op moment c, box 4 op moment d.
De controlword cycle is 10 seconden. Als box 1 een ecm stuurt en box 2 een ecm stuurt maar een seconde later, box 3 nog ietsje later en box 4 stuurt hem weer ietsje later:
4 verschillende ecm's zijn er verstuurd. Ook al decoderen ze allemaal 1 en zelfde kanaal de ecm's van die verschillende momenten blijken te verschillen.

[theparasol]

Alle ecm's komen uit de dvbstream. Alleen "tap" moment verschilt en blijkbaar verschijnt er dan ook een andere ecm.
Ik was altijd in de veronderstelling dat gedurende zeg maar 10 seconden interval de stream altijd zelfde ecm bevatte. Of je nu op 1,2,3,4,5,6,7,8 of 9 seconden ecm uit stream haalde: gelijke ecm. Blijkt niet zo te zijn. Afwijkende ecm komt blijkbaar vaker voor bij bv skylink kanalen. Dus als hardware van de box iets te vroeg of te laat ecm tapt en aan de dvbapi aanlevert krijg je kaart igv sharing sneller strafpunten.
Volgensmij moet gedurende die interval met verschillende ecms wel altijd zelfde controlword opleveren immers anders zou je dat gedeelte van de stream niet kunnen decrypten
Je zou dus ipv afwijzing ook actuele controlword kunnen retourneren ook al hoort die niet bij die specifieke ecm. Niks retourneren is altijd fout
En met controlword cycle check wordt een fout controlword toch de nek omgedraaid dus geen cache vervuiling mogelijk!

[Jeroensky]

Oscam ontwikkelingen graag op het Oscam board bediscussiëren

Of op opensat4all.

[Poodle]

Je zou dus ipv afwijzing ook actuele controlword kunnen retourneren ook al hoort die niet bij die specifieke ecm. Niks retourneren is altijd fout
En met controlword cycle check wordt een fout controlword toch de nek omgedraaid dus geen cache vervuiling mogelijk!

Klinkt goed, dat bij afwijkende ecm toch het control word naar de client wordt gestuurd, welke hoort bij de eerste ecm aanvraag van zelfde srvid. Hiermee uitgaand van feit dat control word dezelfde moet zijn, ook bij verschillende ecm (zoals theparasol al schreef).

Deze feature zit er nu nog niet in toch?

[Poodle]

Mogelijke toevoeging bij bovenstaande, versturen control word aan client met afwijkende ecm hoeft in principe alleen als alle slots bezet zijn. Ik neem aan dat clients, als deze weer synchroon lopen, daarna weer verder gaan met gebruik van 1 slot voor een bepaald srvid.

[littlesat]

Klinkt goed, dat bij afwijkende ecm toch het control word naar de client wordt gestuurd, welke hoort bij de eerste ecm aanvraag van zelfde srvid.

Slimme opmerking... als die extra ECM een omgebogen ECM is die eigenlijk bij een andere caid en provider id hoort... of wat dan ook... dat CW is toch altijd dezelfde bij simulcrypt.

Edited by littlesat, 1 March 2013 - 11:22.