[VDR*ELEC] LibreELEC/AMLGX (arm) Probleme/Diskussion

rell · May 16, 2025 at 10:21 PM

Quote from vdr_rossi

Hoffe es ist bis zum Stillstand was zu erkennen.

Ich sehe, dass dynamite das log vollballert, aber ich habe keine Ahnung, was das bedeutet. Am Ende ist der alsa ringbuffer leer, das plugin startet eine Schleife neu und wartet auf das Startsignal, was nicht kommen kann, weil es im andere Thread nicht getriggert wird. Lange Rede kurzer Sinn, warum es zu dem ring buffer empty kommt, weiß ich (noch) nicht, aber dass danach gar nichts mehr geht, darf nicht sein. Das schaue ich mir an.

vdr_rossi · May 18, 2025 at 12:50 PM

Quote from rell

Ich sehe, dass dynamite das log vollballert, aber ich habe keine Ahnung, was das bedeutet.

Das hatte ich mal hier hinterfragt.

Dynamite orientiert sich am Loglevel des VDR. Muss das mal zurück auf log=1 setzen.

vdr_rossi · May 18, 2025 at 1:31 PM

Wenn es zu den genannten Abstürzen kommt, läuft am Ende die Storage Partition komplett voll

Da hilft ein: rm ~/.cache/cores/*

Aber eventl. sollte dieser Pfad besser auf eine RAM Disk zeigen? Das ein komplett volllaufen nicht passieren kann...
Ok, noch besser wäre die Ursache zu finde und abzustellen.

rell · May 18, 2025 at 2:21 PM

Da sind die core dumps drin und da kannst du ein backtrace abfragen. D.h.

gdb /usr/local/bin/vdr *.core

Und dann bt full, dann posten.

Mit der vorhanden systemd service startet vdr immer neu und schreibt core mit dumps voll. Das ist schlecht.

vdr_rossi · May 18, 2025 at 2:31 PM

Ok, hatte die core dumps auf einem nfs share geparkt. Aber nicht komplett...

Code

vdr1:/tmp/nfs/cores # gdb /tmp/nfs/cores/core*
Excess command line arguments ignored. (/tmp/nfs/cores/core.!usr!local!bin!vdr.1747523728.24963 ...)
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-libreelec-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
   <http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/tmp/nfs/cores/core.!usr!local!bin!vdr.1747522563.2799": not in executable format: file format not recognized
[New LWP 14366]
[New LWP 14370]
[New LWP 14377]
[New LWP 14381]
[New LWP 14385]
[New LWP 14390]
[New LWP 14373]
[New LWP 14374]
[New LWP 14378]
[New LWP 14382]
[New LWP 14367]
[New LWP 14389]
[New LWP 14372]
[New LWP 14388]
Core was generated by `/usr/local/bin/vdr --grab=/storage/.config/vdropt/tmp --watchdog=0 --lirc --ter'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000ffff8938b354 in ?? ()
[Current thread is 1 (LWP 14366)]
(gdb) bt full
#0  0x0000ffff8938b354 in ?? ()
No symbol table info available.
Backtrace stopped: not enough registers or memory available to unwind further

Display More

ist daran was zu erkennen?

Besser auf ein erneute core dumps warten...

rell · May 18, 2025 at 5:57 PM

Der richtige Aufruf wäre:

Code

gdb /usr/local/bin/vdr /pfad/zum/core/dump

Aber um wirklich was zu sehen, muss vdr bzw. das plugin, das den core dump auslöst (softhddevice-drm-gles?) mit debug symbolen gebaut sein. D.h. wenn du selber baust muss ein DEBUG=_vdr,_vdr-plugin-softhddevice-drm-gles vorne dran stehen.

Das kann ein segfault oder gewollter abort sein.

Quote from vdr_rossi

Wenn es zu den genannten Abstürzen kommt,

Von welchen Abstürzen redest du hier? Was kommt da im Log? Wie kanns du das reproduzieren?

vdr_rossi · May 18, 2025 at 7:30 PM

Ok, es mit debug symbol bauen - probiere ich aus. Baue lokal in einer ubuntu vm...

Quote from rell

Von welchen Abstürzen redest du hier? Was kommt da im Log? Wie kanns du das reproduzieren?

Habe das Gefühl das wir zwei Problemen auf der Spur sind:

1. -> Mai 14 18:15:14 vdr1 vdr[1022]: [1122] tp 450 (18/51) read incomplete section - len = 3119, r = 1742

2. -> Mai 16 18:40:51 vdr1 vdr[1018]: [1134] [softhddevice] AlsaPlayer: ring buffer empty Videopkts: 182
Mai 16 18:41:02 vdr1 vdr[1018]: [1159] i/o throttle activated, count = 1 (tid=1159)
Mai 16 18:41:05 vdr1 vdr[1018]: [1159] buffer usage: 70% (tid=1157)
Mai 16 18:41:08 vdr1 vdr[1018]: [1159] buffer usage: 80% (tid=1157)
Mai 16 18:41:10 vdr1 vdr[1018]: [1159] buffer usage: 90% (tid=1157)
Mai 16 18:41:12 vdr1 vdr[1018]: [1159] buffer usage: 100% (tid=1157)

Reproduzieren geht mit einfach laufen lassen und irgendwann steht alles, wenn ich Glück habe komme ich per ssh drauf und kann z.B. das oben gepostete Log ziehen.
Es ist von vdr Start bis Stillstand.

Bezüglich read incomplete section bin ich nicht sicher ob Helmut´s Patch es in den vdr geschafft hat? Bei mir sind 4x DVB Tuner dran... so wie ich das Verstehe "begünstigen" viele Tuner das Verhalten.

Sehe zu das ich in der Woche das debug symbol setze und dann aussagekräftige bt liefern kann.

rell · May 18, 2025 at 7:33 PM

Den leeren ring buffer schaue ich mir an, das kann ich bei einem UHD Testsender reproduzieren.

vdr_rossi · May 18, 2025 at 7:45 PM

Quote from rell

Mit der vorhanden systemd service startet vdr immer neu und schreibt core mit dumps voll. Das ist schlecht.

Wie lässt sich das besser umsetzen, hast Du dazu auch schon eine Idee? Wäre ein symlink in die RAM Disk praktikabel?
LibreELEC Logt (per journalctl) ja glaube ich eh nur ab Start und speichert nix aus der Vergangenheit ab.
Für bt ist das was anderes.

rell · May 18, 2025 at 7:55 PM

Du musst einfach den crash abfangen und vdr nicht mehr starten lassen.

https://github.com/Zabrimus/VDRSt…ropt.service#L8

Ich bin kein systemd profi, aber im service file kannst du das Verhalten einstellen. Ob oder evtl. wie oft ein Neustart versucht wird.

Dann hast du im log den Stand ab beenden...

vdr_rossi · May 24, 2025 at 2:32 PM New

Quote from rell

Aber um wirklich was zu sehen, muss vdr bzw. das plugin, das den core dump auslöst (softhddevice-drm-gles?) mit debug symbolen gebaut sein. D.h. wenn du selber baust muss ein DEBUG=_vdr,_vdr-plugin-softhddevice-drm-gles vorne dran stehen.

Möchte das jetzt umsetzen. Wo genau muss DEBUG=_vdr,_vdr-plugin-softhddevice-drm-gles vorne dran stehen?
Muss dann sicher das build Verzeichnis kompletten leer machen und einmal komplett neu bauen.

rell · May 24, 2025 at 4:55 PM New

Z.B. irgendwo im script

https://github.com/Zabrimus/VDRSt…r/build.sh#L279

oder es muss halt als Variable beim Bau gesetzt sein. Z.B. über ein export...

Und nein, nix löschen. Einfach bauen.

vdr_rossi · May 24, 2025 at 5:42 PM New

Ok, habe es eingefügt:

Code

...
  fi
 echo "   BUILD_SUFFIX=$BUILD_SUFFIX"
 echo "   VDR_OUTPUTDEVICE=$VDR_OUTPUTDEVICE"
 echo "   VDR_INPUTDEVICE=$VDR_INPUTDEVICE"
 export PROJECT="$PROJECT"
 export DEVICE="$DEVICE"
 export ARCH="$ARCH"
 export BUILD_SUFFIX="$BUILD_SUFFIX"
 export VDR_OUTPUTDEVICE="$VDR_OUTPUTDEVICE"
 export VDR_INPUTDEVICE="$VDR_INPUTDEVICE"
 export DEBUG=_vdr,_vdr-plugin-softhddevice-drm-gles
 if [ "$DORELEASE" = "true" ]; then
   echo "   BUILD_PERIODIC=nightly"
   export BUILD_PERIODIC="nightly"
 fi
...

Display More

gebaut, Image herüber kopiert + installiert.

Jetzt mal laufen lassen und Abstürze abwarten.

rell · May 24, 2025 at 6:32 PM New

Na hoffentlich kommt nix...

vdr_rossi · May 25, 2025 at 12:14 PM New

Schwierig.

Vdr läuft mit MinUserInactivity = 0 (vdr setup.conf).

Nach xx Stunden friert das TV Bild ein, System ist noch per ssh erreichbar, kein Coredump in ~/.cache/cores/ vorhanden, im Log kommt sporadisch:

Code

...
Mai 24 19:20:18 vdr1 vdr[994]: [1434] [softhddevice] invalid PES audio packet
Mai 24 19:20:19 vdr1 vdr[994]: [1434] [softhddevice] invalid PES audio packet
Mai 24 19:20:47 vdr1 vdr[994]: [1589] [softhddevice] invalid PES audio packet
...
Mai 25 00:57:23 vdr1 vdr[994]: [14626] [softhddevice] invalid PES audio packet

ist das verdächtig?

Außerdem Richtung Ende:

Code

...
Mai 25 02:19:10 vdr1 kernel: em28xx 3-1.4:1.0: write to i2c device at 0xc8 failed with unknown error (status=3)

Was wiederum ein neues Problem aufwirft. Da geht es um USB Schnittstelle Tuner. (Gleiches Problem im Web gefunden). Klar ohne DVB Signal steht das Bild.
Erste Maßnahme war jetzt aktiven USB Hub auf USB2 Schnittstelle am RockPi 4 umzustecken.

Wie sollte sich Vdr bei "weggezogenem" DVB Signal verhalten?

Mal weiter beobachten.

rell · May 25, 2025 at 1:26 PM New

Ich würde nicht ausschließen, dass softhddevice-drm-gles Probleme bekommt, wenn das Signal abreißt o.ä.

Wie schon gesagt gibt es ein Problem, wenn der alsa buffer leer läuft, das konnte ich im Normalbetrieb aber noch nie bei mir beobachten.

Im Optimalfall sollte ein Umschalten auf einen Kanal den VDR wieder zurückbringen, aber ich vermute, das klappt nicht.

Siehst du im Log irgendwo diese Zeile https://github.com/rellla/vdr-plu…audio.cpp#L1232 ohne dass im Anschluss irgendwann https://github.com/rellla/vdr-plu…audio.cpp#L1240 folgt? Das wäre das angesprochene Problem.

Ansonsten hatte ich an einem früheren Rechner massive USB Probleme und die haben zu ständigen USB disconnects geführt, was dem VDR nicht gefallen hat. Das kann durchaus das Problem sein, dass sich VDR dann nicht da raus retten kann, ist evtl. nur die Folgen.

Die PES Meldungen deuten auf ein falsches audio Paket hin. Sind aber unbedenklich, weil die Daten einfach übersprungen werden.

vdr_rossi · May 25, 2025 at 1:49 PM New

Quote from rell

Siehst du im Log irgendwo diese Zeile https://github.com/rellla/vdr-plu…audio.cpp#L1232 ohne dass im Anschluss irgendwann https://github.com/rellla/vdr-plu…audio.cpp#L1240 folgt? Das wäre das angesprochene Problem.

Hmm, da ich vdr log=1 gesetzt habe, würde das überhaupt im vdr Log auftauchen? Aktuell kommt keines von Beiden vor.

Werde sehen ob ich diesen leeren alsa buffer irgendwie reproduziert bekomme.
Und natürlich das USB Tuner Problem beseitigen.

Am Ende führt beides zum beobachteten Stillstand. Ich schaue also weiter auf Logs...

rell · May 25, 2025 at 1:52 PM New

Je nachdem welche plugin Version du hast, kannst du die loglevel im setup menu einstellen.

Standard, Drm, codec, avsync und sound wären gut.

vdr_rossi · May 26, 2025 at 8:42 AM New

Code

vdr1:~ # gdb /usr/local/bin/vdr /storage/backup/core.!usr!local!bin!vdr.1748174250.1587
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-libreelec-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
   <http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/vdr...
[New LWP 1629]
[New LWP 1587]
[New LWP 1609]
[New LWP 1611]
[New LWP 1742]
[New LWP 1613]
[New LWP 1594]
[New LWP 1636]
[New LWP 1588]
[New LWP 1743]
[New LWP 1744]
[New LWP 1610]
[New LWP 1740]
[New LWP 1612]
[New LWP 1741]
[New LWP 1616]
[New LWP 1745]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr --grab=/storage/.config/vdropt/tmp --watchdog=0 --lirc --ter'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000ffffb250341c in _Unwind_Find_FDE () from /usr/lib/libgcc_s.so.1
[Current thread is 1 (Thread 0xffff827cf140 (LWP 1629))]
(gdb)

Display More

rell · May 26, 2025 at 8:45 AM New

Zeigt ein "bt full" mehr Infos?

Participate now!