Gast Geplaatst: 27 januari 2007 Geplaatst: 27 januari 2007 Citaat: Citaat: Volgens mij komen de geleerden er niet uit, het blijft zo stil! Groet Gerard Als er iets te melden valt dan laten we 't weten. Het zou toch wel prettig zijn om te weten of jullie de fout kunnen reproduceren. Groet Gerard
nbrok Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Hallo allemaal, Ik heb een workaround bedacht en die scheen tot gisteren te werken <img src="/forums/images/graemlins/frown.gif" alt="" /> Afgelopen week heb ik samen met een programmeur die ervaring had met C++ de sources van Enigma bekeken. Hij vond het niet vreemd dat hierdoor geheugenproblemen wordt veroorzaakt. (Probeer ook maar eens X te runnen op een embedded x86 systeem met maar 32 MB Geheugen zonder swap. Na een tijdje crashed X ook. Voor de mensen die Unix niet zo goed kennen: X is een grafische schil zodat je net zo als bij Windows grafische applicaties kan runnen zoals KDE enzo.) Ikzelf ben niet zo vertrouwd met C++ maar ik heb van hem begrepen dat er in de C++ standaardlib een new en delete functie bestaat om geheugen te reserveren en weer vrij te geven. Volgens zijn zeggen wordt hier vaak mee gezondigd, en wordt deze functie niet op de juiste wijze toegepast. <img src="/forums/images/graemlins/crazy.gif" alt="" /> De workaround tegen het steeds minder worden van het werkgeheugen was het uploaden van een grote file in /tmp en daarna deze file in /tmp te wissen. Dan komt er ineens meer geheugen vrij dat eerst werd vastgehouden. Maar helaas, ik had gisteren iets met ngrab opgenomen en vannacht werd Enigma gereset. (Hij stond vanochtend op WDR ipv RADIO2, terwijl ik hem gisteren op RADIO2 had gezet voordat ik naar bed ging.) Dit zal wel een andere oorzaak hebben dan het in deze topic besproken crashen van Enigma, bij het afspelen van videobestanden. Maar ik denk dat het geheugenmanagement in de dreambox beter geregeld moet kunnen worden. Voor de PLI-ontwikkelaars: Dit is een theorie van mij, het kan zijn dat ik de verkeerde richting in denk. Kijk in ieder geval ook eens in de Enigma sources.. Het is een hels karwei om in de spaghetti wegwijs te worden. <img src="/forums/images/graemlins/confused.gif" alt="" /> Groeten, Nick Groeten, Nick Astra1, 2 en 3 op triax-schotel 89 cm
dAF2000 Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Citaat: Voor de PLI-ontwikkelaars: Dit is een theorie van mij, het kan zijn dat ik de verkeerde richting in denk. Kijk in ieder geval ook eens in de Enigma sources.. Het is een hels karwei om in de spaghetti wegwijs te worden. <img src="/forums/images/graemlins/confused.gif" alt="" /> Het is duidelijk dat je in 't geval van een geheugenprobleem naar de new's/delete's (of soortgelijke constructies) moet kijken. En Enigma is inderdaad nogal spaghetti en niet altijd zo netjes gemaakt. Met logisch redeneren en stap-voor-stap de wijzigingen nagaan is 't uiteindelijk sneller te vinden dan door heel de Enigma source (veel te veel) na te gaan.
Gast Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Citaat: (Probeer ook maar eens X te runnen op een embedded x86 systeem met maar 32 MB Geheugen zonder swap. Na een tijdje crashed X ook. Voor de mensen die Unix niet zo goed kennen: X is een grafische schil zodat je net zo als bij Windows grafische applicaties kan runnen zoals KDE enzo.) En dat is nu precies de reden dat we geen X draaien, maar enigma... Enigma is ontworpen voor systemen met weinig geheugen. Citaat: Ikzelf ben niet zo vertrouwd met C++ maar ik heb van hem begrepen dat er in de C++ standaardlib een new en delete functie bestaat om geheugen te reserveren en weer vrij te geven. Volgens zijn zeggen wordt hier vaak mee gezondigd, en wordt deze functie niet op de juiste wijze toegepast. Als hij bugs gevonden heeft hoor ik het graag. Maar tot dan toe wil ik dat toch even af doen als 'onzin'. Er zitten bij mijn weten momenteel geen memory leaks in enigma, we hebben er de laatste tijd veelvuldig naar gezocht, met veel verschillende tools en debug methoden. Je kan afgeven op de 'structuur' van enigma (die de laatste jaren een beetje verwaterd is), en dat doe ik ook regelmatig, maar het geheugen beheer is dik voor elkaar. Citaat: De workaround tegen het steeds minder worden van het werkgeheugen was het uploaden van een grote file in /tmp en daarna deze file in /tmp te wissen. Dan komt er ineens meer geheugen vrij dat eerst werd vastgehouden. Ook onzin. Het enige wat er op dat moment gebeurt is dat de kernel geheugen dat in buffers en cache gebruikt wordt gaat vrijgeven. Maar zodra je de grote file uit het tmpfs weer weggooit, gaat de kernel het vrijgekomen geheugen weer gebruiken voor buffers en cache. Hiervoor hoef je echt geen grote file in tmp te copieren, als je geheugen probeert te alloceren, gaat de kernel ook direct buffers en cache geheugen vrijmaken als dat nodig is. Het enige wat je hiermee dus beinvloedt is de waarde die je met 'free' krijgt te zien. Daarom moet je altijd de grootte van buffers en cache bij de 'free' waarde optellen, om te weten te komen hoeveel je in werkelijkheid nog kunt alloceren. Pas als ook die twee (bijna) nul zijn krijg je problemen. En dat kan best wel gebeuren op een systeem met weinig geheugen, vooral als bijvoorbeeld de codec iets te scheutig met geheugen omgaat. En op dat moment (of als het bijna zo ver is) zal je merken dat je zelfs niks meer in /tmp kunt copieren, omdat daar eenvoudig geen geheugen meer voor beschikbaar is. Citaat: Kijk in ieder geval ook eens in de Enigma sources.. Het is een hels karwei om in de spaghetti wegwijs te worden. <img src="/forums/images/graemlins/confused.gif" alt="" /> Geloof me, de enigma sources kunnen we wel dromen inmiddels ;-)
Gast Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Nog een kleine aanvulling, en dan gaan we snel weer terug ontopic ;-) De reden dat enigma af en toe uit z'n voegen dreigt te barsten wat geheugengebruik betreft, is simpelweg de epg data. Die blijft maar binnen komen, en wordt zo langzaamaan ook steeds meer (vergeet niet al die regionalen die er opeens bijgekomen zijn, met elk ruim twee dagen epg, en met name de duitse zenders hebben echt ontzettend veel epg) Momenteel kan je door eenvoudig rond te zappen al snel 10MB aan epg data vergaren. En al die epg wil je natuurlijk wel bewaren, terwijl daar eigenlijk niet genoeg geheugen voor is. Daarom is het PLi team druk bezig met een goede oplossing voor de toekomst, waarbij gebruik gemaakt wordt van een database (zodat je niet al je epg data permanent in geheugen hoeft te houden, zoals standaard het geval is). Op dit moment zitten er echter nog wat nadelen aan deze database (sqlite) oplossing, veel mensen melden problemen die hieraan gerelateerd zijn. Maar hier wordt aan gewerkt, en we zijn er van overtuigd dat we in deze richting verder moeten gaan, als je alle beschikbare epg wilt kunnen blijven gebruiken op boxen met beperkt geheugen.
Gast Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Citaat: Nog een kleine aanvulling, en dan gaan we snel weer terug ontopic ;-) De reden dat enigma af en toe uit z'n voegen dreigt te barsten wat geheugengebruik betreft, is simpelweg de epg data. Die blijft maar binnen komen, en wordt zo langzaamaan ook steeds meer (vergeet niet al die regionalen die er opeens bijgekomen zijn, met elk ruim twee dagen epg, en met name de duitse zenders hebben echt ontzettend veel epg) Momenteel kan je door eenvoudig rond te zappen al snel 10MB aan epg data vergaren. En al die epg wil je natuurlijk wel bewaren, terwijl daar eigenlijk niet genoeg geheugen voor is. Daarom is het PLi team druk bezig met een goede oplossing voor de toekomst, waarbij gebruik gemaakt wordt van een database (zodat je niet al je epg data permanent in geheugen hoeft te houden, zoals standaard het geval is). Op dit moment zitten er echter nog wat nadelen aan deze database (sqlite) oplossing, veel mensen melden problemen die hieraan gerelateerd zijn. Maar hier wordt aan gewerkt, en we zijn er van overtuigd dat we in deze richting verder moeten gaan, als je alle beschikbare epg wilt kunnen blijven gebruiken op boxen met beperkt geheugen. Als ik de epg uitschakel, dan blijft mijn 500 crashen met een mpeg file! Groet Gerard
Gast Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Maar om even op mijn vraag terug te komen, kunnen jullie de crash reproduceren of niet?????? Groet Gerard
nbrok Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Hoi Pieterg, Dat je door in /tmp een grote file laadt en weer verwijdert meer geheugen vrij krijgt is natuurlijk niet waar, daar heb je gelijk in. Ik meldde ook al dat het niet helpt. <img src="/forums/images/graemlins/wink.gif" alt="" /> Maar ik heb wel ontdekt dat als je het cached geheugen en het vrije geheugen bijelkaar optelt dat niet altijd overeenkomt met het geheugen dat werkelijk beschikbaar is. Hierdoor kwam ik op de redenatie uit dat je hiermee "dwingt" dat de kernel geheugen vrijgeeft dat niet meer door een proces wordt gebruikt dat nog om de een of andere reden gelocked is. Het EPG lijkt mij een belangrijke boosdoener. Omdat je bij PLI in kunt stellen van hoeveel dagen hij bij moet houden lost dit al een deel van het crash probleem op. Zodra Enigma geen geheugen meer kan alloceren exit deze en start het opnieuw op. Dit doet ie ook bij het afspelen van een videobestand. (Dit verklaart het crashen) Bij mij reboot de box niet maar restart enigma als ik enkele minuten naar een opgenomen film bekijk. Deze neem ik per ngrab op en is dus een .vob bestand. Zo leer ik ook altijd weer bij... en ik meldde al dat het een theorie was die waarschijnlijk niet geheel correct is.... Jij hebt mij gecorrigeerd <img src="/forums/images/graemlins/grin.gif" alt="" /> Je moet toch wat proberen om je box aan de praat te houden? Ik heb jarenlange ervaring met embedded systemen en weet dat een verkeerd gebruik van het beschikbare geheugen tot deze problemen kan leiden. Misschien wordt er bij het afspelen een te grote buffer aangelegd? Jullie schijnen er meer van te weten omdat jullie de source goed kennen. Ik moet wegwijs worden uit de spaghetti <img src="/forums/images/graemlins/confused.gif" alt="" /> Het restarten van Enigma wordt door de "gewone" gebruiker gezien als een reboot; die zitten niet per telnet continu op hun box ingelogd. <img src="/forums/images/graemlins/grin.gif" alt="" /> Ik moet wel zeggen dat de plek waarop de box crashed, bij het afspelen van een film, niet voorspelbaar is. Hangt van EPG af. Groeten, Nick Groeten, Nick Astra1, 2 en 3 op triax-schotel 89 cm
Gast Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Citaat: Zo leer ik ook altijd weer bij... en ik meldde al dat het een theorie was die waarschijnlijk niet geheel correct is.... Jij hebt mij gecorrigeerd <img src="/forums/images/graemlins/grin.gif" alt="" /> Je moet toch wat proberen om je box aan de praat te houden? Tuurlijk, en we zijn juist heel blij met ondernemende gebruikers zoals jij :-) Vaak kunnen we met zulke info een bepaald probleem sneller localiseren en oplossen.
mirakels Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Citaat: Maar om even op mijn vraag terug te komen, kunnen jullie de crash reproduceren of niet?????? Ik hierboven dacht ik toch redelijk helder gezegd dat ik ook last heb van dit probleem als ik via een netwerk share kijk. Met CIFS veel problemen, met NFS minder problemen, en als ik de mpg vanaf de interne disk bekijke heb ik praktisch geen probleem. Citaat: Ik moet wel zeggen dat de plek waarop de box crashed, bij het afspelen van een film, niet voorspelbaar is. Hangt van EPG af. Je moet tijdens het afspelen maar eens in een telnet sessie 'top' draaien, en dan opletten wanneer enigma het moeilijk heeft en dreigt te crashen. Mijn test mpg van 10 minuten heeft het op bepaalde plekken erg moeilijk, en als enimga crashed is dat 9 van de 10 keer op die plekken. DM7000, noname 58 cm bord met SM3D12 rotor, 46GB 2.5in hitachi hdd
Urkel Geplaatst: 28 januari 2007 Geplaatst: 28 januari 2007 Mijn ervaring is dat als je tijdens het afspelen van een .mpg bestand de lekker heen en weer gaat klikken in de webinterface dat de box eerder crasht. Niets wijzigen in de webinterface, gewoon door de verschillende menu's heen wandelen is al genoeg. Enkele keren geprobeerd en binnen een minuut een crash. Met een .ts bestand kun je je een ons klikken zonder een crash. Urkie 3xDM800 1xVisiosat Bigsat met 2x Inverto quad lnb's en 2x Alps quad lnb's 1xEdubuntu server met 500GB voor o.a. de 3 DM's
Gast Geplaatst: 5 februari 2007 Geplaatst: 5 februari 2007 Rammel rammel schop! Al wat gevonden????? Groet G
hemertje Geplaatst: 5 februari 2007 Geplaatst: 5 februari 2007 niet te hard schoppen want dan valt de barkruk om... we zitten aan de apre ski en het is beregezellig <img src="/forums/images/graemlins/tongue.gif" alt="" /> DM8000 + DM800SE + VU+DUO + Wavefrontier T90 + 10LNBs Hemertje.Dreambox Webmaster Sat-nerds Moderator Plinux Member
Gast Geplaatst: 5 februari 2007 Geplaatst: 5 februari 2007 Kijk maar uit, anders heb je die skies nodig als spalk! Groet G
Eland Geplaatst: 12 februari 2007 Geplaatst: 12 februari 2007 jawel, ik lijk hier ook problemen mee te hebben. en ik maar denken dat het aan mijn vervangen router/switch lag dat het afspelen van mpeg filmpjes vanaf mijn landrive crashte. Nu maar hopen dat er een oplossing komt, zodat ik niet terug hoef naar een eerdere PLI.
Aanbevolen berichten
Maak een account aan of log in om te reageren
Je moet een lid zijn om een reactie te kunnen achterlaten
Account aanmaken
Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!
Registreer een nieuwe accountInloggen
Heb je reeds een account? Log hier in.
Nu inloggen