43 replies to this topic

[SatMann]

heren

hebben jullie ook al opgemerkt dat bij de laatste images van OpenPli met nieuwe kernel de mem heel hoog gaat pieken?
Ook oscam-experimental gaat soms tot 83% en na lang draaien gaat deze door tot 135% mem gebruik?

is er iets mis met de image/kernel waardoor het op de vu's niet zo lekker gaat?

want sedert ik de nieuwe images in mijn vu's zette, krijg ik met oscam/mgcamd en die nieuwe kernel wel problemen zoals zwart beeld en toch perfect afname van mijn local.

iemand een idee?

greetz

Attached Files

•  screen.JPG   65.82KB   64 downloads

[MiLo]

"VSZ" = Virtual size. That is the "address space" in use, not actual RAM. For example, starting a thread usually takes 8MB for the stack, even though only a few k of that 8MB is actually occupying real memory.

You may have noticed that your box still has over 50MB available RAM (free + cache).

[SatMann]

Hi Milo

wel hier de hele dag getest met verschillende scenario's en dat kan ik 1op1 reproduceren, dus er zit iets in de kernels die dit niet goed doet werken en dat enkel met de vu's :

test 1 : vu solo met laatste image openpli met kernel samen met mgcamd/oscam , snel zappen = zwart beeld(uiteraard op mijne eigen kaarten ! )

test 2 : vu duo met laatste openpli met enkel mgcamd die connecteerd naar mijn vu solo = perfect.

test 3: dm500hd met oscam en mgcamd = perfect

test 4 : vu solo met laatste open pli met enkel mgcamd naar dm500 oscam/mgcamd = perfect

test 5 : vu solo met image van 28/12/2011 (dus oude kernels) met oscam en mgcamd = perfect

dus na 4 uur flashen en testen en terug flashen kan ik dat keer op keer reproduceren.
nieuwe image van openpli met oscam/mgcamd (moet wel deze combinatie zijn, dus oscam cs #6189 en apart mgcamd 1.38) werkt absoluut niet lekker. ook niet met mgcamd 1.35 het is dus echt tussen die 2 (oscam/mgcamd) dat het niet lekker loopt met de nieuwe kernels.

net hetzelfde qua oscam en mgcamd op de image van 28/12/2011 = perfect.

hopelijk hebben jullie hier iets aan.

Edited by SatMann, 3 January 2012 - 16:44.

[doglover]

Een vu+ duo met de image van vandaag loopt ook niet goed met de combinatie oscam+mgcamd

Zwart beeld en toch ECM's

Met CCcam alleen loopt het wel goed.

Willy

[SatMann]

idd willy

het probleem ligt bij de nieuwe kernels van de vu en de mgcamd /oscam.

na een dag testen ben ik daar nu wel 10000% zeker van
hopelijk komt een fix voor de kernels of mgcamd of wat dan ook uit.

op blackhole, vix, ... allemaal met nieuwe kernel = dezelfde problemen.

Edited by SatMann, 3 January 2012 - 17:05.

[Roymar]

Hier ook vandaag nog geupdate en geen enkel zwart beeld met de combo oscam mgcamd, overigens ik gebruik wel de mgcamd uit de feed

[SatMann]

met de mgcamd 1.35 had ik ook prijs en niet alleen ik, nog een paar andere

blijkbaar nogal wat andere images met nieuwe kernel vu die ook problemen hebben....nu dan maar dm500HD met oscam/mgcamd en de vu's enkel mgcamd met laatste openpli = geen enkel probleem meer

[Roymar]

Hier is het geheugengebruik van oscam inderdaad ook erg hoog, maar nog geen problemen met het beeld hier

Mem: 135604K used, 2640K free, 0K shrd, 6876K buff, 55264K cached
CPU: 2% usr 1% sys 1% nic 92% idle 0% io 0% irq 1% sirq
Load average: 0.11 0.26 0.51 2/102 2032
PID PPID USER STAT VSZ %MEM %CPU COMMAND
419 414 root S 113m 84% 5% /usr/bin/enigma2
345 344 root S < 143m 106% 1% /usr/bin/oscam-experimental -b -r 2 -
137 2 root SW 0 0% 0% [sched_high]
418 1 root S 37576 27% 0% /usr/bin/mgcamd
1936 1922 root R 3264 2% 0% top
385 1 root S 13576 10% 0% /usr/sbin/smbd
387 385 root S 13576 10% 0% /usr/sbin/smbd
388 1 root S 6964 5% 0% /usr/sbin/nmbd
344 1 root S 4868 4% 0% /usr/bin/oscam-experimental -b -r 2 -
407 1 avahi S 3500 3% 0% avahi-daemon: running [vuduo.local]
408 407 avahi S 3500 3% 0% avahi-daemon: chroot helper
381 1 root S 3312 2% 0% /usr/sbin/inetd
1921 381 root S 3268 2% 0% telnetd
1922 1921 root S 3264 2% 0% -sh
391 1 root S 3012 2% 0% /sbin/syslogd -n -C64 -m 20
393 1 root S 2948 2% 0% /sbin/klogd -n
414 1 root S 2948 2% 0% /bin/sh /usr/bin/enigma2.sh
371 1 messageb S 2832 2% 0% /usr/bin/dbus-daemon --system
378 1 root S 2424 2% 0% /usr/sbin/dropbear -r /etc/dropbear/d
1925 1923 root S 2404 2% 0% vsftpd

[aardbei]

@Roymar,

wat voor box zie je dat mee?


mvrgr

[SatMann]

euh : 106% 1% /usr/bin/oscam-experimental -b -r 2 -
vind je dat zelf niet veel?
ik zie ook dat bij de versie #6189 dit langzaam maar zeker omhoog gaat...nog iemand?

Edited by SatMann, 3 January 2012 - 19:37.

[MiLo]

Is virtueel geheugen (adresruimte), heeft bijna niks met RAM gebruik te maken.

[SatMann]

okey thanks Milo (again :-) )

