4250 replies to this topic

[posixx]

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?

Draai hier met de 4 / 10 instelling en heb nog nooit een kaart op zwart gehad. Heb 3 kaarten erin zitten (1 hoofdabo + 2 extra kaarten) en loadbalance mode op 2, waarmee elke kaart om-de-beurt aangesproken wordt. Ik zie de ECMRateLimit af en toe inschakelen waarna de volgende kaart gepakt wordt, en werkt tot nu toe vlekkeloos.

[Non Disclosed]

Ik geef nog een hint wat OScam is: http://en.wikipedia....ki/Proxy_server
Lees dat nu eens, dan merk je dat het spul heel anders ineen zit dan CCcam.

En die ratelimiet van 4/11 werkt niet in OScam, 3/10 wel.

Waarom mensen op jacht gaan naar meer ECM's is me een raadsel, want zoals ik al eerder aangaf het is een proxy, geen cardserver zoals CCcam.
Lees a.u.b. nu eerst eens die proxy wiki dan snap je misschien waarom deze topic over een paar ECM's zo lang duurt, want 3/10 is prima.

Ook hoef je niet met caching te klooien want het ding cached alles toch.

Als je kaarten gaat opsplisten in groepen om ECM last te vermijden doe je juist de proxy om zeep, want de proxy is pas effectief op veel aanvragen.

Zoals ik ook al eerder aangaf, ik vermoed dat OScam bij 0 begint te tellen en niet bij 1, wat dus perfect verklaard waarom oscam op 3/10 het goed doet en CCcam 4/11.
Mocht iemand dit een foutje noemen dat zit heel de computer-industrie te werken op foutjes, want voor computers is het normaal om met 0 te beginnen.
Kijk gewoon even naar internet, minimale waarde = 0.0.0.0 maximale waarde 255.255.255.255 = die 0 <=> 255 = 256 stappen.
Bij computer is 0 ook een waarde in tegenstelling tot bij mensen.

En nu hou ik er over op, je doet maar, ik blijf op 3/10 en het werkt perfect zonder cooldown, geen hapering of niks.
Als je de juiste oscam.dvbapi hebt en dvbapi requestmode = 0 (CAID per CAID en niet allemaal tegelijk!) hebt staan.

Groeten en succes met knoeien

[posixx]

Waarom zou je dat willen?

Ik heb vernomen dat de kaart helemaal niet sneller en wellicht zelfs langzamer gaat werken op hogere snelheden.

Dit blijkt zo te zijn met interne readers zoals die van de dreambox. Met smargo's is het echt een ander verhaal; daarmee kan je de ecm tijden flink verkorten.
Ik begrijp overigens niet waarom mensen dit koppelen aan bv. de chid-lock of ecm tijden. Daat staat los van de Mhz instelling. De codering welke gebruikt wordt bepaald wat de tijdsperiode is tussen ECM's, niet de frequentie van de kaart. Hoe sneller de kaart antwoord geeft hoe meer ECM's deze kan verwerken; althans was dit zo voor de chid-lock:-) Sinds deze beperking is het flink overklokken van je kaart dus enkel meer risico op problemen, je schiet er verder weinig mee op.

[Erik Slagter]

Draai hier met de 4 / 10 instelling en heb nog nooit een kaart op zwart gehad. Heb 3 kaarten erin zitten (1 hoofdabo + 2 extra kaarten) en loadbalance mode op 2, waarmee elke kaart om-de-beurt aangesproken wordt. Ik zie de ECMRateLimit af en toe inschakelen waarna de volgende kaart gepakt wordt, en werkt tot nu toe vlekkeloos.

Dat is niet vergelijkbaar met mijn situatie (gewoon 1 kaart met vier + twee tuners interne sharing).

[frissie]

En nu hou ik er over op, je doet maar, ik blijf op 3/10 en het werkt perfect zonder cooldown, geen hapering of niks.
Als je de juiste oscam.dvbapi hebt en dvbapi requestmode = 0 (CAID per CAID en niet allemaal tegelijk!) hebt staan.

Groeten en succes met knoeien

Bij mij werkt 3/10 ook perfect, met 2 kaarten in load balance 2.
Doe ik 4/10, happeringen en stotteren ... zoals bart zegt.

Edited by frissie, 7 February 2012 - 12:55.

[polarbear]

En nu hou ik er over op, je doet maar, ik blijf op 3/10 en het werkt perfect zonder cooldown, geen hapering of niks.
Als je de juiste oscam.dvbapi hebt en dvbapi requestmode = 0 (CAID per CAID en niet allemaal tegelijk!) hebt staan.

