1176 replies to this topic

[Erik Slagter]

Teletext caching uitzetten is inderdaad een slimme zet als je al problemen met geheugenverbruik hebt.

[kwajoep]

inmiddels het volgende gedaan, laatste pli er opnieuw opgezet, ccam2.09 erop gezet ipv 2.30, wireless plugin uit pli verwijderd, teletext caching uit gezet. en verdomd nog geen vastloper meer gehad.

En hoelang (dagen of uren) gaat het al goed ?

[petalo]

nog steeds up, al 2 dagen..!

ook heb ik de 2 comando geven die geadviseerd zijn, was ik nog vergeten te melden.

Ook draaid de box een stuk soepeler op cccam2.09 dat viel me op.

Edited by petalo, 18 April 2012 - 11:05.

[Erik Slagter]

ook heb ik de 2 comando geven die geadviseerd zijn, was ik nog vergeten te melden.

Dat zijn die sysconfig commando's?

[petalo]

deze commando's zijn het...

Je kunt ook de workaround proberen die hier elders in het topic genoemd staat. In telnet moet je dan het volgende commando geven:

echo 'vm.min_free_kbytes=8192' >> /etc/sysctl.conf
en
echo 8192 >> /proc/sys/vm/min_free_kbytes

Edited by petalo, 18 April 2012 - 13:53.

[Roymar]

nog steeds up, al 2 dagen..!

ook heb ik de 2 comando geven die geadviseerd zijn, was ik nog vergeten te melden.

Ook draaid de box een stuk soepeler op cccam2.09 dat viel me op.

CCcam 2.09 doet het soepel inderdaad, maar heeft de bug dat er geen geluid doorgegeven wordt op Discovery HD

[petalo]

nu al 3 dagen up! lijkt goed te gaan nu..

voor die discovery hd, selecteer ik dan wel ff cccam 2.21..!

en voor de andere zenders ga ik terug naar cccam2.09 het zappen gaat wel 1x zo snel.

Edited by petalo, 19 April 2012 - 09:15.

[teo1966]

Teletext caching uitzetten is inderdaad een slimme zet als je al problemen met geheugenverbruik hebt.

hoeveel is eigenlijk het geheugen gebruik van teletext caching ?

[josjansen]

nu al 3 dagen up! lijkt goed te gaan nu..

voor die discovery hd, selecteer ik dan wel ff cccam 2.21..!

en voor de andere zenders ga ik terug naar cccam2.09 het zappen gaat wel 1x zo snel.

Wat raar bij mij werkt de CCcam 2.09 op geen enkele zender. Of moet er dan iets in de CCcam.cfg worden aangepast?

[BBsat]

nu al 3 dagen up! lijkt goed te gaan nu..

voor die discovery hd, selecteer ik dan wel ff cccam 2.21..!

en voor de andere zenders ga ik terug naar cccam2.09 het zappen gaat wel 1x zo snel.

Wat raar bij mij werkt de CCcam 2.09 op geen enkele zender. Of moet er dan iets in de CCcam.cfg worden aangepast?

Bij mij gaat het zappen ook veel sneller met 2.09
dat is maar goed ook want ik krijg op geen enkele zender van mijn CD kaart beeld
En dan is het maar beter als je weer lekker snel weg kunt zappen
Ben weer terug naar de nieuwste versie

[Rob van der Does]

Nog even een kleine update: De VU+ is niet meer gecrasht sinds de toegepaste workaround, het kan uiteraard toeval zijn omdat ik ook uit andere bron andere geluiden hoor, maar de box draait nu een week probleemloos.

Hier loopt inmiddels test #6, allemaal met nieuwe drivers & kernel configs van VU+. Hoewel t/m test #5 het resultaat slecht was (= systemcrash na 24-60 uur uptime) geeft dit wel aan dat VU+ er mee bezig is.

Na 8 testen met steeds verschillende kernels/drivers en nog steeds een systeemcrash na een beperkt aantal draaiuren, heeft VU+ besloten de zaak in huis te gaan onderzoeken. Mijn box zit in het vliegtuig.......
Maar in ieder geval heeft het er alle schijn van dat zij er serieus op ingaan.

En de afloop is: teleurstellend..........

Na anderhalve week op de Koreaanse pijnbank te hebben gelegen, heeft mijn DUO geen krimp gegeven. Geen enkele vastloper heeft men weten te bewerkstelligen. Ik roep even in de herinnering dat mijn box hier in huis meestal binnen 24 uur vastliep (systeemcrash), op OI, VTI, PLI & ViX, ongeachte de settings en de geïnstalleerde plugins. Wel geeft men duidelijk aan de problemen niet te ontkennen en verder onderzoek te zullen plegen.
Verder heeft men mij nu verzocht de DUO weer in bedrijf te stellen (zal wel medio volgende week zijn dat ik hem weer in huis heb) maar nu zonder LAN-aansluiting en te bezien hoe de box zich nu gedraagt.
Men stelt dus impliciet een verdenking richting LAN (nic-problemen?) te hebben, zonder verder enige informatie daaromtrent te geven.

