35 replies to this topic

[Benfra]

Hoi allen,

 

Hoe kan ik het zappen sneller kan maken met oscam, heeft het iets te maken met oscam.srvit file aan te passen?  Zoja wat juist?

 

mvg Ben

[Tech]

Nee, de srvid heeft niets met sneller zappen te maken, in dat bestand worden de namen van kanalen gekoppeld aan de service id (sid) zodat je en de webif kunt zien welk kanaal wordt bekeken.

Geen idee hoe traag het zappen bij jou gaat maar ik heb binnen een seconde beeld op kanalen, dat lijkt me snel genoeg.

Om welke box gaat het?

[Benfra]

Vu+ solo2. Ik vind het soms lang genoeg duurt voor ik men volgend kanaal te zien krijg en de tijd verschilt van zender tot zender. Soms stoort het me een beetje. Zijn er soms andere mogelijkheden op die tijd te kunnen verkleinen?

[Henksat]

En ik neem aan dat je de kaart in de box hebt zitten?

[goldeneye]

Correct me if I am wrong, maar uit eerdere posts begreep ik dat er geen locale kaart aanwezig was.... Dus om een WAN sharing.... Maar nogmaals.....

[Henksat]

Correct me if I am wrong, maar uit eerdere posts begreep ik dat er geen locale kaart aanwezig was.... Dus om een WAN sharing.... Maar nogmaals.....

 

Een voorbarige conclusie, kan ook LAN sharing zijn.

De reden dat ik het vraag is dat in geval van LAN sharing de oorzaak ergens gezocht kan worden. (Net zoals bij WAN sharing natuurlijk)

[Sagitarius †]

Benfra, on 08 Jul 2016 - 05:03, said:Benfra, on 08 Jul 2016 - 05:03, said:Benfra, on 08 Jul 2016 - 05:03, said:Benfra, on 08 Jul 2016 - 05:03, said:Benfra, on 08 Jul 2016 - 05:03, said:Benfra, on 08 Jul 2016 - 05:03, said:

Hoi allen,

 

Hoe kan ik het zappen sneller kan maken met oscam, heeft het iets te maken met oscam.srvit file aan te passen?  Zoja wat juist?

 

mvg Ben

Heb je een kaart in de ontvanger, of een interne oscam server? Zo ja wat zijn de ecm tijden daarvan ( zie je rechts onderin bij een zender wissel bij de info balk).

Edited by Sagitarius, 8 July 2016 - 10:18.

[Jan Gruuthuse]

- juiste instellingen gebruiken  (niet met de pet naar gooien, dit kan verschillen per type STB), voor kaartlezers: nml: MHz, Card MHz, evt. Autospeed. 

- in LAN 1 protocol gebruiken cs378x (Transport Control Protocol) of cs357x (User Datagram Protocol), TCP doet handshake, UDP (fire and forget)

- Config: Cache: Global Cache Settings: Delay: 50 ms delaying answers from cache (verlagen naar bvb 50 ms), default staat iets hoger

Edited by Jan Gruuthuse, 8 July 2016 - 11:15.

[Erik Slagter]

Als je LAN sharing doet, maken al deze instellingen niks uit.

[Tech]

Als je LAN sharing doet, maken al deze instellingen niks uit.

Nee, als dat al een probleem gaat opleveren moet je het niet in de ST zoeken maar je netwerk maar eens gaan onderzoeken

[Jan Gruuthuse]

nou ja,

- als je de caching verlaagt naar 50 ms, komt de response toch vlugger

- gebruik je maar één protocol, belast je toch iets minder het ganse gedoe.

- staat je kaart lezer verkeerd ingesteld kan dit toch ook problemen geven, met als mogelijk gevolg trage response.

- ik zap snel, toch sneller dan met de geleverde troep van de aanbieders (kabel of sat)

[Poodle]

'Shining light' Jan gooit ook weer wat onzin de community in... (zoals al zo vaak eerder...)

 

- juiste instellingen gebruiken  (niet met de pet naar gooien, dit kan verschillen per type STB), voor kaartlezers: nml: MHz, Card MHz, evt. Autospeed. 