[doglover]

Is virtueel geheugen (adresruimte), heeft bijna niks met RAM gebruik te maken.

Kan dan wel zo zijn, maar het feit blijft dat op een VU+ (duo en solo) de combinatie Oscam en mgcam problemen oplevert met zwarte schermen tot gevolg, en op een DM niet.

Willy

[Roymar]

@Roymar,

wat voor box zie je dat mee?


mvrgr

Met een Vu Duo

@satmann ik gaf al aan dat ik dat inderdaad wel veel vind, maar ik ondervind geen problemen met zwarteschermen of iets dergelijks en het zappen gaat gewoon snel

[SatMann]

@roymar

bij je B waarde in mg_cfg wat heb jij staan? 00 of 06?

[Roymar]

06

[aardbei]

ah, detectie boxtype wellicht stukgegaan vwb de combo nwe kernel mgcamd

[SatMann]

@aardbei,

zou het dan niet met 00 ook moeten gaan? autodetectie?

[aardbei]

kennelijk niet met die hogere kernel versie
je komt er op internet nog wel wat over tegen voor boxen die 'm hebben, de vu's en de et's

hier b.v.

http://www.world-of-...hp/t-14349.html

en dan met name deze tekst


im85288
29-12-11, 10:10
Mate if I say it works it works; I tried zapping to 30 channels still no lock up on the new kernel; because you asked so nice look at the B line

From what I understand you need to change the B Line to { 06 }

Edited by aardbei, 3 January 2012 - 20:44.

[doglover]

From what I understand you need to change the B Line to { 06 }

Werkt maar gedeeltelijk.
ja het voorkomt zwart beeld tijdens het zappen. Maar als je tegelijkertijd een opname plant dan gaat dit verkeerd. Zwarte opname.
Uiteindelijk loopt de CAM zelfs vast.

Dit alles op een VU+ duo.
Ligt de oorzaak nu bij Oscam of MGcam? Ik weet het niet.
Feit is dat met het top commando je kunt zien dat Oscam erorm groot wordt en veel CPU tijd inpikt.
Naar het schijnt gebeurt dit op een dreambox niet.

Wat is er mis met Oscam op een VU+ duo?

Willy