softhddevice mit High Level OSD

So, das Umschalten des primären Ausgabegerätes auf dummydevice über dbus2vdr scheint mit dem normalen softhddevice auch zu funktionieren, wenn das OSD offen ist - da habe habe ich allerdings noch das Problem, dass das OSD (insbesondere des Skindesigners) nach dem Reattachen in Fetzen hängt, wenn das Menü zuvor offen war (svdrpsend plug skindesigner DLIC hilft da nichts, weil das OSD nie zu war).
Leider hängt sich der VDR mit dem softhddevice-openglosd beim Umschalten auf das dummydevice bei offenem OSD genauso weg, wie beim normalen Detachen:

(gdb) bt
#0  0x00007f1c08213f2c in __lll_lock_wait ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f1c08211dc0 in pthread_cond_broadcast@@GLIBC_2.3.2 ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00000000005135d6 in cCondWait::Signal() ()
#3  0x00007f1bf62423e1 in cOglThread::DoCmd (this=0x1d41e80,
    cmd=cmd@entry=0x2339150) at openglosd.cpp:1379
#4  0x00007f1bf624289a in cOglPixmap::Fill (this=0x1c1a900, Color=0)
    at openglosd.cpp:1667
#5  0x00007f1bf915750f in cViewElement::Render (this=0x2247480)
    at coreengine/viewelement.c:341
#6  0x00007f1bf914ce66 in cViewChannel::Flush (this=0x205e2c0)
    at coreengine/viewdisplaychannel.c:182
#7  0x00000000004ac36c in cInterface::GetKey(bool) ()
#8  0x0000000000470272 in main ()
(gdb) bt full
#0  0x00007f1c08213f2c in __lll_lock_wait ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1  0x00007f1c08211dc0 in pthread_cond_broadcast@@GLIBC_2.3.2 ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2  0x00000000005135d6 in cCondWait::Signal() ()
No symbol table info available.
#3  0x00007f1bf62423e1 in cOglThread::DoCmd (this=0x1d41e80,
    cmd=cmd@entry=0x2339150) at openglosd.cpp:1379
        doSignal = true
#4  0x00007f1bf624289a in cOglPixmap::Fill (this=0x1c1a900, Color=0)
    at openglosd.cpp:1667
        PixmapMutexLock = {<cMutexLock> = {mutex = 0x79d860 <cPixmap::mutex>,
            locked = true}, <No data fields>}
#5  0x00007f1bf915750f in cViewElement::Render (this=0x2247480)
    at coreengine/viewelement.c:341
        node = 0x1bd83e0
#6  0x00007f1bf914ce66 in cViewChannel::Flush (this=0x205e2c0)
    at coreengine/viewdisplaychannel.c:182
No locals.
#7  0x00000000004ac36c in cInterface::GetKey(bool) ()
No symbol table info available.
#8  0x0000000000470272 in main ()
No symbol table info available.

Ich habe hier mit vdr4arch (gleich Spezifikationen wie bei lostinspc) keine Probleme.
Ich schalte zusätzlich noch zwischen Kodi und VDR hin und her, indem ich softhddevice in den Hintergrund (SUSP; REMO OFF) schicke.

Beim Zappen habe ich auch keine Probleme festgestellt mit skindesigner-simplex

Zerrissenes OSD beim Umschalten ist zu erwarten. Der vdr schickt ja immer nur Differenzen zum aktuellen OsdProvider, deshalb kann da nichts vernünftiges angezeigt werden.
Das ist wie mit der Kanalinfo beim detach-Start von shd.

Lars

Zitat von louis

Hm, ok. Da scheint dann wirklich noch ein Problem mit dem blinkenden Icon im Skindesigner vorzuliegen. Das muss ich mir nochmal anschauen...

Zitat von »Murry«
Und zweimal hatte ich das Problem das der vdr nicht mehr auf die Fernbedienung reagierte (irw zeigte die normalen dev input Ausgaben)

Das widerum sollte nichts mit dem OpenGL OSD zu tun haben...zumindest würde mir kein Grund einfallen. Hattest du das vorher niemals nie nicht?

Hallo louis,

Mit LCARS funktioniert es. Mit MetrixHD brauche ich bei einer Aufnahme nur ein paar mal um zu schalten und schon hängt er. Vorhin habe ich beobachtet das dann das rote Rec-Symbol nicht mehr blinkte.

Gruß,

Murry

Zitat von louis

Was genau verstehst du unter "hängen bleiben"?

Dann friert zumindestens mal das OSD komplett ein (evtl. auch der ganze VDR, bin nicht sicher).

Der Watchdog schlägt nicht zu. Coredump gibts auch nicht, nur den von Murry angeführten EIntrag "blinking thread wont end" im Log.
Beheben lässt sich das Ganze teilweise durch einen VDR-Neustart.
Wobei ich dann tearing-Effekte habe, d.h. Reboot und alles ist wieder ist wieder gut.

