Der Teil benutzt nur Standardfunktionen von E2… wenn die nicht gehen ist es nicht meine Schuld und fixen kann das nur noch DMM (ohne unverhältnismäßigen Aufwand).

Und weils so lustig war trat es heute nochmal auf – ob es das einzige seit dem letzten mal war kann ich ehrlich gesagt nicht beantworten, ändert aber am Problem auch nichts.
Ich denke ich werde dann besagten Workaround in meinen Build einbauen, Interesse an einem Fix scheint es ja keines zu geben.

Nichtsdestotrotz anbei nochmal die Ausgabe von dmesg und lsmod. Dazu der Hinweis - der mount wurde in beiden logs manuell von mir ausgelöst, nur falls sich jemand wundern sollte

Und das dritte Problem, was ich mir heute von der Seele rede: Unbootbarkeit.

Selten, aber schon ein paar mal aufgetreten, die Module möchten nicht laden bzw. funktionieren nicht korrekt.
Besonders ärgerlich, da die Box dann einfach hängt und ich manuell via telnet checken musste, was jetzt schon wieder im Eimer ist.

Allerwenigstens sollte ein counter eingebaut werden, dass wenn nach 2-3 Minuten noch immer das gesuchte Device nicht da ist, die Box das Booten aufgibt und entweder a) herunterfährt oder b) es mit einem reboot probiert.

Anbei lsmod, dmesg, und ein ps ax vom letzten mal.
(Ja, mein Image kommt mit ein paar Paketen weniger und dafür ein paar zusätzlichen, aber nichts davon sollte das provozieren)

Ich habe seit Ewigkeiten On und Off mal das Problem, dass HD-Sender via Sat nicht empfangbar sind – ob Sat dabei relevant ist oder nicht kann ich nicht genau sagen, installiert sind ein zusätzlicher DVB-C und DVB-S Tuner; nutze aber primär Sat deshalb fällt es mir evt. nur da auf.

Zugegebenermaßen tritt das Problem am häufigsten auf, wenn ich "böse" Dinge mache wie PiP während einer Aufnahme mit meinem pipzap umschalten oder auch grade mit "Fake Recording" bei EPGRefresh.
Es sind dann ausschliesslich die HD-Sender via Sat nicht empfangbar, SD via Sat geht und HD via Kabel auch. Das Signal ist grundsätzlich nicht das Problem, nach einem Reboot geht es wieder.

Anbei die Ausgabe von dmesg, die ich neulich irgendwann mal gespeichert hatte - das aktuelle Log sah nicht gross anders anders aus, weshalb ich es nicht gespeichert hab.
Oh - wenn ich versuche einen HD-Sender wiederzugeben ist die GUI dabei auch grauenhaft langsam. Macht das Suchen der Reboot-Option gleich viel mehr Spass

Da versucht man sich vor der Hitze zu retten und dann hängt sich die CPU bei der MKV-Wiedergabe weg (nice!).

Viel mehr Infos als ein dmesg call trace konnte ich nicht holen, da kein HDD-Zugriff mehr möglich war und mir ehrlich gesagt auch die Lust fehlte
Die Box läuft noch mit 3.2.20, allerdings fällt mir jetzt aus den beiden Changelogs auf Anhieb nichts ein, was das beheben könnte.

Bump weil es wieder auftrat und es hier nichts neues gibt.

Zitat von SIOUD

Hello all
And at compile OE2.0 how should I proceed to add or remove plugins
you can not apply the procedure of OE1.6 in OE2.0, some one can enlighten me please
hello

I actually do use the same method I used before, but it was already written like an overlay.

Basic example to remove some plugins from task-opendreambox-enigma2:

PR .= "-ritzmo1"


DEPENDS += "\
"


RDEPENDS_${PN} += "\
    enigma2-plugin-extensions-teletext \
"


# remove inhibited packages from configuration
# soft-patching this makes us independent from original recipe
python() {
    inhibitPackages = (
        'task-opendreambox-modem',
        'enigma2-plugin-systemplugins-tempfancontrol',
        'enigma2-plugin-systemplugins-crashlogautosubmit',
        'tuxbox-tuxtxt-32bpp',
    )
    depends = bb.data.getVar('DEPENDS', d, True).split()
    pn = bb.data.getVar('PN', d, True)
    rdepends = bb.data.getVar('RDEPENDS_'+pn, d, True).split()
    rrecommends = bb.data.getVar('RRECOMMENDS_'+pn, d, True).split()


    for package in inhibitPackages:
        while package in depends: depends.remove(package)
        while package in rdepends: rdepends.remove(package)
        while package in rrecommends: rrecommends.remove(package)


    bb.data.setVar('DEPENDS', ' '.join(depends), d)
    bb.data.setVar('RDEPENDS_'+pn, ' '.join(rdepends), d)
    bb.data.setVar('RRECOMMENDS_'+pn, ' '.join(rrecommends), d)
}

