[remote] Plugin-Verwendung beendet VDR

nobanzai · 4. Februar 2024

Hi *,

ich verwende immer noch oft und gerne das Remote-Plugin.

Das hat bis vor kurzem (sehr vage, ich weiß) noch ohne Probleme funktioniert.

Gestern erst habe ich festgestellt, dass sich oft der VDR beendet, sobald ich das Plugin verwende. Teilweise passiert das bereits beim Connect, teilweise beim Aufruf des Menüs oder beim Setzen von Optionen im Menü.

Dummerweise gibt es nirgends einen Hinweis auf die Ursache - keinen Dump, keinen Eintrag im Journal oder in irgendeinem Log. Der VDR beendet sich einfach und wird wieder gestartet. Danach läuft er problemlos weiter, bis man wieder das Plugin nutzt.

Hat Jemand eine Idee, was das sein kann, bzw. wo man da suchen könnte?

Danke und ciao.

Michael.

wirbel · 4. Februar 2024

Vielleicht wäre das control plugin eine Alternative per telnet auf port 2002

nobanzai · 4. Februar 2024

Danke für den Hinweis.

control habe ich mal genutzt, aber irgendwann hat es nur noch zu segfaults geführt.

Danach habe ich auf remote umgestellt.

Ich teste es mal.

nobanzai · 4. Februar 2024

Leider passiert bei dem dasselbe wie bei remote - der VDR beendet sich bei Benutzung.

Diesmal gab es aber einen coredump:

Code

systemd[1]: Started Process Core Dump (PID 9854/UID 0).

Allerdings wurde der nicht gespeichert:

Code

coredumpctl
No coredumps found.

Ich habe in der /etc/systemd/system.conf

Code

[Manager]
DumpCore=yes
DefaultLimitCORE=infinity

stehen, trotzdem gibt es keine coredumps.

wirbel · 4. Februar 2024

Auch diese Version?