Groeten en succes met knoeien

Bij mij werkt 3/10 ook perfect, met 2 kaarten in load balance 2.
Doe ik 4/10, happeringen en stotteren ... zoals bart zegt.

E.e.a is puur afhankelijk van het aantal clients dat je op je kaarten hebt. Als je 2 kaarten in lb mode op 4/10 hebt staan, kunnen er maximaal 4 sids per kaart per 10 seconden worden gevraagd. Dat zijn reeel iets minder dan 4 clients. (want een client zapt). Als je dan totaal maar 5,6 of 7 kijkende clients hebt blijft e.e.a. ook wel prima werken Maar ga je in jouw geval naar 8 clients, dan krijg je onherroepelijk toch problemen!!!!
Uit mijn logfiles blijkt overigens knetterhard dat per 10 seconden dan ook daadwerkelijk maximaal 4 sids worden afgegeven; de 5e aanvraag binnen die 10 seconden geeft een rejected ECMspacelimit no space for sr. Kijk maar na in je logfile!
Dat kan echter niet de reden zijn dat de kaart begint te stotteren. Zet je dit aantal seconden op 11 of 12, kun je effectief nog minder sids aan de kaart vragen en maak je m.i. het probleem alleen maar groter. Misschien moeten we eens 7 per 20 proberen
Dan zit je in theorie iets lager dan 4 /10.

[christophecvr]

@Polarbear

je zal het wel weten maar voor alle zekerheid zeg ik het er nog bij cacheex gaat enkel tussen twee oscam. gaat niet met cccam users.

[HPPli]

Ik heb even getest middels met 1 kaart met daaraan 4clients.
3 clients in opname dus 3 chids in gebruik en met de 4e client kijken en zappen.
Het resultaat is, altijd beeld en geen stottering etc. een instelling als volgt;
ratelimitecm = 4
ratelimitseconds = 9
cooldown = 50,120

Zodra ik terugga van 4 naar 3 ratelimitecm(s) altijd problemen, met voornamelijk stottering bij de 4e client. (client 1,2,en 3 niet bekeken, enkel in opname gehouden)
Indien ik weer terugga naar ratelimitecm = 4 kan ik weer redelijk zappen op 4e client, maar heb ik zo nu en dan een freeze (4e client)
Zodra ik dan ratelimitseconds stapsgewijs terugbreng van 15 naar 10 kan je goed zappen maar blijft de freeze zo nu en dan op de 4e client.
Ga ik terug naar ratelimitseconds = 9 is ook het laatste probleempje (freeze) niet meer aanwezig en kan ik langdurig kijken en zappen, terwijl ik er als 4e client en/of gebruiker aan de kaart "hang"
Rest mij te melden dat dit is getest met een VU+DUO // Oscamversie 6351 welke gelijktijdig als server en tevens intern (ge)connect middels dvbapi client en leest van 1 enkele kaart// reader als kaartlezer initialized (device=/dev/sci0, detect=cd, mhz=300, cardmhz=500)

[doglover]

Het bovenstaande illustreerd wat ik altijd beweerd heb.

Oscam werkt wel, maar soms ook weer niet. Krijg dat probleem er ook nog uit en we praten verder.

Willy

[christophecvr]

Ik heb even getest middels met 1 kaart met daaraan 4clients.
3 clients in opname dus 3 chids in gebruik en met de 4e client kijken en zappen.
Het resultaat is, altijd beeld en geen stottering etc. een instelling als volgt;
ratelimitecm = 4
ratelimitseconds = 9
cooldown = 50,120

Zodra ik terugga van 4 naar 3 ratelimitecm(s) altijd problemen, met voornamelijk stottering bij de 4e client. (client 1,2,en 3 niet bekeken, enkel in opname gehouden)
Indien ik weer terugga naar ratelimitecm = 4 kan ik weer redelijk zappen op 4e client, maar heb ik zo nu en dan een freeze (4e client)
Zodra ik dan ratelimitseconds stapsgewijs terugbreng van 15 naar 10 kan je goed zappen maar blijft de freeze zo nu en dan op de 4e client.
Ga ik terug naar ratelimitseconds = 9 is ook het laatste probleempje (freeze) niet meer aanwezig en kan ik langdurig kijken en zappen, terwijl ik er als 4e client en/of gebruiker aan de kaart "hang"
Rest mij te melden dat dit is getest met een VU+DUO // Oscamversie 6351 welke gelijktijdig als server en tevens intern (ge)connect middels dvbapi client en leest van 1 enkele kaart// reader als kaartlezer initialized (device=/dev/sci0, detect=cd, mhz=300, cardmhz=500)