We zullen het zien. Voorlopig vind ik het resultaat teleurstellend.
Wellicht een idee voor degenen die ook lijden onder de 'DUO-Systeemcrash-onder-kernel3.1' om eens te bezien hoe de box zich zonder ethernet-aansluiting gedraagt?

[petalo]

nou ik ben ook maar even weer met de softcam aan het klooien geweest, en hij blijft met cccam 2.09, 2.21, 2.30 gewoon stabiel!

het fijnst loopt hij op 2.09 maar deze heeft ook zo weer zijn beperkingen.

Ik krijg steeds meer de indruk dat teletext cashing op uit zetten de oplossing is, in combinatie met de 2 sys commando's.

ben erg benieuwd op het bij een ander nu ook stabiel draaid.

Gr Fred.

[Erik Slagter]

Ik krijg steeds meer de indruk dat teletext cashing op uit zetten de oplossing is, in combinatie met de 2 sys commando's.

Het is geen oplossing, je beperkt daarmee het geheugengebruik, waardoor het eigenlijke probleem minder snel optreedt. Het geheugengebruik van de teletext caching of de instelling van de sysconfig zijn op zich niet de oorzaak van het crashen.

[petalo]

klopt, het is misschien geen goede oplossing, maar ik kan nu wel weer normaal kijken met de vu+duo, zonder dat ik om de 2 uur een harde reset moet geven.

Wat nu de oorzaak is weet ik ook niet, wel krijg ik het idee dat het geheugen vol loopt, en dat er daardoor ook geen chraslog meer geschreven kan worden, omdat er simpelweg geen geheugen meer vrij is.

Maar Erik, wat is volgens jou dan de oorzaak van het probleem?

Gr Fred.

[littlesat]

De oplossing is eigenlijk dat VU zal de "bug" in hun drivers moet oplossen.... Zolang ze dat niet doen kunnen wij alleen maar wat simptomen bestrijden...

Maar als het uitschakelen van de Teletext cache helpt in combinatie met en een geheugeninstelling in een opstartscript ook... is dat het enige wat we kunnen doen....

Edited by littlesat, 19 April 2012 - 14:01.

[Erik Slagter]

Maar Erik, wat is volgens jou dan de oorzaak van het probleem?

Er zit een fout in de drivers (zie eerdere meldingen van ons daarover) en daar kunnen wij niks aan doen. Er zijn twee mogelijkheden: ofwel de drivers crashen de box als meer dan x procent van het geheugen vol zit (en dat is dan echt geheugen, niet virtueel zoals je met "top" opvraagt), ofwel de drivers zelf hebben een memory leak waardoor heel linux vastloopt. Dat is ook weer "echt" geheugen wat opraakt, en daar helpt swap of processen afschieten uiteindelijk ook niet meer tegen. De reden dat het met swap wel langer blijft werken is dat linux op die manier geheugen van processen kan afpakken (en op swap zetten), waardoor er weer even wat "echt" geheugen beschikbaar komt. Totdat alle processen uitgeswapt zijn en dan houdt het ook gewoon op. Geheugen van de kernel kan namelijk meestal niet uitgeswapt worden.

Genoeg informatie zo, of misschien een beetje teveel

[petalo]

nee duidelijk zo, het wachten is gewoon op een nieuwe bootloader met daarin een fix, tot die tijd is het pappen en nathouden dus.

Gr Fred.

Edited by petalo, 19 April 2012 - 14:35.

[Erik Slagter]

nee duidelijk zo, het wachten is gewoon op een nieuwe bootloader met daarin een fix, tot die tijd is het pappen en nathouden dus.

Drivers, dat is wat anders dan bootloader.

[petalo]

mmm, het probleem is na het laden van de nieuwe bootloader onstaan, het geheugen gebruik van de processor is toen ook aangepast, vandaar dat ik denk aan de bootloader...

[Pedro_Newbie]

Nee, het probleem is niet met de bootloader ontstaan, de bootloader was er al een tijdje maar door de meesten nog niet geflasht.
De problemen begonnen met de nieuwe kernel want toen werden ook meteen de nieuwe drivers daarvoor geïntroduceerd.

Edited by Pedro_Newbie, 19 April 2012 - 15:03.