posixx

Hoeveel negatieve beoordelingen moet je eigenlijk hebben voordat je verbannen wordt van dit forum?

Ik zou nog even wat testen en posten, bij deze. Dit is met 4/11 en 50,120 en met twee streams (nota bene...) op dm8000 waar ook de kaart in zit, en het gaat al fout, oscam gaat in "cooldown" mode. Dit klopt toch zeker niet???

Jawel, cooldown mode is niet iets wat pas ingeschakeld wordt op het moment dat het moet. Dat is ook waarom cooldown mode zoals deze nu on OSCam zit vrijwel onbruikbaar is. Het is nu gewoon een timer welke na 50 seconden aangezet wordt, en na 120 seconden weer wordt uitgezet, ongeacht het aantal streams / ECM's. De cooldown functionaliteit is pas effectief wanneer OSCam de cooldown inschakeld zodra er meer dan 4 ECM's binnen 11 seconden opgevraagd worden. Dit is al wel kenbaar gemaakt aan het dev-team, maar nog geen vervolg..

ook voor jou geldt dat we geen onderlinge verwensingen of elkaar zwart maken hier meer willen zien!
deze trap na was dus niet nodig geweest, er is inmiddels genoeg over gezegd

indien nog iemand deze discussie aanhaalt gaat dit draadje zonder pardon op slot

Dit was niet bedoeld als een trap na. Ik zal de uitleg geven.

Bas gaf aan dat met een instelling van 2/10 de kaart in de oude situatie gezet kon worden. De oude situatie was dat een kaart relatief onbeperkt ECM's kon afleveren. Tussen elke ECM aanvraag van 1 kanaal zit 10 seconden. wanneer het antwoord van de kaart 250ms duurt, kan de kaart 4 ECM's per seconde afleveren, totaal 40 per 10 seconden (in theorie dan). Hier heeft M7 dus een stokje voor gestoken, dit is nu dus maximaal 4 geworden (de burst-mode even buiten beschouwing gelaten).

Wanneer je nu in OSCam de ECMlimiet op 2/10 zorg je er inderdaad voor dat je kaart nooit op zwart gaat omdat deze nieuwe limiet nooit bereikt wordt. Maar je hebt dan ook maar 2 ECM's per 10 seconden beschikbaar. Als je 4 ontvangers hebt die allemaal op andere zenders zijn afgestemd zul je dus haperend beeld hebben omdat per 10 seconden maar 2 ECM's uitgegeven mogen worden op die kaart.

Als ik het verkeerd zie dan hoor ik dat graag natuurlijk.

Ik denk dat ik het begin te begrijpen. Deze pid komt door een of andere reden op de blocklist. Daar ben ik nog niet achter. Maar deze list is eigenlijk puur een buffer wat voorkomt dat deze aanvraag blijft duren. Door de lb_reopen_seconds nu laag te houden (zeg 10 seconden) zal de request opnieuw door de client bij de kaart komen. Hiermee voorkom je dat een kanaal langere tijd voor alle boxen op zwart gaat. Als je je services goed hebt gedefineerd en deze aan de readers hebt gekoppeld is zo'n kleine reopen tijd geen probleem.

In principe wel ja, maar in de praktijk werkt dat mechanisme helaas niet zo goed...

Heb de duitse wiki eens bekeken, vind dat daar betere info in staat dan de engelse. Het toevoegen van services aan je reader heeft de volgende uitwerking op loadbalancing: deze werken als een whitelist voor loadbalancing. Dit betekend dat wat je bij een service invoert door de loadbalancer gezien wordt als 'ondersteund' door de kaart. Wanneer er toch een 'not found' voordoet, wordt deze genegeerd en zal de kaart vervolgens blijven gevraagd worden voor deze PID.

Dus, stel je hebt 2 C+ NL kaarten, 1 met het toppakket en EDL en 1 met het entertainmentpakket (extra kaart). Om deze goed te kunnen loadbalancen dien je de volgende services toe te voegen:

[canaldigitaal_compleet]
caid						  = 0100
provid					    = 00006A
srvid						 =
 
[eredivisielive]
caid						  = 0100
provid					    = 00006A
srvid						 = 17CC,51C7
 
[canaldigitaal_toppakket]
caid						  = 0100
provid					    = 00006A
srvid						 = 51B8,51AE,51B3,51BD,51C2,51DB,51E0

Nu geef je de reader met de full-abo kaart de volgende regel:

services					  = canaldigitaal_compleet

En de kaart met alleen het entertainmentpakket:

services					  = canaldigitaal_compleet,!canaldigitaal_toppakket,!eredivisielive

Zo zou het loadbalancen met 2 'verschillende' kaarten goed moeten gaan.