43 replies to this topic

[MiLo]

Typ een keer "ulimit -s 512" in de shell waar je oscam start (is ook leuk voor E2) en kijk wat er gebeurt met het vermeende memory gebruik.

[aardbei]

even afgezien van dat memory-gebruik, er is wel wat mis met de combo nieuwste vu kernel's oscam + mgcamd op één box

@Willy, jammer dat die B parameter niet voldoende hielp, ik heb hier helaas geen vu om mee te kunnen helpen met zoeken. Maar even terug naar een ouder image denk ik

[mrbeam]

]Ik heb ook al tijdje met een DB8000 en een ET9000 dezelfde problemen, maar dan met CCCam 2.2.1 en 2.3.0.
Met veel CPU bedoel ik 50% load, wat me 1 core lijkt. Dat zal wel wel een soort dual core zijn, dus 2 core's bij elkaar opgeteld is 100%.

Een DM500HD met exact dezelfde smartkaart en OpenPLI versie heeft hier geen last van. Ik heb hier dagen lang en vele uren mee getest.

[SatMann]

idd, ik heb de hele handel oscam/mgcamd op dm500HD draaien, die doet het opmerkelijk beter, stabieler.

de vu's zijn nu gewoon met mgcamd 1.38 met B 06 waarde en dat verloopt voorlopig vlot, maar toch straf dat met het uitkomen van de vu nieuwe kernel deze problemen wel heel sterk overal terug komen...zal wel een probleempje zijn, maar ja...waar te zoeken

[doglover]

Typ een keer "ulimit -s 512" in de shell waar je oscam start (is ook leuk voor E2) en kijk wat er gebeurt met het vermeende memory gebruik.

Milo: Dit kan allemaal wel waar zijn. Feit blijft dat het op de VU+ fout blijft lopen. En zolang jij (en andere ontwikkelaars) aan dit idee blijven hangen - die is niet erg, wordt er niet naar een oplossing gezocht.

Dit " hoge mem" gebruik kan dan wel iets zijn wat er niets mee te maken heeft. Maar de DM boxen hebben dit niet.

Is Oscam fout, of is OpenOLi fout of is de het de fout van de kernel. Wie zal het zeggen. Ik weet het niet. Daarvoor heb ik niet de kennis.

Maar nog eens herhalen: Op een VU+ duo blijft het fout lopen. Trouwens in het verleden zijn er ook al veel fouten met Oscam op een VU+ duo geweest met zwart beeld tot gevolg. Ik heb daar nooit een goede oplossing voor gezien, behalve een heleboel gegoochel in de DVB-api.

Willy

[doglover]

]Ik heb ook al tijdje met een DB8000 en een ET9000 dezelfde problemen, maar dan met CCCam 2.2.1 en 2.3.0.
Met veel CPU bedoel ik 50% load, wat me 1 core lijkt. Dat zal wel wel een soort dual core zijn, dus 2 core's bij elkaar opgeteld is 100%.

Een DM500HD met exact dezelfde smartkaart en OpenPLI versie heeft hier geen last van. Ik heb hier dagen lang en vele uren mee getest.

Is dit met alleen CCcam of CCcam in combinatie met Oscam?

Willy

[SatMann]

willy,

ik verdenk de kernel die voor problemen zorgt.
als ik mij niet vergis (mijn prog kennis is niet zo groot) als oscam tegen mgcamd moet "praten" op dezelfde box verloopt dit ook via de libcrypto dinges...het kan zijn dat net daar in combi met kernel iets mis gaat...want het communiceren tussen oscam en mgcamd is een heel gevoelig iets dat 100% perfect moet verlopen, zoniet is het feest

[MiLo]

Ik heb met oscam op de ET nooit problemen gezien, en die draait al heel lang een 3.x kernel. Dat virtual memory gebruik zie je met CCcam ook, en ik zie het ook op de 7025 met oscam. Dus niks nieuws onder de zon wat mij betreft. Ik wil jullie daarmee alleen maar helpen in de zin dat je in die hoek niet verder hoeft te zoeken.

In het debuggen van een closed-source blob als mgcam ga ik geen tijd steken.

[SatMann]

Milo,

het is wel als oscam EN mgcamd (2X bin's dus) draaien op dezelfde box, ze moeten echt samen draaien om die problemen te hebben.
Draai 1 apart op de vu, das geen probleem enkel als ze samen "iets" moeten doen op die 3.x.
uiteraard dat je niet in closed source gaat zoeken.
Wij stellen alleen maar vast wat onze bevindingen zijn

[mrbeam]

]Ik heb ook al tijdje met een DB8000 en een ET9000 dezelfde problemen, maar dan met CCCam 2.2.1 en 2.3.0.
Met veel CPU bedoel ik 50% load, wat me 1 core lijkt. Dat zal wel wel een soort dual core zijn, dus 2 core's bij elkaar opgeteld is 100%.

