35 replies to this topic

[Tech]

Ach, zolang de geldigheid van ecm's nog niet aan de orde is, hoef je je daar niet druk om te maken.

[Jan Gruuthuse]

Het niveau van Jan's bijdragen is vaak nogal van een bedenkelijk niveau, en dat was deze keer niet anders. Hij suggereert meestal alsof hij het allemaal zo goed weet, maar dit valt vaak te betwijfelen. Hij bedoelt het vast goed, daar zal ik niets van zeggen, maar zijn informatie brengt mensen meestal weinig tot niets.

 

Blijkbaar heb je persoonlijk een pik op mij. Ik suggereer helemaal niets. Al verschillende keer aangegeven dat ik een gebruiker ben.

 

Net nog even getest: "Config: Cache: Global Cache Settings: Delay: 50 ms" maakt geen verschil meer uit. Blijkbaar is daar iets veranderd (ms delaying answers from cache). Mijn STB's krijgen binnen de 10 ms een antwoord uit de cache van de STB die de kaart heeft, gelijk wat ik daar nu instel. Vroeger was dit anders.

[Erik Slagter]

Laten we ons nou gewoon concentreren op de inhoud. Als je het niet eens bent met de bijdrage van iemand dan kun je op inhoud er op in gaan of het gewoon negeren. Het is totaal niet nodig om op de man te spelen. Daar komen alleen verliezers van.

[Jan Gruuthuse]

Ook een mogelijkheid in Cache: Max time: 12 s keep ECMs in cache (CDNL 10 seconden en 1 seconde voor en na) als de klant ecm vraagt deze dan toch nog in de cache aanwezig is. Mocht deze vraag net ergens op de grens (aanvang/einde) van die 10 seconden worden.

[Tech]

Ook al zou je de cw langer in cache bewaren dan 12 seconden is er nog weinig aan de hand, de opvolgende cw is toch anders.
Maar als je twee ontvangers hebt denk ik niet dat je er ook maar iets van gaat merken dat de zapsnelheid omhoog gaat, de cache heeft alleen zin als een andere client toevallig op hetzelfde kanaal staat, allemaal zaken die je thuis echt niet nodig hebt.

[Poodle]

Ook een mogelijkheid in Cache: Max time: 12 s keep ECMs in cache (CDNL 10 seconden en 1 seconde voor en na) als de klant ecm vraagt deze dan toch nog in de cache aanwezig is. Mocht deze vraag net ergens op de grens (aanvang/einde) van die 10 seconden worden.

 

Hahaha... dit bedoel ik nou... 1 seconde voor (en na)? Een ECM kan NOOIT in de cache komen 1 seconde VOOR de periode van 10 seconden, waarin de ECM geldig is! 

[Jan Gruuthuse]

Tijdsverschil tussen de ontvangers. Zit deze net op de grens. Vraagt een ontvanger aan andere ontvanger terwijl deze net deze uit de cache kiepert. Het gaat niet om wanneer deze in de ontvanger komt, het gaat om wanneer deze uit de cache gekiepert wordt. Alle 3 de ontvangers serven de kaarten onderling. Met 12 seconden marge is deze hoe dan ook nog in de cache aanwezig.

 

Hahaha... dit bedoel ik nou... 1 seconde voor (en na)? Een ECM kan NOOIT in de cache komen 1 seconde VOOR de periode van 10 seconden, waarin de ECM geldig is! 

 

Poodle kijk jij nou maar rustig door jou paardebril. En zoek iemand anders om te cyberpesten.

[Triax]

Ik heb het zappen sneller gemaakt door van een VU Duo over te stappen naar een Solo 4K (gisteren), wat een verschil

[goldeneye]

Ik heb één DM800HD-SE vervangen door een VU+ SoloSE V2. ECM tijden van de kaart zijn volledig identiek! Dit terwijl de box dus bijna 3 x sneller is. Zappen is maar marginaal sneller. Wat maar weer bewijst dat de zaptijd sterk afhankelijk is van de kaart/kaartlezer snelheid. Significant sneller zapper gaat dus alleen als je de kaart opvoert/overklokt. Sneller, maar ook sneller de kaart kapot....

[theparasol]

Valt allemaal wel mee, die nagra kaarten kunnen 9 mhz prima hebben, dan krijg je trouwens een ecm response van 170 ms.

Worden dan wel wat warmer... mijn kaart heeft een bruine brandvlek nabij de chip hierdoor. Heeft meer dan een jaar op 9 mhz gedraaid.

Niet omdat ik wilde overclocken maar omdat ik dacht dat oscam de chip op 3 mhz klokte... dat was dus 2700/3 = 9.00 mhz (!)

[goldeneye]

Zou je denken dat die kaart 6 jaar had kunnen draaien dan op 9 Mhz? Na een jaar al een bruine plek bij de chip.... Mijn Seca kaart draait vanaf de kaartwissel van Seca2 en geen plekje hoor....

[WanWizard]

Mijn SKY kaart heeft het door het door theparasol geschetste probleem begeven, dus "nee". Die zat destijds in een DM7000 die ik als cardserver had ingezet, en die vind onbeperkt hoger klokken blijkbaar prima.

[theparasol]

7000 = powerpc pll: 3150 / 3 = 1050 = 11 Mhz

 

Dat is wel wat te veel van het goede.

 

Dreambox is voor zover ik het weet de enige fabrikant die vrij clocken van de smartcards toestaat. Al de anderen clocken de drivers zelf de kaart op basis van de ATR van de kaart.

[WanWizard]

Ik heb geen idee wat de config destijds was, maar het zou best kunnen dat hij op 3.57 gestaan heeft of zo, en dat is aan je berekening te zien erg ongezond. Wat dan ook gebleken is.

 

Gelukkig was na een belletje een nieuwe kaart zo geregeld.

[theparasol]

3.57Mhz was idd destijds de default waarde. Er waren wat streamboarders die met een Mhz meter de boel nagemeten hadden (TheRaven en Irata) en die gaven al aan dat er iets niet goed zat icm dreambox. Na wat bestudering van de meetresultaten versus de verschillende instellingen en dreambox types heb ik daar toen een paar jaar terug een aanpassing voor gemaakt waardoor ook igv dreambox de mhz nu wel exact gelijk loopt.

[christophecvr]

Een algehele typ :

 

Het zappen kan sneller gemaakt worden door juist gebruik van de oscam.dvbapi file.

goed gedocumenteerd op streamboard site.

 

Eigenlijk de juiste prioriteiten versus uw persoonlijke kaarten instellen.

 

Nu heb je maar één kaart dan (en uiteraard dan ook geen wan gebruikt) is het niet nodig.

Maar voor bv zoals bij mij twee m7 abo's tvv/telesat waarbij de telesat niet de extra optie tvv heeft

verhoogd de zaptijd voor sommige kanalen aanzienlijk. Dat is op te lossen met oscam.dvbapi.