Beiträge von joeAverage62

dito, hier auch keine "Fabrik-Abbrecher" gesehn' ..., auch nicht während LE12 nightly bzw. jetzt LE13 nighly daily use !

grad' 'nen alten Tatort (mit Falke) gesehn und ein paar alte Stücke darin wiedergehört:

Roxy Music - If There is Something

und

Creedence Clearwater Revival - Fortunate Son (passt m.M.n. gut in die Zeit, weil gegen "Wir müssen kriegtüchtig -Rababa Babara - wer'n )

aktuell setze ich LE13 (letztes nightly: 20240624-d897522) auf einem Nuc13 mit deinem letzten Addon (seit gestern mit den letzten Einzelupdates) ein

ich sehe nicht nur mit der letzten Version, sondern schon mit der Version davor Crashes

crash log attached

wie bekommen ich den crash ?

1. ich suche mit der AddOn-Suche nach z.B. Tatort:

dann bekomme ich alle Tatorte angezeigt und gehe dann ans Ende der Liste, dann noch mal ans Ende der dann angezeigten der Liste, und dies so ein paar Mal bis ich einen ungesehenen/brauchbaren Tatort gefunden habe

2. (wahrscheinlich nicht relevant, aber zur Vollständigkeit): schaue diesen Tatort bis Ende an und bin dann wieder in der Liste

3. möchte dann per Backspace-Taste meiner Fernbedienung (kleines Keyboard: Rii Mini i8+) die Liste wieder zurück / rückwärts / hoch wieder zur AddOn-Suche ...

Ergebnis:

nach mehrfachen Drücken der Backspace-Taste crashed das AddOn

meine , dass dies frühen nicht crashte ..., etwa 2 Addon-Version früher

rols1, du musst dass nicht gestern gefixed haben !

Es ist Sommer: Biergarten, Tauchen, what-so-ever ... ist wichtiger !

Danke f. deinen Einsatz !!!

ist zwar ein Doppelpost (Kommentar #866), aber...

Porcupine Tree - Way Out Of Here -Live in Tilburg (HD) -

Zitat von tantalos

Manchmal erinnert er mich an Peter Gabriel, oder?

yep, ein wenig

abba wir können den ja ma' auflegen:

Peter Gabriel - Red Rain

to complete "VoKoHilLa's"

Rod Stewart - (I Know) I'm Losing You

David Bowie - Rebel Rebel (TopPop)

TopPop ~war~ (in den 70-zigern) eine niederländische TV Sendung f. so "Rüppel" wie mich und natürlich der Erstkontakt mit Bowie (mit VoKoHiLa; brauchte ich dann auch ! )

Jean Genie

ich muss vorausschicken, dass ich keine Ahnung von OMV habe.

da hier ein TVH-4.3 - unter LE zwar - einwandfrei läuft und deiner ja erst nach Umzug der Platte spinnt:

in deinen Log stehen viele

"space usage 94.7% matches resource limit [space usage > 85.0%]"

und ich dies als mangelnden Platz intepretiere (kann mich irren, weil es ggf. *vor* dem Platttenumzug war ?)

meine Theorie:

weil TVH f. EPG-Grap-Aktionen Dateien anlegt, für die aber kein Platz sind (?), fällt TVH auf die Fresse:

2024-06-09T20:25:57.023226+02:00 openmediavault tvheadend[556139]: epgdb: parsing 8929116 bytes
2024-06-09T20:25:57.262804+02:00 openmediavault tvheadend[556139]: epgdb: loaded v3
2024-06-09T20:25:57.266799+02:00 openmediavault tvheadend[556139]: epgdb:   config     1
2024-06-09T20:25:57.266898+02:00 openmediavault tvheadend[556139]: epgdb:   broadcasts 20916
2024-06-09T20:25:58.418119+02:00 openmediavault tvheadend[556139]: CRASH: Signal: 11 in PRG: /usr/bin/tvheadend (4.3-2335~gf15f05761) [20b310209e6167d5017f3a5100b10c6ba2126ca2] CWD: /  
2024-06-09T20:25:58.418539+02:00 openmediavault tvheadend[556139]: CRASH: Fault address (nil) (Address not mapped)
2024-06-09T20:25:58.418678+02:00 openmediavault tvheadend[556139]: CRASH: Loaded libraries: linux-vdso.so.1 /lib/x86_64-linux-gnu/libdvbcsa.so.1 /lib/x86_64-linux-gnu/libssl.so.3 /lib/x86_64-linux-gnu/libcrypto.so.3 /lib/x86_64-linux-gnu/libz.so.1 /lib/x86_64-linux-gnu/libpcre.so.3 /lib/x86_64-linux-gnu/liburiparser.so.1 /lib/x86_64-linux-gnu/libavahi-common.so.3 /lib/x86_64-linux-gnu/libavahi-client.so.3 /lib/x86_64-linux-gnu/libdbus-1.so.3 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libmvec.so.1 /lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libsystemd.so.0 /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/libcap.so.2 /lib/x86_64-linux-gnu/libgcrypt.so.20 /lib/x86_64-linux-gnu/liblzma.so.5 /lib/x86_64-linux-gnu/libzstd.so.1 /lib/x86_64-linux-gnu/liblz4.so.1 /lib/x86_64-linux-gnu/libgpg-error.so.0 /lib/x86_64-linux-gnu/libnss_compat.so.2 /lib/x86_64-linux-gnu/libnss_systemd.so.2  
2024-06-09T20:25:58.418889+02:00 openmediavault tvheadend[556139]: CRASH: Register dump [23]: 00000000000000460000000000000073000000000000000000007f83b89b01480000562559fe00d4000056255d8580e000007ffc27412fc000000000000000b400000000000000000000562559fe00d40000000000000000000056255e9fd1a000000000000000000000000000000000000000000000000000007ffc27412f8800007f83b88c8cb60000000000010293002b0000000000330000000000000004000000000000000efffffffe7ffbfa170000000000000000
2024-06-09T20:25:58.423557+02:00 openmediavault tvheadend[556139]: CRASH: STACKTRACE
...

schon mal den Total-Abriss (mit vorherigem Backup) von TVH, Reboot, Neuinstall v. TVH, probiert ?

mit vlt. danach mit zwei terminals offen:

- in einem: journalctl -f oder tail -f <log dateien v. TVH)

- im anderen: systemctl restart tvh.service

f. meine Plattenplatzproblem-Theorie könnte ggf. auch sprechen, wenn du TVH mal

- "Erzwinge initale EPG--Suche beim Start" und

- "Force Intial EPG Grab at start-up" (siehe 2. screenshot in Kommentar #1)

temporär mal abschaltest und TVH danach startest und das gleiche mit obigen wieder AN

tvh crash bei aus/an ?

===

unterstellend, dass du die Platte auf der TVH lag ge'dd'ed hast:

ich könnte mir vorstellen, dass beim dd irgenwelche links von TVH (welche ? keine Ahnung !) zerlegt wurden und TVH daher nicht mehr richtig funzt ...

Dabei sollen Totalabriss (löschen) und Neuinstallation gewährleisten, dass ggf. diese links wieder korrekt gesetzt werden (können; bei nur Drüberinstallation ohne Löschen ggf. aber nicht)

Zitat von Skogtroll

Meinst Du mit LE = LibreElec?

Ja !

Tips:

a) speichere dir das Bios irgendwo hin, dann kannst du bei Malfunctions eines Neuen zurück zum Alten. (Wie steht in den Begleitdokumenten)

- ASUS hat zwar (noch) eine Bios-Release-Historie, aber garantiert ist das nicht -

b) grase alle paar Monate die Asus-Seite ab, ob ein Neues erschienen ist (die fixen u.a. intervallweise auch CPU-Bugs)