Wenn der VDR gegen später "frei ist", kann ich mal ein bisschen testen ....

Peter

Zitat von louis

ch denke daran liegt es. Wenn du magst, kannst du als Workaround mal im metrixhd Skin an dieser Stelle das "animtype="blink" animfreq="500"" wegnehmen, dann sollte der Effekt weg sein. Dann blinkts halt nimmer Der Bug im Skindesigner muss natürlich trotzdem gefixt werden.

Ja, das ist es. Mit der Änderung kann ich wieder zappen.

Gruß

Murry

So, hab mal einen Logauszug gemacht, wenn der VDR mit MetrixHD nach zappen mit blinkendem REC-Icon hängt:

Mär 01 20:42:41 darkstar vdr[509]: [509] switching to channel 33 (Super RTL)
Mär 01 20:42:41 darkstar vdr[509]: [509] [softhddev]SetPlayMode: 0
Mär 01 20:42:41 darkstar vdr[509]: [509] [softhddev]SetVideoDisplayFormat: 1
Mär 01 20:42:41 darkstar vdr[509]: [509] [softhddev]GetSpuDecoder:
Mär 01 20:42:41 darkstar vdr[509]: video: slow down video, duping frame
Mär 01 20:42:41 darkstar vdr[509]: video: decoder buffer empty, duping frame (2559/36) 0 v-buf
Mär 01 20:42:41 darkstar vdr[509]: video: --:--:--.---   +0    0   0/\ms   0-1+4 v-buf
Mär 01 20:42:41 darkstar vdr[509]: audio/alsa: using device 'hw:1,7'
Mär 01 20:42:41 darkstar vdr[509]: audio/alsa: start delay 416ms
Mär 01 20:42:41 darkstar vdr[509]: [1447] device 2 TS buffer thread ended (pid=509, tid=1447)
Mär 01 20:42:41 darkstar vdr[509]: [1446] buffer stats: 110356 (2%) used
Mär 01 20:42:41 darkstar vdr[509]: [1446] device 2 receiver thread ended (pid=509, tid=1446)
Mär 01 20:42:41 darkstar vdr[509]: [1449] device 2 receiver thread started (pid=509, tid=1449, prio=high)
Mär 01 20:42:41 darkstar vdr[509]: [1450] device 2 TS buffer thread started (pid=509, tid=1450, prio=high)
Mär 01 20:42:43 darkstar vdr[509]: [509] ERROR: blinking thread 1448 won't end (waited 2 seconds) - canceling it...
Mär 01 20:42:43 darkstar vdr[509]: [509] [softhddev]SetPlayMode: 1
Mär 01 20:42:43 darkstar vdr[509]: [1451] blinking thread started (pid=509, tid=1451, prio=high)
Mär 01 20:42:43 darkstar vdr[509]: [509] switching to channel 34 (Nickelodeon/Nicknight)
Mär 01 20:42:43 darkstar vdr[509]: [509] [softhddev]SetPlayMode: 0
Mär 01 20:42:43 darkstar vdr[509]: [509] [softhddev]SetVideoDisplayFormat: 1
Mär 01 20:42:43 darkstar vdr[509]: [509] [softhddev]GetSpuDecoder:
Mär 01 20:42:43 darkstar vdr[509]: audio/alsa: using device 'hw:1,7'
Mär 01 20:42:43 darkstar vdr[509]: [1450] device 2 TS buffer thread ended (pid=509, tid=1450)
Mär 01 20:42:43 darkstar vdr[509]: [1449] buffer stats: 76516 (1%) used
Mär 01 20:42:43 darkstar vdr[509]: audio/alsa: start delay 416ms
Mär 01 20:42:43 darkstar vdr[509]: [1449] device 2 receiver thread ended (pid=509, tid=1449)
Mär 01 20:42:43 darkstar vdr[509]: [1452] device 2 receiver thread started (pid=509, tid=1452, prio=high)
Mär 01 20:42:43 darkstar vdr[509]: [1453] device 2 TS buffer thread started (pid=509, tid=1453, prio=high)
Mär 01 20:43:39 darkstar vdr[509]: video: --:--:--.---   +0    0   0/\ms   0-1+4 v-buf
Mär 01 20:44:13 darkstar vdr[509]: [509] PANIC: watchdog timer expired - exiting!
Mär 01 20:44:13 darkstar vdr[509]: X Error of failed request:  BadAccess (attempt to access private resource denied)
Mär 01 20:44:13 darkstar vdr[509]:   Major opcode of failed request:  153 (GLX)
Mär 01 20:44:13 darkstar vdr[509]:   Minor opcode of failed request:  26 (X_GLXMakeContextCurrent)
Mär 01 20:44:13 darkstar vdr[509]:   Serial number of failed request:  79
Mär 01 20:44:13 darkstar vdr[509]:   Current serial number in output stream:  79

OSD wird angezeigt, kein Bild ...

Watchdog kommt übrigens doch ...

