4250 replies to this topic

[Pedro_Newbie]

Krijg je dan met die PMT BLABLABLABLABLA meer zenders open

Alleen talkshows, meer niet (sorry kon het even niet laten, ik ben weer weg)

[theparasol]

Voor iedereen hier die met ecmratelimit / ratelimitseconds en cooldown experimenteert:

Voordat je de verkeerde conclusie ik heb vandaag "even" de logging van oscam bestudeert met ecmratelimit op 1 en televisie + extra stream open:

Experimenteer met de ratelimitseconds, zet die eens naar 8 oid als je die stijf op 10 seconden hebt staan kan oscam soms een pass geven maar pas op 11 seconden na eerste ecm alsnog een extra ecm vragen waardoor de card bij 4 gelijktijdige ecm's alsnog in de lock kan gaan. De timings zijn dus niet krek dus je zult een beetje moeten compenseren.
Mocht je de kaart "opgevoert" hebben qua mhz dan kan het ook maar zo zijn dat de seconde klok van de kaart sneller tikt en daardoor niet 4 ecm's per 10 seconden maar 4 ecm's per 7 seconden de lock al triggert.

Mocht je cooldown ook inzetten:

Met cooldown 60,1200 (na 60 seconden ratelimit instellen) moet je compenseren voor de ecm rate in geval van CDS dus minimaal 10 seconden aftrekken om veilig te zitten.
cooldown 50,1200 dus.

[WanWizard]

Dat begrijp ik, maar volgens mij zul je dan nog steeds problemen hebben met het openen van de kanalen met zowel sec2 als seca3 pids. Ik ben benieuwd of je bijvoorbeeld NL1 NL2 NL3 SBS6 (de SD versie op 19,2E) kunt openen vanaf je kaartje in het linux bakkie.

Ja, geen enkel probleem...

[Erik Slagter]

Ja thanks. Ben jij nog verder gekomen met testen van de cooldown period?

Ja, zie eerder. Ik kreeg de kaart niet warm, laat staan rokend, met de beschreven instellingen.

[theparasol]

@Erik: Heb je nog je disconnect verhaal niet opgelost? Het heeft toch niets te doen met MTU sizes ofzo?

[Erik Slagter]

Net precies is dmv shared emm's mijn kaart naar volgende gegaan:

admin 0100 000000 0000000000000000 00000000 1970-01-01 2012-03-19 MANAGMENT PBM 0100 00006A BLABLABLABLABLA 00000000 1970-01-01 2012-03-17

Ik niet snap niet?

[Erik Slagter]

@Erik: Heb je nog je disconnect verhaal niet opgelost? Het heeft toch niets te doen met MTU sizes ofzo?

Ik heb een ticket aangemaakt.

En nee heeft niks te maken met mtu e.d. Mijn netwerk is wel goed. Als dat niet zo was zou ik me diep moeten schamen als netwerkbeheerder ;-) Ik denk dat het een combinatie is van timeouts en bugs in oscam.

[theparasol]

Ik had je ticket al gezien, gokje: staat over 6 maanden nog open
Waarom werkt het op mijn netwerk dan wel ok? Ik gebruik trouwens CCcam 2.2.1 protocol voor interconnect tussen 2 oscam servers en dan werk ik niet met extended oscam version.
Weet je zeker dat je geen loop in je cardserver netwerk hebt zitten, dus dat cardreader op box 1 ook via de sharereader op box 2 weer terug connecteert naar zichzelf?

[SatMann]

Voor iedereen hier die met ecmratelimit / ratelimitseconds en cooldown experimenteert:

Voordat je de verkeerde conclusie ik heb vandaag "even" de logging van oscam bestudeert met ecmratelimit op 1 en televisie + extra stream open:

Experimenteer met de ratelimitseconds, zet die eens naar 8 oid als je die stijf op 10 seconden hebt staan kan oscam soms een pass geven maar pas op 11 seconden na eerste ecm alsnog een extra ecm vragen waardoor de card bij 4 gelijktijdige ecm's alsnog in de lock kan gaan. De timings zijn dus niet krek dus je zult een beetje moeten compenseren.
Mocht je de kaart "opgevoert" hebben qua mhz dan kan het ook maar zo zijn dat de seconde klok van de kaart sneller tikt en daardoor niet 4 ecm's per 10 seconden maar 4 ecm's per 7 seconden de lock al triggert.

Mocht je cooldown ook inzetten:

Met cooldown 60,1200 (na 60 seconden ratelimit instellen) moet je compenseren voor de ecm rate in geval van CDS dus minimaal 10 seconden aftrekken om veilig te zitten.
cooldown 50,1200 dus.

wat dus bevestigd dat wij met ratelimit 3 en 10 seconden de kaart niet in lock krijgen, met 4 10 en dan wat zot doen ga je in lock.
blij dat een andere partij het nu ook eens grondig testte, waarvoor dank !

[Erik Slagter]

Ik had je ticket al gezien, gokje: staat over 6 maanden nog open

En over 12 maanden ook nog wel