Zitat von DonTrafo

Bei BIOS Updates bin ich immer etwas vorsichtig die genaue Bezeichnung des Mini-PC ist Intel NUC7CJYH und da kann es sein das nach dem Update Linux nicht mehr funktioniert.

kann ich so nicht bestätigen, als nun zus. rd. 9,5 Jahre NUC-User

bios ist hier (Intel hat nach Asus verkauft):

NUC7CJYH - Support

Urggghhh, mir fällt da gerade ein (bin schon alt/verkalkt), dass du tvh auch ohne Kommandozeilen--Gehampel unter LE (hast du das ?) restarten kannst

in LE:

Settings => Addon => my-addon => services und dort TVH disable und enable

Zitat von DonTrafo

bei den beiden Linux und Windows10 funktioniert die Bildausgabe ohne Probleme

Diesen Satz verstehe ich nicht vollständig !

Heisst dass du hast Einzelinstallationen probiert ?

Oder heisst es dass du jetzt wenn du z.b. Windows gebootet hastest nach Linux umbootest und dann geht es nicht mehr ?

f. diesen Fall:

hatte mal eine Dualboot-Kiste.

Jedesmal wenn ich von Windows nach Linux bootete lief eine LAN-oder WLAN-Karte nicht mehr.

Background war das Windows die Karte in einem Zustand lies (wahrscheinlich PCI-e-SleepModi), den Linux nicht verändern konnte.

Problem war -glaube ich- der SleepModus-Shutdown, anstelle Richtigem, von Windows.

Fix war -galube ich- in einem WindowsTerminal "powercfg -H off" und reboot to Windows, dann Linux

===

anderer Gedankengang:

ich muss vorausschicken, dass ich KEIN UEFI-Äkschpärte bin !!!, aber ich glaube UEFI inititisiert auch Teil der GPU ... (kann mich irren !)

ich schätze deine -ggf- Einzelinstallation booteten alle UEFI.

wenn ja, tut es das in Dulaboot auch (noch) ?

mal ins Bios geschaut, ob es da was zum Ein-/Umstellen gibt ?

zum Nuc's hat es mal HDMI-FW-Updates gegeben (Update nur über Windows)

Herstellerseite kontaktiert ?