louis: Könntest du mal einen Blick auf folgenden Patch werfen. Ich habe versucht softhddevice an ffmpeg 3.0 anzupassen. Auf halben Weg wollte ich dann noch alle Warnings los werden und habe es anscheinend übertrieben.
Es kompiliert und es startet. Auch das OpenGL OSD funktioniert. Bild kommt aber keines.

Vielleicht fällt dir ja irgendein grober Schnitzer auf. Ich hab mir mein Halbwissen nur zusammengegoogelt.

OK. Ich dachte nur, weil du da in letzter Zeit deutlich aktiver bist als johns.

habe heute nochmal mit ARCH4VDR das ganze getestet mit meinen Intel Board und VAAPI geht es nicht, der VDR startet andauernd neu. Ohne den Patch läuft softhddevice einwandfrei. Auf einen anderen System mit nouveau und vdpau hat es funktioniert. Wenn Interesse besteht kann ich auch gerne genauer testen habe es gestern nur kurz ausprobiert.

Gruß

Sebastian

Zitat von Kron

habe heute nochmal mit ARCH4VDR das ganze getestet mit meinen Intel Board und VAAPI geht es nicht...

wird ja auch nicht unterstuetzt. steht gleich im ersten post dieses threads

Mal davon abgesehen, dass das vdr-softhddevice Paket ohne den VAAPI Patch ausgeliefert wird.
VAAPI ist nach wie vor nicht wirklich funktional. Genauso wie nouveau mit VDPAU nicht wirklich funktional ist.
Warum also darauf Rücksicht nehmen?

Beim Start von Aufnahmen mit aktivierten Untertiteln, stürzt bei mir der VDR ab:

Thread 67 "oglThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fcaddb78700 (LWP 32596)]
0x00007fcb3a85da50 in cOglCmdDeleteFb::Execute() () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.2.0
(gdb) bt
#0  0x00007fcb3a85da50 in cOglCmdDeleteFb::Execute() () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.2.0
#1  0x00007fcb3a8644f9 in cOglThread::Action() () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.2.0
#2  0x0000000000510f69 in cThread::StartThread(cThread*) ()
#3  0x00007fcb4c9f7424 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fcb4b38acbd in clone () from /usr/lib/libc.so.6

Wahrscheinlich ähnlich dem OSD-Teletext-Probelm.

Was kann man hier machen?

Ich bekomm es leider mit dem neuesten ffmpeg aus dem debian-multimedia repository nicht kompilliert.
Auch das native-softhddevice kompilliert nicht mehr durch, Fehlermeldung(en) wie folgt:

root@multi-player:/usr/src/vdr-2.2.0/PLUGINS/src/vdr-plugin-softhddevice-openglosd.git# make
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/alsa    -I/usr/include/libdrm   -I/usr/include/libdrm -I/usr/include/freetype2  -DPLUGIN_NAME_I18N='"softhddevice"' -D_GNU_SOURCE  -DAV_INFO -DAV_INFO_TIME=3000        -DUSE_PIP          -DUSE_MPEG_COMPLETE              -DH264_EOS_TRICKSPEED           -DUSE_VDR_SPU                   -DUSE_ALSA -DUSE_OSS -DUSE_VDPAU -DUSE_VAAPI -DUSE_GLX -DUSE_SCREENSAVER -DUSE_SWRESAMPLE -DUSE_OPENGLOSD  -DGIT_REV='"bf608ab"'  -g -W -Wall -Wextra -Winit-self -Werror=overloaded-virtual   -c -o softhddevice.o softhddevice.cpp
In file included from openglosd.h:43:0,
                 from softhddevice.cpp:41:
video.h:63:13: error: use of enum ‘PixelFormat’ without previous declaration
 extern enum PixelFormat Video_get_format(VideoHwDecoder *, AVCodecContext *,
             ^
video.h:64:16: error: use of enum ‘PixelFormat’ without previous declaration
     const enum PixelFormat *);
                ^
In file included from softhddevice.cpp:50:0:
video.h:63:13: error: use of enum ‘PixelFormat’ without previous declaration
 extern enum PixelFormat Video_get_format(VideoHwDecoder *, AVCodecContext *,
             ^
video.h:64:16: error: use of enum ‘PixelFormat’ without previous declaration
     const enum PixelFormat *);
                ^
<builtin>: recipe for target 'softhddevice.o' failed
make: *** [softhddevice.o] Error 1

Im Debian VDR anonscm (Tobias Grimm) existiert dazu bereits ein Patch von Andreas Cadhalpun:
http://anonscm.debian.org/cgit…2ad89ba32ada4274c532b0878

Damit kompilliert das softhddevice(-openglosd) problemlos. Getestet wird's die nächsten Stunden/Tage, je nach dem ob's bereits Wohnzimmertauglich ist.

Wäre super, wenn du & johns den Patch integrieren könnt.
Vielen Dank an euch für die tolle Arbeit!

Beste Grüße,
z421