- in LAN 1 protocol gebruiken cs378x (Transport Control Protocol) of cs357x (User Datagram Protocol), TCP doet handshake, UDP (fire and forget)

- Config: Cache: Global Cache Settings: Delay: 50 ms delaying answers from cache (verlagen naar bvb 50 ms), default staat iets hoger

 

[Jan Gruuthuse]

beetje grof, doen leuk hoor

[mirakels]

Beste poodle.

We hebben op dit forum een groen arrow up icoontje als je een post van iemand wilt waarderen. Het rode down arrow icoontje hebben we weggehaald om te voorkomen dat deze in onredelijkheid gebruikt wordt. Het alternatief wordt dan om op zo'n post te reageren met constructief commentaar. Dus geen stemmingmakerij, dat laat je maar aan Wilders en consorten over.

 

Dus ik wacht met spanning op je uitleg waarom de opmerkingen van Jan Gruuthuse onzin zijn. Misschien is het zo en is het algemeen bekend, maar dan was het niet nodig geweest om dat nogmaals te herhalen. Maar ik weet van niets dus als je behulpzaam wilt zijn weet je wat je kan doen...

[Poodle]

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.

 

Maar dan to-the-point:

 

'als je de caching verlaagt naar 50 ms, komt de response toch vlugger, staat default iets hoger'. Nee, staat default op 0, ook in de standaard OpenPLi OSCam config. Maar ook als je deze iets zou verlagen (stel default is niet 0 maar bv. 80 en dan verlagen naar 50), denk je nu echt dat je deze 30ms merkt in de zapsnelheid? Onzin!

 

'In LAN 1 protocol gebruiken, gebruik je maar één protocol, belast je toch iets minder het ganse gedoe'. Alsof je elk apparaat (dus niet alleen je ontvangers) in je LAN netwerk het CS3xxx (TCP of UDP maakt lokaal normaal niet uit) moet laten praten (denk je echt dat je smartphone dit kan?). Alle softcam protocollen leunen voor de onderlinge communicatie op het TCP/IP protocol, daardoor zijn ze ook bruikbaar op internet (voor bv. WAN sharing). Pas als je meerdere netwerk protocollen op je LAN gebruikt (dus naast TCP/IP bv. IPX/SPX), belast je je switches/routers meer, maar zelfs dan is dit maar zeer beperkt. Dus hogere zapsnelheid door 1 protocol (als dit al zou kunnen), onzin!

 

Kaart moet wel juist worden ingesteld, daar heeft 'ie gelijk in. Meestal voldoen de standaard instellingen in o.a. OpenPLi (voor kaarten van CD/TVV), maar mocht je afwijkende kaarten hebben, is het zeker zaak om hiervoor de instellingen juist te hebben. Maar verschil tussen wel werkende kaart die niet optimaal staat ingesteld (qua mhz etc.) t.o.v. optimaal ingestelde kaart, zal qua ecm response tijd nooit bv. 300ms zijn, eerder < 50ms. Een niet optimaal lopende kaart zou dus een (zeer) kleine vertraging tijdens het zappen kunnen veroorzaken. Dus geen onzin, maar wel (zeer) weinig winst te behalen.

[Roymar]

heb hem altijd rond de 300ms zitten, zou niet weten hoe ik dit sneller krijg zonder m'n kaart op te roken

[Sagitarius †]

Dat bedoel ik hij zit hier ook rond de 300ms, minder dan 50 heb ik hier nooit gehaald, wel even uit de cache dan kom ik wel eens op 10ms.

[littlesat]

Dat bedoel ik hij zit hier ook rond de 300ms, minder dan 50 heb ik hier nooit gehaald, wel even uit de cache dan kom ik wel eens op 10ms.

 

->

 

Kan helemaal niet, behalve uiteraard als je op een "grote ïllegale" cardserver zit die uiteraard alle bekeken zenders cached.... (en na 10 sec zie je hem dan weer rond de 300 staan!!!)

[WanWizard]

Heeft dat soort lage tijden uberhaupt zin? De box moet ook nog kunnen tunen, dat is ook niet in 10ms gebeurd volgens mij...

[littlesat]

En dan nog altijd door de GOP structuur heb je pas beeld tussen de 1/2 en de volle seconde....