Gelegentliche Crashes

Die 1.1.1 funzt auch zuverlässig, hatte ich bis vor 4-5 Wochen auch noch. Es dient ja auch nur zum testen. Wenn das Problem danach wieder auftritt, kannst Du es ja wieder rückgängig machen. Bei dem Fehler kommt man mMn nur durch Ausschlussverfahren weiter

Du kannst die Version 2.05 auch hier herunterladen:
Einstellungen EPGRefresh?

Inhaltlich sind nur die Einstellmöglichkeiten, was die Box nach Beendigung der EPG-Suche machen soll, andere.

Und schalte bitte die Debug-Ausgabe ein (VTI - Einstellungen -System - Seite 5/5):
Debug-Typ: An
Debug-Ausgabe aktivieren: Datei
Erweiterten ...: Ja

Die log- und crash-Dateien findest du dann auf der HDD im Stammverzeichnis.
Fals kein Crash erfolgt wäre auch die genaue Zeit, wann der Fehler auftritt, noch wichtig.

Ich habe die debug-Ausgabe auf allen Boxen permanent aktiviert. Ausser bei Programmtests, bei denen ich grosse Tabellen mitprotokollieren lasse, merke ich keine Verzögerung.

Crashes werden übrigens auch ohne aktivierte Debug-Ausgabe geschrieben, aber wenn ich richtig gelesen habe entsteht bei dir kein Crash (Absturz der Box).

Der Countdown ist ja nicht das Problem, die PopUp Meldung kannst du getrost mit "Exit" der FB ausblenden, musst den Timer = 0 nicht abwarten ...
Wenn CrasLogs aktiviert sind, dauert aber schon allein das Booten gefühlt viel länger ...

gruß eraser65

Verwechselt ihr Crashlog und Debuglog?

Ich nicht, hab ja schon in #45 darauf hingewiesen.

Im Übrigen habe ich gerade bei mir die Startzeit mit und ohne aktivierten debug-log gemessen, es ist kein Unterschied messbar. Gewöhnungsbedürftig ist nur die Startmeldung, die man aber wegdrücken kann. Da schon gelegentlich nicht reproduzierbare Fehler auftreten nehme ich eine mögliche minimale Verzögerung in Kauf - vor allem dann, wenn ich ohnehin schon einen solchen Fehler suche.

Hast Du wirklich einen Crash? Also einen Neustart des Enigma2-Prozesses mit Anzeige der Start-Logos?
Oder ist die Box nur eingefroren? Ansonsten fragt man sich, wo das Crash-Log bleibt

Im ersten Debug-Log sieht das tatsächlich nach einem Crash aus. Da sind am Schluss Meldungen drin, die man sonst aus Crash-Logs kennt... Das ist ein BSOD, also leider ein Crash aus dem C++-Kern. Da ist leider nicht genau zu erkennen, was den Fehler ausgeführt hat.
07:10:10.080 [e2-core] [bsod.cpp] kill dvbapp2 horrible

Die letzte Meldung vor dem BSOD ist
07:10:09.932 [e2-core] [eEPGCache] lock already acquired --> retry

Das könnte etwas mit dem BSOD zu tun haben, muss es aber nicht...

Ah ja, mit dem Crash-Log passt das alles zusammen.
Da ist der gleiche Fehler-Stack zu sehen, der auch in dem Debug-Log ist.

Jetzt müsste nur noch eine Idee haben, was hinter Fehlermeldung [eEPGCache] lock already acquired --> retry steckt und ob die etwas mit dem letzten Call im Stack /usr/bin/enigma2(_ZN7eThread7wrapperEPv) zusammenhängt.

lt. Google "Schloss bereits erworben"

im Ernst
@RickX
Du kannst hiermit bestimmt was anfangen (einfach im Browser übersetzen lassen). Ich versteh das so, dass 2 Threads gleichzeitig auf eine Recource zugreifen wollen und da was gesperrt ist.
Frage ist, warum, da es bei anderen das Problem nicht gibt

Naja, was die Meldung bedeutet, ist ja ziemlich klar. Es wird versucht, auf den EPGcache zuzugreifen und dazu soll ein Lock gesetzt werden, da ist aber schon einer drauf. Die Frage ist halt, ob das tatsächlich das Problem ist, das den Crash auslöst oder ob das schonmal vorkommen kann.

@Zenturio

Beim BSOD keine Chance, also nimm schon mal das Baldrian zur Hand.

Ich hab jetzt nicht zurückgelesen - wurde hier eigentlich schon auf die "üblichen Verdächtigen" verwiesen? Also FCC, Epg.dat und SQL Datenbank?

Ich meine, ich hätte im Log vorhin was von FCC gelesen. Dazu könnte auch der Lock-Error passen.

@Zenturio

Und die anderen beiden "Verdächtigen"?
Wurde die epg.dat mal gelöscht und/oder in den Flash verschoben? (Hab's gefunden - ja, wurde)
Von der SQL Datenbank sehe ich im Log bisher nichts. Ich sehe aber auch nicht, dass die deaktiviert wäre. Wie sieht es damit aus?