GitHub - wirbel-at-vdr-portal/vdr-plugin-control: This Plugin shows [VDR's](www.tvdr.de) menu via telnet session on port 2002. You may also use ssh/putty to the VDR computer, and use telnet locally. Dont forget to configure svdrphosts.conf.

This Plugin shows [VDR's](www.tvdr.de) menu via telnet session on port 2002. You may also use ssh/putty to the VDR computer, and use telnet locally. Dont…

github.com

nobanzai · 4. Februar 2024

Die habe ich verwendet.

wirbel · 4. Februar 2024

Wundert mich, keine Abstürze in den letzten Jahren.

nobanzai · 4. Februar 2024

Ich habs jetzt auf dem zweiten VDR zwar nicht mit control, sondern weiter mit remote ausprobiert.

Und da funktioniert es - in beiden Fällen habe ich es auch ohne Plugins ausprobiert.

Das System, auf dem es funktioniert, ist ein openSUSE Tumbleweed, nicht funktioniert es auf einem openSUSE Leap 15.5 - beide neueste Snapshot/Hotfix Stände.

wirbel · 4. Februar 2024

Also alles gut.

nobanzai · 4. Februar 2024

Außer dass ich keine Ahnung habe, warum es ausgerechnet auf dem headless Server nicht klappt 8-(

nobanzai · 4. Februar 2024

Von den Libs ist schon mal kein Unterschied.

openSUSE Leap 15.5:

Code

ldd libvdr-remote.so.2.6.6
    linux-vdso.so.1 (0x00007ffee0d8f000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a5a200000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f2a5a119000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2a5a4b8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f2a59e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2a5a50a000)

openSUSE Tumbleweed:

Code

ldd libvdr-remote.so.2.6.6
    linux-vdso.so.1 (0x00007ffee0d8f000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a5a200000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f2a5a119000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2a5a4b8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f2a59e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2a5a50a000)

nobanzai · 4. Februar 2024

Nachdem ich endlich rausgefunden habe, welche Opion noch fehlte, hat systemd einen stacktrace und einen core dump geschrieben.

seahawk1986 · 4. Februar 2024

Kannst du in der gdb-Konsole noch ein thread apply all bt full absetzen und die Ausgabe anhängen?

nobanzai · 4. Februar 2024

Habs gefunden, wie das geht - siehe Anhang.

nobanzai · 8. Februar 2024

Keiner ne Idee?

MarkusE · 8. Februar 2024

Hi,

Fehler scheint hier zu sein:

Code

Thread 1 (Thread 0x7f65da655780 (LWP 25031)):
#0  0x00007f65d9c0ed2b in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007f65d9c103e5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007f65d9c54c27 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007f65d9c5ccca in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007f65d9c5eb50 in _int_free () from /lib64/libc.so.6
No symbol table info available.
#5  0x00007f65da01af79 in FT_Remove_Module () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#6  0x00007f65da01b4a0 in FT_Done_Library () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#7  0x00007f65da00f15e in FT_Done_FreeType () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#8  0x00000000004c3d19 in cFreetypeFont::~cFreetypeFont (this=0x1eb49d0, __in_chrg=<optimized out>) at font.c:181
No locals.
#9  0x00000000004c3d69 in cFreetypeFont::~cFreetypeFont (this=0x1eb49d0, __in_chrg=<optimized out>) at font.c:182
No locals.
#10 0x00000000004c4008 in cFont::SetFont (Font=Font@entry=fontOsd, Name=Name@entry=0x5c3f7c <Setup+3996> "Sans Serif:Bold", CharHeight=CharHeight@entry=18) at font.c:408
No locals.
#11 0x00000000004fc741 in cOsdProvider::UpdateOsdSize (Force=<optimized out>) at osd.c:2326
        Width = 720
        Height = 480
        Aspect = 1
        MutexLock = {mutex = 0x5cbfc0 <cOsd::mutex>, locked = true}
...

Alles anzeigen

Aber warum eine Änderung des Fonts zu Absturz führt, kann ich auch nicht sagen.

rfehr · 8. Februar 2024

Zitat von MarkusE

Hi,

Fehler scheint hier zu sein:

Code

Thread 1 (Thread 0x7f65da655780 (LWP 25031)):
#0  0x00007f65d9c0ed2b in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007f65d9c103e5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007f65d9c54c27 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007f65d9c5ccca in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007f65d9c5eb50 in _int_free () from /lib64/libc.so.6
No symbol table info available.
#5  0x00007f65da01af79 in FT_Remove_Module () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#6  0x00007f65da01b4a0 in FT_Done_Library () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#7  0x00007f65da00f15e in FT_Done_FreeType () from /usr/lib64/libfreetype.so.6
No symbol table info available.
#8  0x00000000004c3d19 in cFreetypeFont::~cFreetypeFont (this=0x1eb49d0, __in_chrg=<optimized out>) at font.c:181
No locals.
#9  0x00000000004c3d69 in cFreetypeFont::~cFreetypeFont (this=0x1eb49d0, __in_chrg=<optimized out>) at font.c:182
No locals.
#10 0x00000000004c4008 in cFont::SetFont (Font=Font@entry=fontOsd, Name=Name@entry=0x5c3f7c <Setup+3996> "Sans Serif:Bold", CharHeight=CharHeight@entry=18) at font.c:408
No locals.
#11 0x00000000004fc741 in cOsdProvider::UpdateOsdSize (Force=<optimized out>) at osd.c:2326
        Width = 720
        Height = 480
        Aspect = 1
        MutexLock = {mutex = 0x5cbfc0 <cOsd::mutex>, locked = true}
...

Alles anzeigen

Aber warum eine Änderung des Fonts zu Absturz führt, kann ich auch nicht sagen.

Der font vieleicht nicht vorhanden

nobanzai · 8. Februar 2024

Zitat von rfehr

Der font vieleicht nicht vorhanden

Tja, nachdem gegen diesen VDR-Server "remote" *und* "control" crashen, auf dem VDR-Client "remote" aber nicht, habe ich mal auf dem Server alles an Font-Paketen analog dem Client installiert. Jetzt crasht "control" immer noch, aber dafür "remote" nicht mehr

Ist zwar keine wirklich Lösung, aber nachdem das jetzt wieder so ist wie vorher, bin ich durchaus zufrieden.

"control" wäre halt schöner, weil maintained.

MarkusE · 9. Februar 2024

> "control" wäre halt schöner, weil maintained.

Dann bitte doch den Maintainer um eine Korrektur ...

wirbel · 9. Februar 2024

Ich würde helfen, wenn ich das nachvollziehen könnte.

Ich selbst nutze 2.6.6 mit control - sogar sehr oft.

[remote] Plugin-Verwendung beendet VDR

Jetzt mitmachen!

Teilen