Client disconnects

[DBdrug]

Daarnaast gebeuren er ook disconnects van de user terwijl deze NIET idle is (zie midden post # 5).

 

En wat doet setting 'keepconnected' dan? Hoe verhoudt deze zich tot de 'clientmaxidle' en 'umaxidle'? Verder is 'keepalive' bij de user er ook nog... 

[theparasol]

Ik bemoei me niet met die tak van sport maar toch knap werk om zoveel verschillende parameters te bedenken. Dat het niet ok werkt verbaasd me niks!

Ik gebruik oscam enkel lokaal als dvbapi client dus heb er totaal geen last van

[Toppers]

Daarnaast gebeuren er ook disconnects van de user terwijl deze NIET idle is (zie midden post # 5).

 

En wat doet setting 'keepconnected' dan? Hoe verhoudt deze zich tot de 'clientmaxidle' en 'umaxidle'? Verder is 'keepalive' bij de user er ook nog... 

Sterker, sinds @blueven op Streamboard een andere oscam-developer te "kakken" heeft gezet middels een totale revert omdat zijn (@blueven) inbreng

beter en eenvoudiger zou zijn  (dus vele verschillende parameters voor "keepalive") is het behoorlijk mis met de binaries sinds svn 9799 (http://www.streamboard.tv/oscam/changeset/9799) o.a. veel mem-leak, ofwel overmatig groeiende users-memory, veel hoger CPU-verbruik en onnodig repeterende Seca3 reader voor 0100:00006A zodat de kaart in de stress geraakt.

 

Gebruik liever een binary tot max svn 9793 en gebruik enkel clientmaxidle  = 0 in oscam.conf !!!

[DBdrug]

Sterker, sinds @blueven op Streamboard een andere oscam-developer te "kakken" heeft gezet middels een totale revert omdat zijn (@blueven) inbreng

beter en eenvoudiger zou zijn  (dus vele verschillende parameters voor "keepalive") is het behoorlijk mis met de binaries sinds svn 9799 (http://www.streamboard.tv/oscam/changeset/9799) o.a. veel mem-leak, ofwel overmatig groeiende users-memory, veel hoger CPU-verbruik en onnodig repeterende Seca3 reader voor 0100:00006A zodat de kaart in de stress geraakt.

 

Gebruik liever een binary tot max svn 9793 en gebruik enkel clientmaxidle  = 0 in oscam.conf !!!

 

Vandaar dat ik de laatste tijd al 2x een kaart in sid-lock heb gehad, terwijl dit al een hele poos daarvoor niet meer is gebeurd!

 

Tsja... maar eens een melding posten op het Streamboard... hopelijk wordt het gefixt...

[Toppers]

Vandaar dat ik de laatste tijd al 2x een kaart in sid-lock heb gehad, terwijl dit al een hele poos daarvoor niet meer is gebeurd!

 

Tsja... maar eens een melding posten op het Streamboard... hopelijk wordt het gefixt...

Ben jij @poedel op streamboard ?

Kijk anders even hier; http://www.streamboard.tv/oscam/ticket/3813#comment:8

 

Vandaag heb ik een proef lopen met svn 9790. In tegenstelling bij laatste versies vanaf 9799 tot heden 9843 geen mem-leak, ofwel overmatig groeiende users-memory, geen hoger CPU-verbruik en ook niet meer een repeterende Seca3 reader voor/met provider 0100:00006A zodat de kaart in de stress geraakt.

[DBdrug]

Yep... that's me...Schijnbaar is er al een niet publieke fix... waarom deze oplossing closed source is, is me niet duidelijk.

 

Zal ook maar terug naar 9790... valt me op dat tickets op het streamboard de laatste wel erg 'gemakkelijk' worden gesloten... (zie ook http://www.streamboard.tv/oscam/ticket/3822). 

[DBdrug]

Hopelijk komt de fix snel publiek beschikbaar.

5 september 2014 aangepast door DBdrug

[theparasol]

Je kunt de ratelimiter zelf inspecteren als je oscam in -d8 log level start.

 

bv

 

/usr/bin/oscam --config-dir /etc/tuxbox/config/oscam -d8 --pidfile /tmp/oscam.pid --restart 2 --utf8

[DBdrug]

Probleem zit dus (mede) in de ratelimiter? Maar dat verklaart toch niet de disconnectende users? Mogelijk wel het groeiende geheugen gebruik en/of het hogere CPU belasting, alsmede de extra Seca aanvragen richting kaart met als (mogelijk) gevolg een sid-lock.

 

Maar tussen changeset 9791 en 9799 zit toch geen aanpassing voor de ratelimiter?

 

 

Dit is de changeset van de niet publieke versie:

 

a new parameter

 

lb_filter_time                = 150

 

filter for changes of average ECM time

 

 

tested on platforms:  Ubuntu 14.04  and VU+ Uno

solved: High cpu consumption time /a new algorithm for deleting all structures/

solved: a lot of memory leaks

 

module cwc cycle check uses balanced b-tree, so we can increase max. ECM count to 20000 

all modules are thread safe

 

it contains

http://www.streamboard.tv/oscam/changeset/9829

http://www.streamboard.tv/oscam/changeset/9830

http://www.streamboard.tv/oscam/changeset/9725

http://www.streamboard.tv/oscam/changeset/9667

http://www.streamboard.tv/oscam/changeset/9792

http://www.streamboard.tv/oscam/changeset/9771

http://www.streamboard.tv/oscam/changeset/9771 9794,9795,9796 ...9805

http://www.streamboard.tv/oscam/changeset/9806

 

--------------------------------------------------------------------------------

Now you can use for cryptoworks readers

time and expiration date of writing EMM

 

emmallowedtimeframe           = 19:30-22:30

expdateemm                    = 2014-08-21

 

solved issues: segfault in oscam-ecm.c

solved issues: cpu consumption time in module cwc-cycle-check.c =>

a new algorithm B+tree + AVL

repared an internal time marker

 

release:streamboard-1

increased thread stack memory

parallel processing for module cwc cycle check

deleting unused data in cwc module check now works

solved: freezing the application

[theparasol]

 

 

Maar tussen changeset 9791 en 9799 zit toch geen aanpassing voor de ratelimiter?

 

 

 

toch wel:

 

http://www.streamboard.tv/oscam/changeset?old=9799&old_path=trunk%2Foscam-reader.c&new=&new_path=trunk%2Foscam-reader.c

 

Maar die extra gone <0 zal de boel niet verstoren, tenminste ik kan niets bedenken!

 

Voor wat betreft die niet publieke patch:

 

Opensource gedachte is ver te zoeken, maar goed zijn we toch wel gewend. Alles pakken wat je kunt gebruiken en niets teruggeven. Gebeurt overal, kan er echt niet mee zitten. Als iemand het lef heeft mij zo'n private patch aan te leveren prik ik hem zo de trunk van oscam in.

5 september 2014 aangepast door theparasol

[Gast dropje20]

maar is er al een oplossing dan ik zit er ook mee

[DBdrug]

Nope... nog altijd zelfde...

[Gast dropje20]

Hoi, beste mensen thuis had ik steeds in me netwerk tussen me 2 dreamboxen een disconnects fout,

 

en ook veder dan ik wil Wi-Fi aan het op me telefoon op laptop wel verbindeng maar geen internet

 

ik wil jullie laten wetten dan het aan de ziggo modem\router licht!

 

 

 

ik heb had met ziggo gebeld gevraagd als de router in brugmodus willen zetten nu heb ik dan een goeie router er op aan gesloten en alles werkt nu zo als het hoort,

 

 

 

als je met ziggo belt en je doet het in over leg dan krijg je van ziggo 45 euro korting op je eerst volgende rekening

 

mijn als ik nu draadloos een bestand van me Nas haal pak ik zoon 300mb dat was eerder met de router van ziggo net geen 80mb

 

 

 

 

 

 

 

 

 

 

[Gast Mimisiku]

OMG!!

[beeheap]

En in het Nederlands?