Beiträge von pcfe

    Ich bin zwar nur sporadischer Besucher bei diesem Forum, aber es hat mit über die Jahre viel gute Hilfe geleistet und ich hoffe ich konnte das eine oder andere beitragen.


    Da ich meine defekte DM900 gegen eine E2 fähige box von einem anderen Hersteller getauscht habe auf der ein anderes Image mit E2 fahre werde ich wohl noch seltener hier posten, wollte aber aber nochmal ganz explizit für die gute Communityhilfe über die Jahre bedanken.


    pcfe

    [...]
    Oder von Erfahrungen anderer Nutzer profitieren, die das gleiche Problem haben.

    Meine DM900 (in Betrieb seit September 2017, aber mit autostandby nach 2 oder 3 Stunden, das Display lief also nicht dauerhaft die 4,5 Jahre) hat das gleiche Fehlerbild vor einem Monat an den Tag gelegt, Display weiß, kein bootlogo.

    Display bestellt, getauscht, immer noch weiß. Displayplatine bestellt auch getauscht, immer noch weiß.

    Gut kann jetzt sein dass ich wie ein Honk die Flachkabel eingesteckt habe, bei beiden Schraubaktionen, aber der Klappmechanismus wurde sauber genutzt und die Kabel schienen mir bündig und gerade eingeführt.

    Es scheint bei meiner DM900 wohl eher das motherboard zu sein. <seufz> ein drittes Mal investiere ich nicht in Ersatzteile aber andrerseits eine akzeptable Begründung eine schickere Box zu kaufen.

    (Die Hardware vom nächsten Hersteller hält dann hoffentlich mehr als 4,5 Jahre)


    ikarus13 Was ist bei Dir beim Tausch rausgekommen?


    pcfe

    Auch ich fände es schön wen ich 6 nutzen könnte.

    1x DVB-T (Tuner in der DM900UHD)

    1x DVB-C (Tuner in der DM900UHD)

    4x SAT>IP (von meiner FRITZ!Box 6490)

    Auf einer DM900 mit

    • Dreambox OS Version: 4.3.1r14-2017-09-01
    • Image Version: Release 2017-09-01
    • noad-arm-oe2.5_4.18.1_all.deb

    kriege ich auch den segfault (nach installation der dependencies).


    zwecks debugging kann ich die files (Aufnahme ist unter 2 Min und somit klein) per download link in PM zur verfügung stellen.

    Mag mal jemand, der systemd besser kennt als ich, die passenden Configs nennen? Ist /etc/systemd/journald.conf der richtige Ort? Laut Google brauche ich aber u.U. noch ein syslog-ng?


    Zum Thema Logs im Flash: Bitte nicht! Sowas macht man schon aufgrund der begrenzten Lebensdauer von Flash-Blöcken nicht. Der Speicherplatz ist dabei nicht das Problem, denn für so etwas wurde Log-Rotation erfunden. Aber der Flash wird dann auf jeden Fall übermäßig belastet und vorzeitig kaputt gehen.


    @gutemine: Das WebAdmin-Plugin steht frei für Pull-Requests auf github zur Verfügung :face_with_tongue:
    Auch cool wäre ein Syslog-Setup, bei dem ein Raspbery Pi, NAS oder eh vorhandener Home-Server die Logs bekommt.

    @m0rphU

    • Configs: wenn Du in .deb machst welches eine Config ablegt, dann ist eine Datei /etc/systemd/journald.conf.d/*.conf einfacher zu verwalten.
    • Flash: full ACK. Für mich kommt als log target hauptsächlich die HDD (oder, wenns nicht anders geht, ein remote syslog server in meinem Netz, wobei ich den mal auf journal modernisieren sollte) in Frage.
    • Doku: Für systemd und journal Doku starte ich generell auf https://www.freedesktop.org/wiki/Software/systemd/
    • syslog-ng: journal an einen syslog schieben und da dann an einen remote syslog server schieben sollte gehen. Aber nur um persistente logs zu haben ist kein syslog notwondig AFAICT.


    @Reichi fair point, nicht jeder sieht die HDD als Verbrauchsmaterial wie ich
    RFE kann CLOSED WONTFIX werden. War eh nur ein nice to have :winking_face:


    Generell:

    • Laut man page reicht bei einer default Config das anlegen von /var/log/journal aber das ist (sinnvollerweise für User die keine HDD in der Dreambox haben) tmpfs und somit beim nächsten boot weg
    • Ich finde auf meinem Fedora 26 (systemd-233-6.fc26.x86_64) kein setting um das Zielverzeichnis umzustellen, vielleicht schau ich ja schlecht :-/
    • https://www.kernel.org/doc/Doc…n/laptops/laptop-mode.txt wäre meine Wahl falls ich /var/log auf Platte umbiegen würde und trotzdem ihr das sleep ermöglichen wollte, aber dann schaffen es die paar letzten journal-einträge nicht unbedingt wuf Platte wenn es einen crash gibt.

    Wenn eine Festplatte eingebunden wird, dann wird sie ja (glücklicherweise) nicht nur für Aufnahmen sondern auch für backups und crashlogs genutzt.


    Er wäre schön wenn auch persistente journals in dem Fall eingestellt würden.
    Momentan hat man ja nur den aktuellen boot und es ist klar dass keiner das aufm flash will.
    Aber, es macht das debuggen so viel leichter falls die box absemmelt und man sich einen älteren boot mit z.B. vor 3 boots

    Code
    journalctl -b -3

    ansehen kann.

    Klar auf embedded devices spart man sich die man pages wegen Platz, aber auf den modernen boxen mit mehr als 500MB rootfs wäre es schon nett wenn sie drauf wären
    (das würde IMHO den einen oder anderen "haaalp, ich krieg es nicht hin" Forenbeiträge sparen).


    Fee free to CLOSED WONTFIX


    pcfe

    Ist es möglich, die volle Debug das System beginnen zu laufen?

    Wenn Du meinst "wie kriege ich das volle enigma2 log seit boot", dann ja das ist einfach.


    Lass das -f (für follow) weg und Du kriegst alles ab boot. Beispiel:

    Code
    journalctl -u enigma2


    Wer Linux kennt aber systemd und journal neu sind, der sehe sich systemd for Administrators, Part XVII an.
    Wer Linux nicht wirklich kennt aber lernen will wie journal und systemd funktionieren, der sehe sich systemd System and Service Manager an.

    Da ich vor kurzem vom einer DM7020 HD auf eine DM900 UHD umgestiegen bin (und somit endlich systemd auch auf meinem PVR habe ;-),
    putze ich nun /media/hdd/movie/autoclean via systemd timer.


    Nachrichten und Sport werden nach 3 Tagen gelöscht, alles andere mittels cleanup.py


    Falls jemand copypasta machen will (oder ich es nochmal aufsetzen muss)


    i. Den Dienst erstellen (an systemd-tmpfiles-clean.service angelehnt)


    ii. Den zugehörigen Timer erstellen (an systemd-tmpfiles-clean.timer angelehnt).
    Im Beispiel 5 Minuten nach hochfahren, sowie alle 4 Stunden.




    iii. Das autoclean script an sich


    iv. cleanup.py installierenEinfach laut Anleitung
    Ausführbar machen nicht vergessen!



    v. Aktivieren

    • Timer aktivieren für den nächsten boot
    • Timer sofort starten
    • Timer prüfen
    • autoclean Skript ausführbar machen
    Bash
    root@dm900uhd:~# systemctl enable autoclean-recordings.timer
    root@dm900uhd:~# systemctl start autoclean-recordings.timer
    root@dm900uhd:~# systemctl list-timers
    root@dm900uhd:~# chmod u+x auto-clean-script.sh

    von unserer Seite besteht da kein Interesse. Das ist immer noch eine Settop Box. Und 99% der Leute benötigen kein cron. Und wir selber auch nicht.


    Und die die es schaffen eine Crontab anzulegen können auch den rest selber anlegen.

    Das ist völlig OK so. Ich sehe keinen Sinn drin dass DMM jetzt wertvolle Entwicklerzeit drauf verschwendet cron in ein eigenes Paket auszulagern und nochmal testet. Ich glaub net dass mehr als eine handvoll von uns crontabs anlegen wird.


    Ich habe mein posting, welches ich zum copypaste nehme wenn ich mir mal wieder das flash kaputt gespielt habe, auch updated.

    Und ich würde dennoch ein if-Konstrukt darüber setzen, da es sonst Fehlermeldungen gibt, sollte nichts gefunden werden. :winking_face:

    Fast perfekt. Wenn man den * weglässt (es ist find [PATH], wenn Du ein * anhängst wird versucht in dem Suchpfad zu expandieren, was nicht geht wenn er leer ist) kann man sich das IF-Konstrukt sparen.


    Code
    find /hdd/movie/Nachrichten/ -type f -mtime +3 -maxdepth 1 -delete


    und zum copypasten (hab mir jetzt schon 2x das flash geschreddert und hatte die crontab nicht im backup, doh!);

    Code
    #
    # clean out 2 day old news at 23:00  	
    00 23 * * * find /hdd/movie/Nachrichten/ -type f -mtime +3 -maxdepth 1 -delete
    #                              	
    # clean out /hdd/movie/autoclean                                           	
    10 23 * * * find /hdd/movie/autoclean/days/ -type f -mtime +3 -maxdepth 1 -delete
    20 23 * * * find /hdd/movie/autoclean/weeks/ -type f -mtime +28 -maxdepth 1 -delete
    30 23 * * * find /hdd/movie/autoclean/months/ -type f -mtime +180 -maxdepth 1 -delete


    Und jetzt noch cron einschalten (ein mal per telnet oder ssh machen)

    Code
    root@dm7020hd:~#  update-rc.d busybox-cron defaults
    root@dm7020hd:~#  /etc/init.d/busybox-cron  start

    Hallo,


    unter OE2 (alle drei bisher released, 20120512 heute) tut die DM7020HD wenn sie autotimer parsed nach kurzer Zeit nicht mehr am frontpanel oder auf die Fernbedienung reagieren.


    ssh auf die dream geht immer noch, load ist niedrig.


    Zum reproduzieren hab ich zwei mal 'Parse' am AutoTimer WebF losgetreten, QObject: Cannot create children for a parent that is in a different thread. kommt konsistent.


    die Ausgabe von enigmal2.sh ist in eine Datei umgebogen in der inittab. In der Ausgabe sieht man


    Die EPGC cleanloops laufen dann interwallweise weiter.
    Normalerweise setzt ich kurz nachdem das passiert ein 'reboot' per ssh ab was dann auch sauber durchläuft.


    FWIW: In syslog kommt keine Meldung wenn der Fehler passiert.


    Versionen:
    Enigma2 v4.0.0 (revision: tarball-20120509-0-g58f61a2, date: 2012-05-09)
    enigma2-plugin-extensions-autotimer - 3.999+git4278+6e15900-r0

    Hallo,


    enigma2-plugin-extensions-growlee lief kurz (seit einigen Stunden) gut im syslog modus (per UDP an meinen server), ist jedoch gerade abgestürzt mit



    Als ich beim durchgehen einiger Aufnahmen war, Schnitte im Hintergrund liefen und eine Aufnahme lief.


    Volles crashlog ist angehängt.

    Aunahmen sind kontinuierliche große Files genauso wie Timeshifts, insofern bringt das wenig bis nichts sich ein bisschen IO beim löschen zu ersparen, das macht ext4 eh schon cleverer und beim xfs bin ich nichtmal sicher ob es das unterstützt.

    Doch genau dann bringt TRIM was, das filesystem teilt der SSD mit welche Blöcke durch ein löschen frei sind. Das wear leveling der SSD muss dann z.B. die eben gelöschte Aufnahme von Kommisar Pterodactylus beim wear levling nicht mehr beachten (ohne TRIM weiss die SSD nicht dass diese Blöcke nie wieder angefragt werden)


    Ein XFS filesystem hab ich nicht mounted und die Platte ist ext4.

    Code
    root@dm7020hd:~# cat /proc/mounts |grep hdd
    /dev/disk/by-uuid/8a55c107-7f21-4f18-a582-e4707a628335 /media/hdd ext4 rw,relatime,barrier=1,data=ordered 0 0


    Meine Box ist allerdings auch 'n update von 1.6, ist bei OE2 xfs default?

    Natürlich wird auch beim Flashen über das WebIF auf Bad Sectors geprüft und eben diese werden dann übersprungen.

    Ah, uff, war schon ganz verwundert und unhappy :smiling_face_with_sunglasses:
    Danke fürs schnelle Aufklären



    m0rphU

    Zitat

    Die
    Option "Recover Bad Sectors" macht ja gerade das Gegenteil und versucht
    diese Sektoren wieder zum Leben zu erwecken. Ich sehe das nur als einen
    letzten Strohhalm an, aber es hat ja schon manchmal geholfen. Beim
    normalen Flashen sollte diese Option vollkommen egal sein.

    Das ist effektiv dann nur ein letzter Strohhalm. flash hat einfach mal hat Zellen die nicht tun.

    Ja.


    Hab grad eine 4,4Gibibyte grosse Datei angespielt und auch erfolgreich drin rumgesprungen. Auch ganz am Ende tut der Sprung vorwärts und rückwärts.


    FWIW: der DLNA server ist ein Twonky Server 6.0.39 auf CentOS5.