Beiträge von Fred Bogus Trumper

  • Speicherleck möglich in dbttcd?

    Zitat von LazyT


    Kann ich nicht bestätigen, du musst natürlich 1x umschalten damit er die PID von E2 bekommt die er filtern/cachen soll.


    ok, das stimmt. Einen Senderwechsel hatte ich natürlich nicht versucht ...


    eventuell hilft ein daily cronjob, der 1x täglich dbttcd neu startet (crond beim bootup nicht vergessen zu aktivern, wird per default nicht automatisch gestarted :winking_face: )


    Code
    0 4 * * * /etc/init.d/dbttcd restart


    im Grunde reich auch ein

    Code
    killall -9 dbttcd


    der wdag startet den daemon automatisch wieder.


    Betroffene man können im in den Teletext Einstellungen auch debug aktivieren, dann wird nach /tmp/dbttcp.log geloggt
    wenn man das Startscript anpasst und dbttcd im debug mode startet, erhält man einen log des Daemons: /tmp/dbttcd.log


    /etc/init.d/dbttcd wie folgt anpassen:
    dbttcd stoppen
    /etc/init.d/dbttcd stop


    Zeile 9 auskommentieren und die Zeile darunter einfügen, sieht dann so aus

    Code
    #start-stop-daemon -q -p /var/run/dbttcd.pid -x /usr/bin/wdog -S -b -m -- -d dbttcd -f
    start-stop-daemon -q -p /var/run/dbttcd.pid -x /usr/bin/wdog -S -b -m -- -d dbttcd -l f -v 3 -f



    und dann wieder starten:
    /etc/init.d/dbttcd stop


    ich habe auch schon vor längerem ein Plugin gefrickelt, damit man den dbttcd restart per GUI ohne Konslole etc. ausführen kann. Aber das ist auch nur ein Workaround ...

  • less (aus busybox) findet Zeichenkette nicht bei Zeilenumbruch im Terminal

    Erfahrungsgemäß kommt da kein update mehr. Solche "Bugs" gehen weit über die Bedienung eines Sat Receivers hinaus und werden von 99% der user nicht mal bemerkt. Ich habe selbst schon Rückmeldungen in der Art bekommen :frowning_face:


    Mir ist der Bug nie aufgefallen, weil ich less auf der Dream nur als pager verwende (keine Suche). less war lange nicht in der busybox, d.h. man musst mit cat file|more und grep arbeiten.


    Tipp:
    hol dir less aus den debian mipsel sourcen und pack die binaries nach /home/root/bin ... und ruf die binaries über aliases auf, dann kann auch das busybox less so sein wie es es ist. Ich rufe einige binaries so über die ~/.user_aliases auf (im Merlin ist das default in der ~/.profile - dort ist das dann auch update sicher, das habe ich mal angeregt :winking_face: )


    Es gibt auch andere Workarounds busybox commands durch vollwertige binaries zu ersetzen ohne das sich die BB und das binary in die Quere kommen. Bei solchen Sachen muss man fast immer basteln ...

  • less (aus busybox) findet Zeichenkette nicht bei Zeilenumbruch im Terminal

    \\Edit


    hier stand Quatsch - du meinst die Suche innerhalb von less. Sorry das hatte ich missverstanden



    1. Wenn ich mit less oder vi eine Datei ansehen, maximiere ich immer vohrer das Konsolenfenster, einfach weil der Inhalt besser lesbar und übersichtlicher ist.


    2. Wenn du mit grep einen string in einer Datei suchst, kannst du dir mit der Option -n die Zeilennummern des Vorkommens des Suchstrings ausgeben lassen, dann kannst du im vi einfach zu der Zeile navigieren (Zeile/Spalte wird dir ja im vi Rechts unten angezeigt)


    Code
    root@dm7020hd:~# grep -n update /usr/lib/enigma2/python/Navigation.py 