Verhoog je client timeout in oscam.conf global section eens tot 16000 (is 16 seconden) zou kunnen dat je dan geen stotterringen krijgt met rate limit 3 15

[HPPli]

Verhoog je client timeout in oscam.conf global section eens tot 16000 (is 16 seconden) zou kunnen dat je dan geen stotterringen krijgt met rate limit 3 15

Ga ik straks of vanavond eens testen, kom er dus op terug.
Thanks voor het meedenken.

@doglover, Bij mij werken alle clients en m'n VU+DUO als server voor 3 clients en internal DVBapi (client) tadeloos, ofwel perfect.

[Lite On]

Ik wilde nog even terug komen op mijn bevindingen van de kaart update.
Alleen managment is nog niet geupdate, is dat normaal of had die gelijktijdig geupdate moeten worden?



[reader]
label = kaart
description = canaldigital
protocol = internal
device = /dev/sci0
detect = cd
mhz = 500
cardmhz = 500
group = 1,2
emmcache = 1,3,2
dropbadcws = 1
ratelimitecm = 3
ratelimitseconds = 10

[account]
user = dvbapiuser
pwd =
description = lokaal
group = 1,2
au = kaart
cccmaxhops = 0
cccreshare = 0
cccstealth = 0


[dvbapi]
enabled = 1
au = 1
boxtype = dreambox
user = dvbapiuser


admin 0100 000000 0000000000000000 00000000 1970-01-01 2012-03-25 MANAGMENT PBM 0100 00006A C100000000000000 00000000 1970-01-01 2012-04-07 Canaal Digitaal NL

[christophecvr]

@HPPli ook mhz=300 cardmhz=500 is geen logische setting, kan wel werken maar heeft geen zin, Je gaat je kaart op clockspeed 480 brengen (dat is de speed die oscam zal nemen). dan ga je je ecm aanvraag underlocken in speed ?

laat ofwell mhz cardmhz gewoon weg of zet er mhz=480 cardmhz=480.

[christophecvr]

@ Lite On

Ik heb het nu weer eens uitgebreid getest,
Oscam update wel degelijk de kaart zowel voor 000000 als 00006c (met 6a zal het hetzelfde zijn)

Maar, enkele rariteiten.

Ik heb 2 kaarten waarvan één extra is.

ben ik nu aan het kijken naar kanaal bv tv één (sd) die enkel op kaart 1 kan ontvangen worden , dan zal hij de 00006c op die kaart updaten. Niet de 000000. Wacht ik lang genoeg (+- 3 uur)
dan zal hij ook 000000 van kaart 2 diegene die NIET aan het decoderen is up daten. maar niet deze van kaart één. Dit werkt ook net omgekeerd. Dit is eveneens het geval voor 6d (telesat)

[polarbear]

@Polarbear

je zal het wel weten maar voor alle zekerheid zeg ik het er nog bij cacheex gaat enkel tussen twee oscam. gaat niet met cccam users.

Nee, je hebt gelijk. Op zich werkt de cache exchange in oscam wel goed zag ik , maar 2 verschillende users naar 1 en dezelfde server gaat niet binnen CCcam als client. Dus of de gewone user uit groep 1 heeft beeld uit reader 1, of de cachevariant van deze user heeft beeld uitsluitend uit de cache van de groepen 2 en 3. Een combinatie is kennelijk niet mogelijk. Welke user aktief is op 1 en dezelfde server, is afhankelijk van de rangorde van de C-lijnen.

[polarbear]

Ik geef nog een hint wat OScam is: http://en.wikipedia....ki/Proxy_server
Lees dat nu eens, dan merk je dat het spul heel anders ineen zit dan CCcam.

En die ratelimiet van 4/11 werkt niet in OScam, 3/10 wel.

Waarom mensen op jacht gaan naar meer ECM's is me een raadsel, want zoals ik al eerder aangaf het is een proxy, geen cardserver zoals CCcam.
Lees a.u.b. nu eerst eens die proxy wiki dan snap je misschien waarom deze topic over een paar ECM's zo lang duurt, want 3/10 is prima.

Ook hoef je niet met caching te klooien want het ding cached alles toch.

Als je kaarten gaat opsplisten in groepen om ECM last te vermijden doe je juist de proxy om zeep, want de proxy is pas effectief op veel aanvragen.