wenn du "nvme-cli" (heisst vlt. f. Mint anders) installiert hast, dann kööntest du die nvme testen mit:

sudo nvme device-self-test /dev/nvme0n1 -n 1 -s 1h # Start a short device self-test operation
sudo nvme device-self-test /dev/nvme0n1 -n 1 -s 2h # Start a extended device self-test operation
  
sudo nvme device-self-test /dev/nvme0n1 -n 1 -s 0h # aktueller Status des laufenden Tests, sprich Test fertig (J/N ?)

Test Ergebnisse

sudo nvme smart-log /dev/nvme0 -o normal
oder
sudo smartctl -a /dev/nvme0

P.S.

ich weiss nicht, ob deine nvme die Tests kann und ob die Kommandos auch mit externen Gehäusen laufen.

obige "/dev/nvme0n1" musst du anpassen !

Alternative: Herstellertools (meistens nur f. Windows)

Zitat von rubicon

Ja, aber das wäre der alte umständliche Weg. Das geht mit HA deutlich einfacher und effektiver - ich weiß nur nicht, wie

weiss ich so auch nicht.

Aber es gibt ein addon unter Kodi, um die log anzuzeigen, vlt. kann man sich damit was basteln ...

Zitat von Skogtroll

Ich vermute, das ist auch ein TV-Headend Re-Start...

yup

Zitat von Skogtroll

...aber ich verstehe nicht was Du z.B. mit "ssh" meinst?!

wenn ssh login auf dem PI eingerichtet ist

von einem anderen linux-PC aus auf den PI zugreifen:

ssh root@<IP-Adresse-des-PI-hier-rein>

oder

von einem Windows-PC aus via putty (=> Internetsuche)

dann arbeitest du direkt auf dem PI

more to read:

Secure Shell – Wikipedia

entweder restart PI oder

mit ssh auf den PI, mit "systemctl | grep tvh" den service f. TVH finden und dann "systemctl restart <tvh-service-hier rein>"

Zitat von brandtan

Sehr ausführlich,

passcht schooo ...

Zitat von brandtan

Ja, das Debug log schalte ich ein und überstelle es sobald der Screensaver noch einmal hängen sollten.

Da kch erstmal nur vom Screensaver sprach, habe ich den einmal abgeschaltet ...

logik ?

wenn du den screensaver abschaltest, wird der wohl kaum hängen bleiben können ... (ich klugscheixx wieder, I know ...)

Zitat von brandtan

Der Zugriff via SSH funktioniert.

dann ist das Teil auch nicht abgestürzt, eher nur Teile davon (sach ich ma so, nach kurzen Überflug durch deine logs, wo *ich* auf die Schnelle so nix erkennen kann)

Für mich ist es ein Absturz, wenn ich die Kiste nur noch via Stecker ziehen wieder in Schwung bringen kann

Zitat von brandtan

Keine Möglichkeit aber via kill -9 $pidof_kodi.sh Kodi neu zu starten.

kill -9 schiesst den Prozess auch nur ab; restartet wird da nix !

und wenn schon, dann:

kill -9 $(pidof kodi.sh)

*und* [1]

kill -9 $(pidof kodi.bin)

oder nur

kill -9 $(pidof kodi.bin)

[1] proof nach "kill -9 $(pidof kodi.sh) "mit "ps aux | grep kodi"

=> die kodi.bin lofft noch, weil die durch die kodi.sh gestartet (?) wurde

und da die *.sh caller von *.bin ist (?), reicht "kill -9 $(pidof kodi.bin) aus um sowohl die *.bin, als auch die *.sh zu beenden

zumindest hier auf einem PC.

noch was:

"$pidof_kodi.sh" ist eine Variable mit Namen "pidof_kodi.sh"

"$(pidof kodi.sh)" ist auch eine Variable, deren Inhalt aber dynamisch mit der Ausgabe eines Befehls (alles zwischen den Klammern) gefüllt wird

[KlugScheiXX-Mode OFF]

===

anyway, ich denke nicht das es auf PI's anders ist als auf PC's (x86 Architekturen) und denke, dass es per systemctl gehen müsste.

also kodi restart mit:

systemctl restart kodi.service

===

bzgl. KODI_CRASH.log fällt mir nur ein, dass der crash log beim graphischen updaten von LE erzeugt wird.

manuelle Updates erzeugen keinen crash log. Bug ist gemeldet, aber nicht gefixed

dein crash log sieht zumindest ähnlich aus, sodass es der graph. update bug sein könnte.

Proof:

- crash log löschen

- ssh login

- cd .update

- curl <LE-Update.img>

- reboot

crash log da ?

- update via graph. Oberfläche

crash log da ?

===

du solltest auf jeden Fall debug einschalten !

z.B.:

debug log ein via advancedsettings.xml

mit Inhalt:

<advancedsettings version="1.0">
   <loglevel hide="false">1</loglevel>
</advancedsettings>

Achtung:

wenn du schon eine advancedsettings.xml unter "/storage/.kodi/userdata" hast, musst du die sichern und/oder ggf. ergänzen