Please note that this is not meant to be perfect and certainly not guaranteed to work forever.
But it was way easier for me to just reuse my old method (as I just had to switch this from being an existing recipe which includes the base to an bbappend which does the same thing without changing its name :D) than to look for alternative and possibly cleaner ways (there are some more "native" ways than fiddling with the bb vars directly, but they are not as flexible and make things even less readable).

Oh, and I know that the teletext/tuxtxt switch is no longer needed, but it doesn't hurt either and worked around the initial awkwardness for me.

Vermutlich irgendwie damit verbunden, aber E2 lief im Hintergrund weshalb es überhaupt dazu kam: Shutdown nachdem die Wiedergabe so gut wie eingefroren war…

Schön mit Meldung in der Telnet session aus der ich eigentlich grade E2 killen wollte

Da kein sauberer Crashlog generiert wird und ich grad mal so gar keine Lust hab mir das selbst anzuschauen, hier mal die letzten Zeilen eines bei mir nicht zu seltenen E2-Crashes:

eServiceMP3::stop /hdd/Movies/*****.mkv


GThread-ERROR **: file gthread-posix.c: line 171 (g_mutex_free_posix_impl): error 'Device or resource busy' during 'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'
Trace/breakpoint trap

Mehr als das was da steht kann ich auch nicht sagen: Die Wiedergabe endet (z.T. durch Betätigen von 'Stop') und die Aktion wird durch einen Absturz von E2 quittiert.

Leider ist heute noch ein Timer abgelaufen, der den Konflikt gelöst hat (good job!), und die alte xml hab ich nicht mehr gespeichert.
Krieg das bestimmt aber nächste Woche nochmal provoziert und dann speicher ich die mal weg

*EDIT* Der Timer stand übrigens alleine (sprich kein anderer parallel) und ist problemlos durchgelaufen.

*EDIT2* So, hab das ganze durchs Erstellen eines neuen Timers wieder reproduzieren können und meine timers.xml von allen "unnötigen" Timern befreit.
Die Alternative scheint (mit) die Ursache zu sein. Es handelt sich dabei um Astra und UM, das ist aber vermutlich nur bedingt relevant.

Es ist nicht das erste mal, dass er Konflikte erkennt wo keine sind (überprüft durch manuelle Kombination von Live-TV, PiP und Aufnahme) - aber dieser Konflikt ist mein neuer persönlicher Favorit.

Wie können drei Timer, von denen einer ca. 12h vor den anderen abläuft, mit zwei dedizierten Leitungen von der Schüssel überhaupt einen Konflikt auslösen?
Bitte schaut euch den TSC für den nächsten Snapshot nochmal an, der wird soweit ich das beurteilen kann immer nur ungenauer und schlechter, bis zu dem Zeitpunkt wo er mir effektiv verbietet gültige Aufnahmen zu machen ohne die Möglichkeit ihn zu deaktivieren, sofern ich da nicht selbst rumpatchen möchte.

Just FYI, nach >24h gabs dann doch einen Hänger… bin jetzt zum Testen nochmal auf den Kernel mit Base 3.2.16 runter.

*EDIT* Fun, da sind dann gleich drei Aufnahmen fehlgeschlagen weil HD-Empfang wieder gestorben war

Zitat von Tode

ritzMo: hast Du selbst Änderungen am Kernel vorgenommen (eigenes Image) oder meinst Du die Commits der letzten Tage?

Hab selbst Hand angelegt, fahr eh immer ein eigenes Image - hab einfach die cgroups und securityfs wieder deaktiviert. Allerdings vermute ich eher ersteres als "Bösewicht" und hab mir schonmal nen neuen Kernel mit securityfs und ohne cgroups gebaut zum weitertesten, wenn ich den aktuellen Zustand für "stabil" erkläre.

Zitat von Mac Siggi

Dream hat doch sicherlich die Möglichkeit die Box auszulesen um einen Softwareschaden auszuschliessen ,
Die baunen doch nicht einfach mal ein neues Board ein, zumal ja noch Garantie drauf ist und sie bezahlen müssen.

Du würdest dich wundern, was alles passiert.
Die Box "auslesen" können sie schonmal nicht. Was sollten sie denn auch auslesen? Sie können in den Flash schauen und auf deine Festplatte, sofern du eine ein- und nicht vorm Versand ausgebaut hast.
Dann können sie die einzelnen Komponenten testen, aber auch da eben nur testen und nicht den Zustand vorheriger Fehlersituationen auslesen.

Mainboard ist eher so die "keine Ahnung, mach mal"-Lösung. Und nicht vergessen, wenn der Fehler OpenDreambox 2.0 spezifisch sein sollte und sogar mit der zu dem Zeitpunkt installierten Firmware rekonstruiert wird, dann ist ein Mainboardtausch ein sehr kreativer Weg um wieder OpenDreambox 1.6 aufzuspielen

Aber wie du schon gesagt hast, soll egal sein - wenns wieder geht ist ja alles i.O. und das ist dann hoffentlich bei uns beiden wieder der Fall, wenn auch auf sehr unterschiedlichem Weg

X war ein Platzhalter

Steht z.B. für dropbear und task-opendreambox-modem.
U.a. tausche ich so auch alten TT gegen den neuen

*EDIT* Hätte man btw auch drauf kommen können - die Images enthalten ja kein X

Just fyi, mein OE Layer besteht aktuell primär aus "nicht X installieren" - das liegt aber z.T. auch daran, dass ich mir noch nicht sicher bin, was ich überhaupt bei den ganzen precompiled binaries noch ändern kann

Nach ein paar Änderungen am Kernel hatte ich >24h keine Probleme mehr, also vermute ich bei mir bis auf weiteres keinen Hardwareschaden.
Btw, ein "joar, da haben wir das Mainboard getauscht" klingt immer besser als "keine Ahnung was wir tun sollten, haben einfach mal rumgepfuscht" :D.

Nope, war nicht die Lösung für mich - allerdings hab ich mal zum Testen an der kernel config rumgepfuscht, mal sehen ob/wann es das nächste mal passiert

Nicht ganz - ich kann mich nicht per Telnet einloggen und das bringt die Box erst recht nicht zurück ins Leben

Zitat von dieter2

richtig erkannt, nach Kernel/Treiber/Gstreamer-Updates sollte man immer neu flashen.

Streng genommen stimmt das nicht. Du magst es mir nicht glauben aber das Image wird auch von der Paketverwaltung erstellt. Bis auf ganz wenige "Live"-Daten, wie z.B. /etc/image-version, sollte es also keinen Unterschied geben.
Da es aber beim aktuell genutzten Schnappschuss von opkg noch ein paar Ecken und Kanten gibt, kommt es zwischendurch mal zu Problemen - aber auch dann sollte es keinen Unterschied geben, wenn die Daten einmal installiert sind.
Wenn doch liegt tatsächlich ein Hardware-Defekt vor

Und da das ganze recht unvorhersehbar passiert, würde ich mir selbst nach einem erneuten Flashen kein Urteil darüber erlauben.
Meine Box hat gleich 4h Uptime heute und läuft noch immer - sie kann theoretisch ohne Update auch 2 Wochen laufen und ich merke von dem Problem nichts, weil es einfach unreproduzierbar passiert (hey, das erste mal bin ich kurz in die Küche und als ich zurück kam hing sie… es lief nur Live-TV).
Ebenso stirbt ab und zu mal HDTV bei mir, auch schon in den alten Images. Passiert mehr oder weniger ohne Ankündigung und besonders nervig wenn ich es nicht merke und dann schlägt eine Aufnahme deshalb fehl. Davon hab ich iirc auch noch nie was gelesen. Da es kein Dauerzustand ist geb ich dafür auch dem Treiber und nicht der Hardware die Schuld.

Es gibt durchaus Fehler, nur weil man sie selbst nicht sieht muss man sie nicht leugnen oder dem Update ohne Flashen die Schuld geben

Zitat von DigitalKlaus

Ich sehe diesen Threat für meinen Teil als erledigt an.

Das hab ich nur zum klugscheissen zitiert, eine Drohung hat hier nämlich keiner ausgesprochen
Naja, wenigstens hast du nicht Forum gesagt - der Fehler tut mir meist noch mehr weh

Ich glaube aber kaum, dass hier mehrere Boxen einen Selbstmordpakt geschlossen haben.

Schlimmstenfalls ist das ein neuer 1.5. wie letztes Jahr, nur halt spezifischer und somit merkt es nicht jeder. Ich würde den Fehler jedoch eher in Software als in Hardware vermuten.

Oh, und weil es so Spass macht: Gestern 4 Abstürze. 2x Wiedergabe, 1x Booten, 1x Live-TV.