Passiert das auch mit z.B. xineliboutput oder dem neuen vaapivideo?
Nur um sicher zu gehen, dass es wirklich an softhddevice liegt.
Du hattest ja schon mal einen falschen Verdacht.
[softhddevice] VDR hängt nach jeder OSD-Anzeige
-
-
Hihi, ich schlage mich schon seit gestern mit Gemini rum
Leider trifft nix von dem zu, was er da oben gesagt hat - und auch die gefühlt tausend anderen Tips haben keine Besserung ergeben bisher - auch wenn ich spannende neue Kernelparameter kennenlernen durfte: i915.enable_guc=2 i915.enable_psr=0 i915.enable_dc=0 intel_idle.max_cstat=1 pcie_aspm=off
Auch Umstellen auf Intel statt modesetting Driver für X11 hat nix gebracht, ebensowenig diverse Optionen in der xorg.conf für Intel oder modesetting.
Gestern schien es mit dem Intel Driver und den o.a. Kernelsettings mal besser geworden zu sein, aber das war auch nur temporär.
Auch der llvmpipe Entry will nicht verschwinden.Dazu behaupt Gemini, dass die intel_gpu_top Anzeige viel zu hohe Werte zeigen würde für das, was da ablaufen würde - aber das kann ich nun garnicht beurteilen.
Danke dir in jedem Fall trotzdem für die Hinweise!
Hi nobanzai,
das hört sich nach meiner Leidensgeschichte an (also das mit dem Renderer llvmpipe; nicht unbedingt die Auswirkungen, die sahen bei mir anders aus)... es waren ungünstige Kombinationen der Versionen von Treibern und Bibliotheken:
[softhddevice] kein video output seit dist-upgrade - error: video/egl: eglCreateImageKHR failed
Mittlerweile habe ich auf kUbuntu 2510 aktualisiert, was ohne Eingriffe sofort korrekt funktionierte.Viele Grüße,
Chriss -
VDR-Aufruf (alles aktuellste Versionen auf den jeweiligen git Repos):
Code /usr/sbin/vdr -u vdr -c /etc/vdr -E /home/vdr/epg.data -L /usr/lib/vdr -r /etc/vdr/scripts/vdr.exec -t /dev/tty8 -v /var/spool/video/video0 -g /home/vdr/tmp/grabdir -w 0 --lirc=/run/lirc/lircd --dirnames=,,1 --shutdown=/etc/vdr/scripts/vdrshutdown -D0 -Pcontrol --port=4444 -Psofthddevice -v va-api-egl -d :0.0 -g 1920x1080+0+0 -a pipewire -p pipewire -l 3 -N -Pchannellists -Pdvbhddevice -Pepgsync -Psvdrpservice -Piptv -Pwebsocket --logodir=/etc/vdr/logos --port=44444 -Posdteletext --directory=/home/vdr/teletext -Pskinnopacity --logopath=/etc/vdr/logos --epgimages=/var/spool/video/epgimages --iconpath=/etc/vdr/plugins/skinnopacity/nopacity_iconpack/nopacity/ -Ptvscraper --dir /var/spool/video/tvscraper --readOnlyClientIch würde mal testweise nicht unbedingt nötige Komponenten deaktivieren.
Und kann man softhddevice und dvbhddevice gleichzeitig benutzen?
-
Ich würde mal testweise nicht unbedingt nötige Komponenten deaktivieren.
Und kann man softhddevice und dvbhddevice gleichzeitig benutzen?
Kann man.
Aber ich habe auch schon Tests mit nur softhdddevice ohne weitere Plugins gemacht - ohne Verbesserung.
-
Passiert das auch mit z.B. xineliboutput oder dem neuen vaapivideo?
Nur um sicher zu gehen, dass es wirklich an softhddevice liegt.
Du hattest ja schon mal einen falschen Verdacht.xineliboutput habe ich nicht mehr, aber mit vaapivideo passiert es nicht.
-
Da es länger hängt, könnte man es evtl. schaffen in der Zeit einen Coredump zu schreiben.
Wenn man raus bekommt, wo es genau hängt, käme man vielleicht weiter.
-
Da es länger hängt, könnte man es evtl. schaffen in der Zeit einen Coredump zu schreiben.
Wenn man raus bekommt, wo es genau hängt, käme man vielleicht weiter.
Du meinst den laufenden VDR zum dumpen bringen?
-
Das geht bei laufendem Prozess irgendwie mit GDB, wenn ich das noch recht erinnere.
Alternativ kann man dem Programm einfach SIGABORT senden, das sollte das Programm hart beenden (KILL!) und einen Coredump schreiben.
Probiert habe ich das aber am VDR noch nicht.
Aber das bitte nur auf einem Testsystem machen, da können gerade geöffnete Dateien kaputt gehen! -
Du kannst deinen VDR starten und parallel in einem anderen Terminal gdb starten.
Sobald VDR hängt, kann man sich in der gdb Konsole mit "attach _pid_von_vdr_" in den Prozess hängen, woraufhin der angehalten wird.
Mit "info threads" siehst du alle offenen threads und z.B. mit "thread 20" "where" kannst du schauen, wo der Thread im Code gerade ist. Das könnte schon weiterhelfen.
-
Schwer zu sagen. Am besten, du kannst die Plugins eingrenzen. Dann alle anderen.
Zueret "thread 1", dann "where", dann den nächsten Thread "thread 2".
Vorausgesetzt, du hast die debug Symbole drin, musst du im Quellcode schauen, wo er gerade ist und drüber nachdenken, ob das Sinn macht und ob das damit zu tun haben kann.
So würde ich es machen.
-
Schwer zu sagen. Am besten, du kannst die Plugins eingrenzen. Dann alle anderen.
Zueret "thread 1", dann "where", dann den nächsten Thread "thread 2".
Vorausgesetzt, du hast die debug Symbole drin, musst du im Quellcode schauen, wo er gerade ist und drüber nachdenken, ob das Sinn macht und ob das damit zu tun haben kann.
So würde ich es machen.
Voraussetzung wäre, man würde verstehen, was der Quellcode treibt - da habe ich bei mir doch ernste Bedenken.
-
Hm, aber ohne in den Quellcode zu schauen wird man das Problem nicht finden bzw. lösen können...
-
Hm, aber ohne in den Quellcode zu schauen wird man das Problem nicht finden bzw. lösen können...
Das glaube ich schon auch, nur werd *ich* das auch mit in den Quellcode kucken nicht finden können.
-
Die beiden von softhddevice, nehme ich an?
Den oglThread unbedingt auch.
Und nur mit den absolut nötigen Plugins wäre das auch etwas übersichtlicher.
-
Da Dein VDR ja gar nicht mehr reagiert müsste das der Haupththread sein (also Nr 1) und der hängt lt. Deinem Log in __lll_lock_wait, das passt also zusammen. Deshalb schau mal, wo er hängt. 'where' kannte ich noch nicht, in nutze immer 'list'. 'bt' bzw 'bt full' von Thread 1 wäre auch interessant um zu sehen wir er an diese Stelle kommt.
-
Falls es daran liegt, daß ein Lock zu lange gehalten wird, hilft:
1. Den Patch anwenden
2. MAX_LOCK_TIME ändern, z.B. auf #define MAX_LOCK_TIME 1 (1 wie 1 Sekunde). Dann werden alle Treads gemeldet, die einen Lock länger als 1 s halten
3. VDR neu übersetzen.
4. Plugins neu übersetzen
5. VDR restarten
6. Den Fehler möglichst schnell reproduzieren
7. Im Log nach "ERROR" suchen, zu dem Timestamp, an dem der Fehler auftrat.
Anmerkungen:
- Das ist jetzt nur für die Fehlersuche. Für Produktivbetrieb ist #define MAX_LOCK_TIME 1 zu kurz. Da empfehle ich #define MAX_LOCK_TIME 60. Wenn nur der Wert von MAX_LOCK_TIME geändert wird, dann genügt es VDR neu zu übersetzen. Die Plugins brauchen dann nicht neu übersetzt werden.
- Es kann da auch andere Ursachen für die Verzögerung geben. S. z.B. [Patch] Mehr Informationen bei "ERROR: cTimer::Matches()" . Da dachte ich erst, daß es an einem zu lange gehaltenen Lock liegt. War aber nicht so. Es lag an einer Verzögerung im VDR Main Thread.
-
Falls es daran liegt, daß ein Lock zu lange gehalten wird, hilft:
1. Den Patch anwenden
2. MAX_LOCK_TIME ändern, z.B. auf #define MAX_LOCK_TIME 1 (1 wie 1 Sekunde). Dann werden alle Treads gemeldet, die einen Lock länger als 1 s halten
3. VDR neu übersetzen.
Wenn ich das übersetze und den vdr mit -V aufrufe, bekomme ich direkt einen Segfault:
Code
Display More./vdr -V vdr (2.8.1/12) - The Video Disk Recorder channellists (0.0.6) - Manage your channellists control (1.0.2) - telnet remote control dvbhddevice (2.2.0) - HD Full Featured DVB device epgsync (1.0.2) - Import EPG of an other VDR graphtftng (0.6.17-GIT76a0802) - VDR OSD on TFT iptv (2.6.13-GIT-8a1f990) - Experience the IPTV osdteletext (2.3.1) - Displays teletext on the OSD skinnopacity (1.1.20) - 'nOpacity' Skin softhddevice (2.4.8-GIT5d6611e) - A software and GPU emulated UHD device status (2.6.2) - Status monitor test svdrpservice (1.0.0) - SVDRP client tvscraper (1.2.15) - Scraping movie and series info vaapivideo (1.4.2) - Hardware-accelerated video playback with VAAPI websocket (0.0.2) - Send VDR status via websocket Segmentation fault (core dumped) ./vdr -V
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!