Waarom werkt het op mijn netwerk dan wel ok? Ik gebruik trouwens CCcam 2.2.1 protocol voor interconnect tussen 2 oscam servers en dan werk ik niet met extended oscam version.

Misschien kun je eens camd35 of cs378x protocol proberen? Inter-oscam worden die aangeraden en het grote voordeel is dat het een berg geheugen op de client scheelt, die hoeft de beschikbare caid's niet bij te houden. Ik herinner me dat het niet altijd zo geweest is. Men heeft ooit in een svn commit diverse protocollen "meer robuust" gemaakt en volgens mij heb ik sinds die tijd hier last van.

Weet je zeker dat je geen loop in je cardserver netwerk hebt zitten, dus dat cardreader op box 1 ook via de sharereader op box 2 weer terug connecteert naar zichzelf?

Nee ik gebruik geen cacheex Mij client is echt heel simpel, alles naar de dm8000 waar de kaart in zit.

Edited by Erik Slagter, 17 January 2012 - 19:14.

[theparasol]

Cacheex is bij lan servers ook niet nuttig, gebruik ik ook niet. Pas gewoon inter connect protocol eens aan naar CCcam, het werkt bij jou immers nu ook al niet (en bij mij wel!)

Edited by theparasol, 17 January 2012 - 19:17.

[Erik Slagter]

Ik zeg cacheex omdat dat dat enige reden is waarom je een client heen-en-weer zou laten connecten naar een server. En nee, dat heb ik dus niet.

Met het cccam protocol heb ik ook disconnects, staat ook in het ticket.

Hij connect daarna meteen weer, het werkt dus wel, maar met soms enige vertraging. Weet jij zeker dat jij nooit disconnects hebt dan? Uit de log?

[theparasol]

Yep.. harstikke strakke logs over en weer. Zowel op mijn DM800HD PVR als mijn NAS waar de ARM versie op draait.

[Erik Slagter]

Hmmm, vaag. Nog even ter toelichting: ik kan een flood ping met payload size > 1300 doen naar beide boxen (helaas niet box-naar-box omdat de busybox ping dat niet kan) zonder packet loss. Dus het is geen netwerk-probleem en geen mtu-probleem Ook ftp van de ene box naar de andere en v.v. geeft de maximaal haalbare throughput. Ben ik nou gek dan?

Nog ziets, de server klaagt over een packet van size "0", ook als ik tcp (cs378x) gebruik. Met tcp kan dat nooit door een netwerk-probleem komen.

[theparasol]

Nee helder... lijkt me een spraakprobleem inderdaad.

Draai je trouwens zelfde oscam revisions op beide apparaten

[posixx]

Hmmm, vaag. Nog even ter toelichting: ik kan een flood ping met payload size > 1300 doen naar beide boxen (helaas niet box-naar-box omdat de busybox ping dat niet kan) zonder packet loss. Dus het is geen netwerk-probleem en geen mtu-probleem Ook ftp van de ene box naar de andere en v.v. geeft de maximaal haalbare throughput. Ben ik nou gek dan?

Nog ziets, de server klaagt over een packet van size "0", ook als ik tcp (cs378x) gebruik. Met tcp kan dat nooit door een netwerk-probleem komen.

Te lang topic om het even op te zoeken, maar Erik: heb je ook mgcamd of cccam als client gebruikt? Hier ook geen enkel probleem..

[posixx]

@Erik Slagter: en om je netwerk helemaal uit te sluiten: maak effe een crosscable, geef eventueel beide boxen een vast ip en en verbind de 2 boxen rechtstreeks. Als je dan nog disconnects krijgt ligt het aan je boxen of aan oscam.

[Erik Slagter]

Draai je trouwens zelfde oscam revisions op beide apparaten

Meestal wel, soms loopt er 1 een paar dagen achter, nog geen verschil gemerkt.

[theparasol]

@Erik Slagter: en om je netwerk helemaal uit te sluiten: maak effe een crosscable, geef eventueel beide boxen een vast ip en en verbind de 2 boxen rechtstreeks. Als je dan nog disconnects krijgt ligt het aan je boxen of aan oscam.

Vette onzin... meeste apparatuur en switches zijn al auto mtx. Daarbij ls het op tcp/ip layer correct werkt zit het in de application layer.

@Eric: ik werk met CCcam protocol ter interconnect maar niet met extended oscam CCcam protocol, dat ook geprobeert?

[Erik Slagter]

Te lang topic om het even op te zoeken, maar Erik: heb je ook mgcamd of cccam als client gebruikt? Hier ook geen enkel probleem..

Ik heb laatst weer eens even naar mgcamd gekeken. Die configfile is niet te doen! Allemaal meuk waar je nooit wat mee gaat doen en dan staan sommige settings weer in een anders file, die dan weer afgeleid is van newcamd, die niemand meer gebruikt. Het stond me zo tegen dat ik 'm meteen er weer afgegooid heb. Volgens mij is er ook al vijf jaar serieus niet meer ontwikkeld aan mgcamd.

Cccam zou ik eventueel nog kunnen proberen.

Maar eigenlijk vind ik dat oscam het gewoon goed moet doen ;-)