Crashes Libreelec

Was ich im Log erkenne:

Absturzursache ist eine Zugriffsverletzung ("Segmentation Fault"). Normalerweise wird das durch einen Programmierfehler verursacht, kann aber auch einen Hardware-Fehler bedeuten. In deinem Fall geschah die Zugriffsverletzung, in einer unverdächtigen Funktion, die die Länge von Zeichenketten bestimmt. Ruft man (ds Programm) die Funktion mit einer "falschen" Zeichenkette auf (z.B. nicht korrekt terminiert, Speicher nicht korrekt/vollständig allokiert, ...) dann resultiert daraus eine Zugriffsverletzung. Das ganze passiert bei dir offenbar, während der Python-Prozessor von Kodi ein Script ausführen will. Vielleicht fällt dir da was ein? Ansonsten, da du das in unregelmäßigen Abständen unter verschiedenen Umständen kriegst - schau dir nochmals ein/mehrere andere Logs an. Ist das wieder in der strlen-Funktion? Wenn scheinbar andere Funktionen/Ursachen könnte das für einen HW-Fehler sprechen.

Du nutzt eine relativ alte Kodi Version (19.5)/LibreElec. Vielleicht hilft ein Update (bei HW-Fahler natürlich nicht).

Da du den Skin nennst - hast du mit Default-Skin gegen getestet? Passiert es da nicht?

Zitat von B.P.G.

Update würde ich ungern machen, ich habe meine Filme usw. alle auf in NTFS formatierten Festplatten, und ab LibreElec 11 scheint es damit - soweit man lesen kann - doch immer wieder Schwierigkeiten zu geben.

ich schätze da wirst du wohl nicht drum rum kommen, falls du das Problem nicht ohne Entwicklerhilfe in den Griff kriegst, denn die werden sehr wahrscheinlich sofort erklären, dass es f. die alte LE-Version keinen support mehr gibt.

Ich habe jetzt NTFS Probleme nicht konkret auf dem Radar (setze ich nicht ein), aber ich denke, dass, wegen neuere LE-Version => neuere Kernelversion => neuerer NTFS-Driver, du wahrscheinlich mit einer aktuellen und noch supporteten LE-Version langfristig auf der sichereren Seite wärst.

Du hättest dann vollen support f. dein aktuelles Problem (falls dann noch vorhanden) und ggf. f. NTFS-Probleme !

Ich würde dann auch nicht updaten, sondern neu installieren ...

Macht sich ggf. in Bugreports besser: "clean installed"

===

hier ist ein alter Foreneintrag mit deinem Fehler aus 2022:

Zitat von B.P.G.

Ich habe mir einmal vier Logs herausgesucht, bei 3 ist die Fehlermeldung völlig identisch, bei einem ein wenig anders.

Ja. Bisschen mehr Kontext zu überprüfen, wäre noch interessant gewesen - kannst du auch selbst tun. Im ersten Log ist eine Stelle (zu finden über "LWP 979", wofür oben im Log SIGSEGV angegeben wird):

Thread 1 (Thread 0x7f7536ffd640 (LWP 979)):
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x00007f758cbe6be5 in std::string::operator=(char const*) () from /usr/lib/libstdc++.so.6
[...]
#26 0x00000000007d6896 in CPythonInvoker::executeScript(_IO_FILE*, std::string const&, _object*) ()
[...]
############# END STACK TRACE ###############

Leider erkennt man (ich jedenfalls) nicht, was für ein Script ausgeführt werden soll. Im eigentlichen Kodi Log sehe ich da nicht so viel. Man kann sich leider auch nicht darauf verlassen, dass die letzte sichtbare Meldung vor dem Absturz nicht immer was mit dem Absturz zu tun hat, weil da i.d.R. viele Dinge mehr oder weniger asynchron gleichzeitig laufen. Und wenn die Zugriffsverletzung geschieht, kann Kodi nix mehr machen, auch nix mehr selber loggen.

Auch wenn ich schrieb, dass das oft/normalerweise ein Programmierfehler ist - oft äußert der sich nur in ungewöhnlichen Situationen, die man vielleicht als Benutzer vermeiden kann. Bei (sagen wir) falscher Konfiguration fängt vielleicht das Programm eine Fehlersituation nicht so ab, wie es sein müsste. Dass die Situation eintritt kann man aber vielleicht vermeiden. (Dennoch dürfte es der Quelltext nicht zu eine Zugriffsverletzung kommen lassen, und das ist was, was normalerweise gefixt werden muss. Wie schon erwähnt, wird das halt bei alten Versionen oft nicht mehr gemacht, da zu aufwändig/unklar ob es nicht eh schon gefixt ist, etc.).

Zitat von B.P.G.

Jetzt auf EXT4 neu formatieren heisst tagelanges rumkopieren - da mache ich noch einen Bogen drum

zumindest für den ersten [1] Copy-Vorgang (von externer NTFS-Disk nach PC mit NTFS) kann ich ein Tool empfehlen, was auch checksum-ed / Verified

[1]

eventuell auch beim Zweiten, z.b. wenn man die nachher ext4-formatierte Platte über eine Linux-Kiste per samba share einbindet, denn dann kann ich ja auch mit fastcopy (arbeitet unter Windoof, welches aber ext4 so nicht schreiben kann) arbeiten, weil beim share das drunterliegende HD-Filesystem keine Rolle spielt.

Hints:

a)

sofern man den, nach ggf. einer gewissen Zeit automatisch einsetzenden, Windows-SleepModus nicht vergessen hat auszuschalten, könnte man in Kombination von obigen checksum/verify die Copy-Aktion auch unbeaufsichtigt über die Nacht machen ...

b)

wenn man die Disk (noch) aus dem externen Gehäuse und direkt in einen PC schrauben kann, ergeben sich ggf. Vorteile ...

c)

disk checks mit ggf. smartmontools schadet nicht, insbes. falls man erst nach dem zweiten Copy-Vorgang realisieren muss, dass die Platte einen Schuss hat und sich diesen langwierigen Copy-Vorgang hätte sparen können, weil eine andere Disk her muss...