Zoals ik ook al eerder aangaf, ik vermoed dat OScam bij 0 begint te tellen en niet bij 1, wat dus perfect verklaard waarom oscam op 3/10 het goed doet en CCcam 4/11.
Mocht iemand dit een foutje noemen dat zit heel de computer-industrie te werken op foutjes, want voor computers is het normaal om met 0 te beginnen.
Kijk gewoon even naar internet, minimale waarde = 0.0.0.0 maximale waarde 255.255.255.255 = die 0 <=> 255 = 256 stappen.
Bij computer is 0 ook een waarde in tegenstelling tot bij mensen.

En nu hou ik er over op, je doet maar, ik blijf op 3/10 en het werkt perfect zonder cooldown, geen hapering of niks.
Als je de juiste oscam.dvbapi hebt en dvbapi requestmode = 0 (CAID per CAID en niet allemaal tegelijk!) hebt staan.

Groeten en succes met knoeien

Ik weet echt wel wat een proxy is; waar jij echter nu over praat zijn kennelijk hele grote oscam-netwerken. En dat valt vlgs mij buiten de scope van deze thread. Hier gaat het met name om het opzetten van een simpel servertje voor thuisgebruik, al dan niet met dvbapi. En omdat CCcam de nodige beperkingen heeft proberen we oscam te gebruiken om dit doel te bereiken. Dat lukt redelijk. De meeste mensen zijn hier al gelukkig als ze b.v 2 kaarten hebben en proberen daar de spulletjes thuis zo soepel mogelijk te laten verlopen.
En daar past nu eenmaal de discussie over de ecm 's en limieten bij.

[doglover]

@doglover, Bij mij werken alle clients en m'n VU+DUO als server voor 3 clients en internal DVBapi (client) tadeloos, ofwel perfect.

En wat gebeurt er als er vier opnames lopen, en vervolgens ga je zappen op jouw TVV of CDS abbo.
Ik verwacht dan dat de opnames feilloos doorlopen, maar vermits je aan de limiet zit, zo er niets mogen opengaan en zwart blijven. En niet zoals mijn ervaring is gaan haperen en freezen. Terwijl ook opnames gaan freezen.

Willy

[polarbear]

Ik heb even getest middels met 1 kaart met daaraan 4clients.
3 clients in opname dus 3 chids in gebruik en met de 4e client kijken en zappen.
Het resultaat is, altijd beeld en geen stottering etc. een instelling als volgt;
ratelimitecm = 4
ratelimitseconds = 9
cooldown = 50,120

Zodra ik terugga van 4 naar 3 ratelimitecm(s) altijd problemen, met voornamelijk stottering bij de 4e client. (client 1,2,en 3 niet bekeken, enkel in opname gehouden)
Indien ik weer terugga naar ratelimitecm = 4 kan ik weer redelijk zappen op 4e client, maar heb ik zo nu en dan een freeze (4e client)
Zodra ik dan ratelimitseconds stapsgewijs terugbreng van 15 naar 10 kan je goed zappen maar blijft de freeze zo nu en dan op de 4e client.
Ga ik terug naar ratelimitseconds = 9 is ook het laatste probleempje (freeze) niet meer aanwezig en kan ik langdurig kijken en zappen, terwijl ik er als 4e client en/of gebruiker aan de kaart "hang"
Rest mij te melden dat dit is getest met een VU+DUO // Oscamversie 6351 welke gelijktijdig als server en tevens intern (ge)connect middels dvbapi client en leest van 1 enkele kaart// reader als kaartlezer initialized (device=/dev/sci0, detect=cd, mhz=300, cardmhz=500)

Kijk, het lijk er dus op dat je met 4/9 voor 4 clients de goede setting te pakken hebt. Zou leuk zijn als de clients af en toe eens zouden zappen en kijken wat er dan gebeurd (niet al te vaak en niet allemaal tegelijk).

Er spelen dus 2 belangrijke zaken, namelijk
1: iedere client heeft gewoon 1 x per 10 seconden een controlword (SID) nodig om beeld te houden; dat is een vast gegeven. Dit staat helemaal los van oscam of welke andere server ook. Volgens mij is die 10 seconden ook echt 10.00 seconden, maar evengoed kan het wat meer of minder zijn .
2: vraag je meer dan 4 sids per 10 seconden, loop je tegen een beperking aan; dit kan zijn