Een DM500HD met exact dezelfde smartkaart en OpenPLI versie heeft hier geen last van. Ik heb hier dagen lang en vele uren mee getest.

Is dit met alleen CCcam of CCcam in combinatie met Oscam?

Enkel CCcam. DM500HD werkt foutloos.

[Henksat]

Ik wil me nergens mee bemoeien, ik draai geen oscam op de box, wél op een linux bakkie.
Ik weet ook niet welke oscam versie in de huidige feed staat, mij staat bij dat Milo deze "vast" had gezet op een bepaalde versie, maar onlangs hadden de i386 versies ook last van een hoger CPU gebruik, dit is inmiddels wel weer verholpen.

`t is maar een idee................

[theparasol]

Ik weet ook niet welke oscam versie in de huidige feed staat, mij staat bij dat Milo deze "vast" had gezet op een bepaalde versie

Klopt, ivm build issues images, maar dat is alweer gefixed. Het gaat hier trouwens om oscam-experimental die compiled iedere image build de laatste svn versie van oscam.
Afgelopen nacht was dat 1.20 rev 6197
Ik lees meer over oscam icm vu's, moet iets hardware specifieks zijn en de oorzaak al je het mijn vraagt zit in oscam code en niet in openpli.

[littlesat]

Milo heeft naar de fix de versies weer losgelaten...

[WimV]

Ik weet ook niet welke oscam versie in de huidige feed staat, mij staat bij dat Milo deze "vast" had gezet op een bepaalde versie

Klopt, ivm build issues images, maar dat is alweer gefixed. Het gaat hier trouwens om oscam-experimental die compiled iedere image build de laatste svn versie van oscam.
Afgelopen nacht was dat 1.20 rev 6197
Ik lees meer over oscam icm vu's, moet iets hardware specifieks zijn en de oorzaak al je het mijn vraagt zit in oscam code en niet in openpli.

[WimV]

Kan niet meer aanpassen ,sorry !

Vraag gaat over oscam unstable.
Wanneer je pli update gaat oscam dan mee ?

En wat is er tegen te doen, dus pli updaten en oscam build niet.
Is hier stabiel en krijg mijn kaart update's.

Nogmaals sorry voor de eerste post maar was weg voor ik er iets bij kon zetten.

Wim

[adri]

Kan niet meer aanpassen ,sorry !

Vraag gaat over oscam unstable.
Wanneer je pli update gaat oscam dan mee ?

En wat is er tegen te doen, dus pli updaten en oscam build niet.
Is hier stabiel en krijg mijn kaart update's.

Nogmaals sorry voor de eerste post maar was weg voor ik er iets bij kon zetten.

Wim

telnet naar je box.

opkg flag=hold oscam-experimental

Edited by adri, 6 January 2012 - 16:32.

[SatMann]

Wel eigenlijk een leuke opmerking.
Mss kunnen de ontwikkelaars volgende inbouwen:
Ze detecteren nu al wat je hebt bij update, waarom geen lijstje tonen met alles bv al aangevinkt maar dat je zelf dingen kan afvinken wat je niet wenst uptegraden voor je effectief dingen gaat uitvoeren tijdens de update.

Uiteraard is dit enkel op de applicaties, niet op systeemdingen....tes maar een gedacht he :-)

Edited by SatMann, 6 January 2012 - 16:43.

[SatMann]

Ik wil me nergens mee bemoeien, ik draai geen oscam op de box, wél op een linux bakkie.
Ik weet ook niet welke oscam versie in de huidige feed staat, mij staat bij dat Milo deze "vast" had gezet op een bepaalde versie, maar onlangs hadden de i386 versies ook last van een hoger CPU gebruik, dit is inmiddels wel weer verholpen.

`t is maar een idee................

Henksat zou je nog weten welke versie het was?
Mss zou mijn bovenstaande reply ivm vragen wat je wenst te upgraden van apps voor upgrade ni slecht zijn om daarover na te denken?

[WimV]

@ adri Thnx, ga ik proberen.

@ Satmann Is best een goed idee.

Wim

[SatMann]

@WimV,

ik vind het eigenlijk ook best leuk mocht dit voorzien worden, nu worden veel updates gedaan, maar soms weten mensen totaal niet wat ze effectief updaten...tot het mss niet was wat zij verwachten dat het was.

ik denk dat OpenPli nu zelf even moet bekijken of dit voor hen haalbaar is en of anderen dit een meerwaarde zou zijn...misschien na onderling overleg dat ze een soort poll of vraag opstarten, weten ze gelijk of er mensen zijn die dit ook wel zouden willen.

begrijpelijk dat ze niet voor iedere gril of voorstel een oplossing gaan maken ..tenzij het een zeer goed is