38:				print "buggy fp driver detected!!! please update drivers.... ignore timer wakeup!"
root@dm7020hd:~#


    Wenn du die Suche mit less vereinfachen willst kannst du dir dann die Zeilennummern mit ausgeben lassen. Wenn dann ein Zeilenumbruch im Terminal stattfindet, erkennst du das sofort an der Zeile ohne vorangestellter Zeilennummer.

    Code
    less -N /usr/lib/enigma2/python/Navigation.py


    dann funktoniert auch wieder die Suche



    die Funktionalität der busybox Befehle sind leider oft sehr kastriert, da braucht es eben oft Umwege. Aber das ist nicht nur mit der Dreambox busybox so. Abhilfe schafft dann meist die Verwendung vollwertiger binaries.

  • Speicherleck möglich in dbttcd?

    Ist (mir) schon länger bekannt. Gibt ein ein paar Threats im IHAD und NN² Forum dazu.


    Bei meiner DM7020HD von USB gebootet und 1GB Swappartition auf USB tritt der leak nie auf, obwohl ich den Teletext auf der Box sehr oft nutze. CPU Auslastung 0%, MEM 1-3,5%


    Es gibt zwei workarounds:


    wenn die Box extrem träge wird und Enigma2 noch ansprechbar ist:
    TELETEXT starten
    mit MENU in die Einstellungen
    "Puffern im Hintergrund" -> deaktivieren
    TELETEXT schließen
    TELETEXT wieder starten und "Puffern im Hintergrund" wieder aktivieren, dann läuft es wieder eine Weile.


    Wenn die GUI nicht mehr reagiert, per Telnet:

    Code
    killall -9 dbttcd


    dbttcd läuft dann zwar wieder, weil vom wdog neu gestartet, aber bis zum nächsten Enigma2 Neustart hat man kein Teletext mehr (black screen) ...

    Code
    /etc/init.d/dbttcd restart


    funktioniert auch nicht korrekt, solange man Enigma2 nicht neu startet, hat man auch kein TELETEXT mehr, aber die CPU/MEM Auslastung geht wie beim killall -9 dbttcd wieder runter


    Wenn man das "Puffern im Hintergrund" in den Teletext Einstellungen dauerhaft deaktivert, tritt der Leak nicht mehr auf. Allerdings hat man ein Teletext wie im OE1.6: jede Seite wird immer neu geladen


    Ich habe hier eine DM7020HD und zwei DM800SE mit jeweils 1GB aktiver Swap Partiton auf USB - auf allen drei Boxen ist wg. dem Dreambox Teletext cache daemon E2 noch nie eingefroren und die CPU und MEM Auslastung liegt bei 0% und 1-3.5%. Aber es gibt genügend Berichte, vor allem über Boxen mit 256MB RAM, wo das recht häufig auftritt, also mit extrem hoher dbttcd CPU und MEM Auslastung bis zur E2 Unbedienbarkeit.


    Ich tippe auch auf einen MEM leak, wobei ich dachte, dass DMM Bescheid weiß ...

  • netzwerkaktivität im stand by

    Jetzt komm mal wieder runter. lt. EU Verordung dürfen Elektrische Geräte im Standby Betrieb ich glaube nicht mehr als 1W verbrauchen. Die Dreamboxen bauchten im "alten" Standby Modus fast gleich viel wie im aktiven Modus, weil nur Bild, Ton und die Tuner ausgeschaltet waren. Im Grunde wie ein Computer, der den Bildschrirm bei inaktivität abdreht. Nur wenn die Dreamboxen in den Deepstandby geschickt werden, brauchen sie unter 1 W, wie die EU verlangt.


    DMM hätte nach der alten Namensgebung keine Boxen mehr verkaufen können, weil im Standby je nach Box zwischen etwa 13 und bis zu 30W verbraucht werden. Deshalb musst der Name geändert werden


    Standby -> neu IDLE
    Deepstandby -> neu STANDBY


    Wenn dich das stört, dann goolge einfach. Ich habe es irgendwo gepostet wie man das wieder umstellen kann, man muss nur eine .xml etwas anpassen. Das machst du ja sonst auch gerne :winking_face:


    Und passe endlich deine Ausdruckweise und Formulierungen an und stecke deine Paranoia in eine Schublade, wenn du hier postest.

  • so muss das display sein! ;-)

    Und wieder einmal hast du deinen Beitrag sinnendfremdet ediert.


    btw.
    am 27.12. kam ein update, das nachtste auf 4.0.15 steht in den Startlöchern.


    Also hör endlich auf hier mit deinem sinnentleertem Rumlabern. Häng die Crashlogs an, damit dir einer, der noch nicht aufgegeben hat dir helfen zu wollen, helfen kann - oder halte endlich mal den Rand!

  • so muss das display sein! ;-)

    Zitat von kopter

    dass die gewissen hier, mich jetzt versuchen zu verhunzen, zu verökern, zu verulken, spricht doch für sich. einer der nur scheiße labert, bekommt so eine "ehre" nicht. damit habt ihr euch verraten! :winking_face: ich wette, wenn ich jetzt ein unstable aufziehen würde, würden auch da nach spätestens 4 wochen die updates verschwinden. :grinning_squinting_face: man, müssen manche einen hass auf mich haben. :grinning_squinting_face:



    [SARKASMUS]
    genau, wir warten alle nur bis du endlich ein unstable flashst, dann werden sofort alle updates eingestellt
    [/SARKASMUS]


    lies und verstehte doch endlich was dir hier viele user versuchen zu erklären



    gib mal diesen Befehl in die Konsole ein:


    tar vcjf /media/hdd/crashlogs.tar.bz2 /media/hdd/enigma2_crash_*.log


    und häng dann die Datei /media/hdd/crashlogs.tar.bz2 hier an


    auch wenn der Threat etwas abgeglitten ist, es gibt noch immer user, die dir helfen wollen - auch wenn das wahrscheinlich vergebene Liebesmüh' ist

  • so muss das display sein! ;-)

    Liegt auch an der Vorgeschichte. Die Diskussion mit dem user begann ja nicht hier


    Jeder andere hätte gesagt: "Gut - dann mache ich das in die skin_user.xml "- oder hätte vielleicht auch noch gefragt, wie man das macht


    Aber wenn jemand dann anfängt allen anderen die Schuld zu geben und beginnt rund um sich zu schlagen und alle gut gemeinten Ratschläge und Hilfestellungen ignoriert und immer genau dann das Thema wechselt oder einen Zick-Zack Kurs einschlägt, wenn ein akuter Argumentationsnotstand auftritt, darf man sich nicht wundern wenn scharf und sarkastisch zurückgeschossen wird.


    Jedenfalls ganz großes Kino und hat dem Board soviele klicks wie schon lange nicht mehr beschert ... :grinning_squinting_face:


    Und über einen mangelden Überfluss an Mut, Starrsinn, Beharrlichkeit und Beratungsresistenz darf sich kopter nicht beklagen.

  • so muss das display sein! ;-)

    Wie du sie wahrnimmst. Das heisst aber noch lange nicht das du Recht hast.


    Sorry, aber du befindest dich am totalen Irrweg was den Unterschied zwischen stable und unstable NN² Image angeht und lässt dir den Unterschied auch nicht nach mehrmaligen Versuchen erklären.