240 replies to this topic

[Erik Slagter]

Ik ben ook heel geinteresseerd in wat de dm8000 doet met zram, zekers. Maar dat heeft alleen zin als je al problemen hebt

[catastrofus]

Hoezo denk je dat ik geen problemen heb?   Die andere 8000 draait PLi3, neemt veel op en wordt, pak 'm beet, 2 uurtjes per dag gebruikt om tv te kijken. Doet het dus al weken ok zonder een reboot!

Die ander draait PLi4, werkt op zich goed (wordt veel gebruikt voor tv kijken, ahum, daar is die voor eigenlijk) als je hem maar 2 x per week reboot of update (dus reboot).

Wil wel eens kijken of er iets is waarbij de (PLi4) uptime vergroot kan worden.

[Erik Slagter]

Aha okee, verkeerd onthouden dan.

[catastrofus]

Niet echt verkeerd onthouden maar er valt eigenlijk geen verwachting te maken over de uptime van die PLi4 8000. Soms draait ie weken zonder problemen en dan, bv dmv de partnerbox, beginnen de tandwielen maar vaak ook niet. Soms is het wisselen van bouqet al een probleem na een week maar soms ook niet. Vandaar de 2 updates per week, dan blijft hij het gewoon uitstekend goed doen.

Maar als dat wellicht beter zou kunnen wil ik die PLi4 8000 wel onderwerpen aan wat mogelijke verbeteringen.

[Erik Slagter]

Ik heb het niet zo extreem, maar wel opvallend vaker wachten dan met OpenPLi 2.1 (= oude kernel en drivers), vandaar dat die van mij weer 2.1 draait (met up2date enigma).

[catastrofus]

2.1 draaide super maar je wilt niet achter lopen qua ontwikkeling. Tenzij die ontwikkelingen voor (grote(re)) problemen gaan zorgen dan is 2.1 wellicht de/een oplossing.

Op dit moment overweeg ik dat eigenlijk nog niet. Het is goed vol te houden zo. En 2 x per week updaten is zo gek nog niet.

[Erik Slagter]

Ik maak zo af en toe een 2.1 image met de laatste enigma en plugins, persoonlijk mis ik daar in ieder geval niet zoveel aan qua nieuwigheid.

[wimpie007]

Lijkt me een mooi alternatief voor diegenen met problemen met de laatste versies...

[wimpie007]

ter info: Misschien interessant om te melden:

Mijn 'testfile' MKV die het snelst de box doet crashen, heeft als 1 van de sporen een vobsub ondertiteling die standaard wordt geactiveerd.

Die leidt tot het bliksemsnel oplopen van het geheugen, ALS er subs moeten getoond worden.

In stukken van de film waar geen conversaties plaatsvinden, is er quasi geen memleak, bij andere gaat het razendsnel.

Opletten dus met vobsubs! Ik zag liever GEEN ondersteuning dan een brakke!

 

groeten,

 

PS veel andere files genereren nog altijd memleaks, niet te herleiden tot bepaalde subs of DTSHD, maar daar blijft het binnen de perken...

[Erik Slagter]

Het is in feite geen memory leak, zie hierover de diverse eerdere threads die we erover hebben gehad. Want nogmaals, de xtrends en de xp heeft er geen last van!

 

Die vobsub kunnen we misschien nog eens naar kijken, maar ik betwijfel of het probleem in enigma zit.

 

Ik weet wel een heel simpele workaround dan, overigens. Met mkvmerge de vobsub track er uit halen en een srt file downloaden van internet en die toevoegen. Dan werkt het zeer waarschijnlijk wel en als bonus ziet het er nog veel beter uit ook (o.a. scherper).

[wimpie007]

Zou dit niet komen door de VU+ drivers die brak zijn? 't lijkt nochtans wel op een memleak: memory wordt niet terug vrijgegeven, ook niet na stoppen van de film.

Workaround is idd vrij simpel eenmaal je hebt vastgesteld wat 't probleem precies is. Dat heeft me meer werk gekost dan het slopen van de vobsub,,

[Zuppelan]

Waar kijk je naar om het geheugengebruik te bepalen? Als het in Enigma2 zit, dan zal je het Enigma2-proces steeds meer geheugen zien gebruiken. Als de driver geheugen lekt, dan moet dat zichtbaar zijn in /proc/slabinfo.

[Erik Slagter]

Ja en nee. Niet alles is daar in terug te vinden. En dan is er ook nog de fragmentatie.

 

Hoe dan ook is de discussie hypothetisch, want van de drivers is geen source beschikbaar en kunnen we dus zowiezo niks mee doen. Hoe graag we ook zouden willen.

[Zuppelan]

Dat dat niet het hele verhaal is, is de discussie niet: Wimpie07 meldt een groeiend Enigma2-proces. Dan is naar de drivers verwijzen (weer eens) erg voorbarig. De juiste stap is gaan uitzoeken waarom Enigma2 zoveel geheugen aanhoudt. Een juiste test lijkt me zijn bestand op een andere ontvanger afspelen en kijken of daar dezelfde groei waar te nemen is.

[littlesat]

Als er meerder ondertitels zijn in een mkv dan weten we al dat er door een bug in gstreamer het geheugengebruik gaat toenemen. En aangezien die vu duo de meest ram geheugen beperkte box is (112 MB) zal de vu duo er van alle boxen het eerste last van hebben.
Het echte issue zit een gstreamer...
En daar bovenop zit nog een fragmantatie probleem bij de niet et en xp boxen met kernels in de 3 range....

[Erik Slagter]

Tot een jaar of twee geleden gingen er dingen echt fout bij media met meerdere subs. Volgens mij is dat nu echt wel opgelost.

Het kan natuurlijk altijd zijn dat er in die code een memory leak zit, maar ik geloof niet dat je dat zo 1,2,3 aan het "geheugengebruik" van enigma kunt zien. Ook libc (malloc enz.) heeft een heel eigen systeem van memory management waarbij, om fragmentatie te voorkomen, geheugen zelden direct teruggegegeven wordt aan de kernel. De enige echte goede manier om er achter te komen is om enigma onder valgrind (of iets vergelijkbaars) te draaien, maar dat is niet zo heel simpel omdat je zowiezo bij voorkeur van alle libs dan debug-versies hebt (met symbols), ook van gstreamer dus, dat maakt het pinpointen een stuk makkelijker. Ik zie dat valgrind wel wordt aangeboden via OE, het zit alleen niet in de feed bij ons. Misschien dat pieterg of MiLo die even wil toevoegen dan, kan nog interessant worden... Meten = weten

 

De dm8000 en de dm800 hebben ook zo weinig geheugen, overigens.

[littlesat]

De DM800(0) hebben dacht ok 128 MB RAM beschikbaar, de VU Duo 112 MB Ram... dat is voor de DMM boxen nog altijd 16 MB meer....

[Erik Slagter]

10%

[Rob van der Does]

Eeuuhhh 14,3%

[blzr]

En aangezien die vu duo de meest ram geheugen beperkte box is (112 MB)...

 
hmm:

root@vuduo:~# cat /proc/meminfo 
MemTotal:         138156 kB