-A je eigen opgezette blokkade in oscam (door de ecmlimit en de ratelimitseconds verkeer in te stellen of
-B De card-penalty ( Er is geen goede waarde voor a ingevuld en dus vraag je te veel sids per tijdseenheid van de kaart)

Beide condities geven in eerste instantie een stotterend en freeze-achtig beeld. Hef je de situatie niet snel genoeg op gaat de kaart in een soort definitieve lock . Echter conditie A is gemakkelijk te traceren in de logfile van oscam.

Wat ik nu bij HPPli lees is dat hij met een instelling van 4/9 toch ongestoord beeld houdt op alle 4 de clients. Hiermee omzeilt hij dus de oscam-blokkade.
Mogelijk gaat de kaart echter onder 4/9 toch naar conditie B indien er door deze 4 clients simultaan- en veelvuldig wordt gezapt.

Eigenlijk is het allemaal niet zo moeilijk, maar je moet de dingen goed uit elkaar houden.
Zo zal 3/9 en 4/10 of 4/11 of zelfs 4/15 wellicht ook prima voldoen, maar wat heb ik aan deze gegevens als ik er niet bij vertel met hoeveel en welk type clients (opname of tv-kijker) ik tegen de kaart aan zit. Dat laatste is dus in alle gevallen een zeer essentieel gegeven.

[theparasol]

@polarbear, ik heb jouw config eens even aandachtig gelezen (tig berichten terug)
Je groept de users en wijst ze vervolgens 1 specifieke reader toe.
Wat nu als je het anders benadert: Maak services aan. In die services benoem je welke kanalen een specifieke service mag opvragen.
Vervolgens wijs je die services toe aan de de diverse readers (=kaarten) met deny op kanalen die de kaarten niet kunnen.
Daarnaast ook aan de diverse users met deny op kanalen die ze niet mogen ontvangen.
Als je nu CCcam server al share protocol naar de clients gaat gebruiken kun je sharen op caid / service level. Je clients zien dan virtuele kaarten van wat ze wel kunnen decoden maar uiteraard geen "kaarten" waar ze geen rechten op hebben volgens hun serviceconfig die je per user kunt aangeven.
Grote winst zit hem erin dat je:
- Loadbalancer mode lowest usage level kunt gaan gebruiken over al je kaarten over alle users.
- Je cache over alle kaarten gaat werken ipv alleen binnen bepaalde groep
- De ratelimits zullen naar de clients toe geen stotters meer geven of je moet haast wel tegen een full pull aanlopen tijdens spitsuur waarbij iedereen loopt te zappen.

Al met al zul je minder snel tegen de individuele limits van een kaart aanlopen: immers hogere kans op cachehit + oscam vraagt ecm's van kanalen op een kaart die nog niet aan zijn taks zit als dat mogelijk is. Daarnaast verandert er aan de client side helemaal niets maar je bent wel van dat gegroep af.

Wellicht een optie voor je om oscam op deze wijze in te richten.

@Bas: Je stelt dat oscam telt vanaf 0: klopt niet, bv 4 = 4 ecm's. Dat heb ik nl al eens onderzocht. Verder bereik je hier alleen maar onnodig verwarring mee in dit topic en ik ga persoonlijk steeds minder waarde hechten aan je "bijdrages" in dit draadje alleen al is het al 2 keer voorgekomen dat je claimed en roept op basis van aannames die onjuist zijn.
We hebben het in dit topic niet over meningen en aannames maar over onderzoek en feiten.

[HPPli]

@doglover, Bij mij werken alle clients en m'n VU+DUO als server voor 3 clients en internal DVBapi (client) tadeloos, ofwel perfect.

En wat gebeurt er als er vier opnames lopen, en vervolgens ga je zappen op jouw TVV of CDS abbo.
Ik verwacht dan dat de opnames feilloos doorlopen, maar vermits je aan de limiet zit, zo er niets mogen opengaan en zwart blijven. En niet zoals mijn ervaring is gaan haperen en freezen. Terwijl ook opnames gaan freezen.

Willy

Indien ik op de server met interne dvbapi-client welke 4 opname's heeft lopen (4 chids) blijven de opnames keurig heel (doorlopen). Terwijl ik op mijn externe clients niets meer kan zien bij het zappen, maar ga ik naar 1 van de kanalen welke ook in opname staan op de andere receiver heb ik gewoon beeld zonder enige stottering.
Conclusie, mijn kaart blijft "heel" en gaat dus niet in de penalty-stop. Dit alles met;
ratelimitecm = 4
ratelimitseconds = 9
cooldown = 50,120

@christophecvr, Ook een verhoging van de clienttimeout in oscam.conf gaf geen verandering/verbetering van de resultaten.