softhddevice mit High Level OSD

Das wird immer seltsamer...

Jetzt kommt:

.....
Mar 26 13:44:58 [vdr] [4673] [softhddev]SetPlayMode: 1_
Mar 26 13:44:58 [vdr] [4673] [softhddev]stopping Ogl Thread svdrp DETA
Mar 26 13:44:58 [vdr] [4673] [softhddev]stopping OpenGL Worker Thread
Mar 26 13:44:58 [vdr] [5451] [softhddev]Cleaning up OpenGL stuff
Mar 26 13:44:58 [kernel] oglThread[5451]: segfault at 0 ip           (null) sp 00007f39657f9df8 error 14 in vdr[400000+1d6000]
Mar 26 13:44:58 [lircd-0.9.0] removed client
Mar 26 13:44:58 [root] Focus: 1
Mar 26 13:44:58 [G2V gg_switchhook.sh] /_config/bin/gg_switchhook.sh -switch ActWin <(1058, 1888) 0(Gg_launcher)>
Mar 26 13:44:59 [root] VDR wurde beendet - RC: 0

Habe aber nichts verändert.

Backtrace

Zitat von louis

3PO: wie genau startest du den VDR bzw. SHD?

Eigentlich nicht außergewöhnlich.

SHD starte ich mit folgenden Parametern:

vdr01_64 ~ # cat /etc/vdr.d/plugins/softhddevice
# Parameters for VDR plugin softhddevice


#INIT_ACTION=""
#EXIT_ACTION=""
#RESTART_ACTION=""
#RECORD_ACTION=""


PLUGIN_NAME=softhddevice


PLUGIN_PARAMETERS="-s -a pcm.stereo -p hw:2,8 -w use-possible-defect-frames"
# PLUGIN_PARAMETERS="-s -a pcm.!default -p hw:1,7 -w use-possible-defect-frames"
# PLUGIN_PARAMETERS="-s -a 51to20 -p front -c softvol -w alsa-driver-broken"


VDR_PARAMETERS=""

Zitat von louis

[...] Warum detachst du SHD per SVDRP nachdem es gestartet ist? ...

Tue ich doch garnicht, zumindest mal nicht bewusst.

Funktioniert leider auch nicht, dann kommt wieder der segfault mit freetype.

Zitat von louis

im Git ist nun eine Version, die das Problem mit dem Ändern der Fenstergröße fixt. Wurde die Fenstergröße geändert, hat das OSD ja nicht mehr funktioniert. Getestet habe ich das ganze mit openbox und wmctrl. Damit sollte das yaVDR PIP auch funktionieren.

Yessesyes - geht während und auch nach dem Pip, so soll es sein.

Heute ist wieder Weihnachten und Ostern zusammen, vielen Dank

Christian

Es funktioniert leider immer noch nicht.

Wenn ich softhddevice so starte,

PLUGIN_PARAMETERS="-a pcm.stereo -p hw:2,8 -w use-possible-defect-frames"

dann startet der VDR nicht mehr.

...
Mar 27 13:52:20 [vdr] [6226] CAM 1: unassigned
Mar 27 13:52:20 [vdr] [6226] [softhddev]SetPlayMode: 1_
Mar 27 13:52:20 [vdr] [6226] [softhddev]stopping Ogl Thread svdrp DETA
Mar 27 13:52:20 [vdr] [6226] [softhddev]stopping OpenGL Worker Thread 
Mar 27 13:52:20 [vdr] [7206] [softhddev]Cleaning up OpenGL stuff
Mar 27 13:52:20 [kernel] oglThread[7206]: segfault at 0 ip           (null) sp 00007f91017f9e78 error 14 in vdr[400000+1d6000]
Mar 27 13:52:20 [lircd-0.9.0] removed client
Mar 27 13:52:20 [root] Focus: 1
Mar 27 13:52:20 [G2V gg_switchhook.sh] /_config/bin/gg_switchhook.sh -switch ActWin <(1058, 1888) 0(Gg_launcher)>
Mar 27 13:52:21 [vdradmind] Connection to vdr01_64:6419 failed: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt_
Mar 27 13:52:21 [root] VDR wurde beendet - RC: 0

Backtrace

Mit der aktuellen Version hatte ich gerade einen Crash beim Umschalten, anbei der backtrace.

Auch ein crash beim umschalten, aber backtrace ist nicht in Ordnung, da stirbt etwas wofür ich keinen debug symbol habe oder so etwas (hat jemand einen Rat dafür?).
(hab vorhin vdr-softhddevice und vdr-skindesigner aktuallisiert)

softhddevice (0.6.1rc1-GIT4fa4f66) + commits 48fbfa9f...fd3db0bc.diff

https://github.com/louisbraun/softhddevice-openglosd/compare/48fbfa9f...fd3db0bc.diff

skindesigner (0.9.5): Skin Designer

backtrace:

https://pastee.org/9cdx5

Ich weiß, was ich jedoch nicht weiß ist wie soll ich damit eine richtige backtrace erstellen. Bis jetzt war es immer ok, entweder ist das etwas tieferes, was den ganzen libc zerstört und dafür habe ich keine debug symbols oder es ist etwas ganz anderes. Bin für jede Hilfe aber dankbar, um ein richtige backtrace zu erstellen, und damit das softhddevice-opengl Plugin zu fixen, falls es der Übeltäter ist.

Richtig reproduzieren kann ich den Crash nicht, passiert beim Sender umschalten. Bis jetzt ist es drei mal aufgetreten, und jedes mal war backtrace derselbe.

Hallo zusammen,

mit Erlaubnis von Louis darf ich den Thread in gewisser Weise "hijacken"
Ich habe hier die Commits von Louis auf den Branch von johns ge-cherry-picked und einen Commit draufgesetzt, der glGetError() nach jedem GL Befehl einführt.
Da ich das ganze als Vorbereitung für die gles Funktionalität gemacht habe und hier keinen i386 mit softhddevice zum Testen habe, wollte ich fragen, ob diesen Branch mal jemand ausprobieren und schauen könnte, dass damit kein Bug einwandert ...
Es würde mir dann auch helfen, wenn jemand den gles branch auf dem i386 probiert, um sicherzustellen, dass ich auch hier nichts kaputt gemacht habe

Mein eigentliches Ziel, ein softhddevice mit OpenGL/ES Unterstützung, ist grundsätzlich erreicht, obwohl noch ein paar Sachen zu fixen sind. Wenn da Interesse besteht, mache ich einen neuen [WIP]Thread dazu auf und beschreibe, wie man das zum Laufen kriegt. Evtl. finden sich ein paar Tester...

Danke und Gruß
Andreas

Hallo Andreas

Zitat von rell

Mein eigentliches Ziel, ein softhddevice mit OpenGL/ES Unterstützung, ist grundsätzlich erreicht, obwohl noch ein paar Sachen zu fixen sind. Wenn da Interesse besteht, mache ich einen neuen [WIP]Thread dazu auf und beschreibe, wie man das zum Laufen kriegt. Evtl. finden sich ein paar Tester...

Klingt, als ob es schon bald eine plattformübergreifende Implementation eines beschleunigten High-Level-OSDs gibt.

Damit stellt sich für mich nun ernsthaft die Frage, ob es nicht sinnvoll wäre, die Arbeit ein eigenständiges Plugin zu stecken. Die Verknüpfung von Ausgabedevice und OSD ist in meinen Augen nicht mehr zwingend, da es inzwischen sowohl für die Videoausgabe wie auch für das OSD auf allen Plattformen mehrere unabhängige Wege gibt. Ein OpenGL/ES-OSD-Plugin würde dann swohl auf einem Raspberry Pi, einer Wetek-Play oder einem Desktop (?) laufen und könnte zentral gepflegt werden. Das nur mal so als Idee.

Gruss
Thomas

Zitat von reufer

Klingt, als ob es schon bald eine plattformübergreifende Implementation eines beschleunigten High-Level-OSDs gibt.

Damit stellt sich für mich nun ernsthaft die Frage, ob es nicht sinnvoll wäre, die Arbeit ein eigenständiges Plugin zu stecken. Die Verknüpfung von Ausgabedevice und OSD ist in meinen Augen nicht mehr zwingend, da es inzwischen sowohl für die Videoausgabe wie auch für das OSD auf allen Plattformen mehrere unabhängige Wege gibt. Ein OpenGL/ES-OSD-Plugin würde dann swohl auf einem Raspberry Pi, einer Wetek-Play oder einem Desktop (?) laufen und könnte zentral gepflegt werden. Das nur mal so als Idee.

Ich habe das noch nicht weiter gedacht... Ich habe nur dem libvdpau backend für die Allwinner Devices ein gles interop feature spendiert, das ja für nvidia auf gl-Basis existiert und von louis' HighLevel OSD- softhddevice genutzt wird. Dann musste nur das softhddevice von gl auf gles angepasst werden... Ein zentrales OSD-Plugin wäre möglicherweise sinnvoll, obwohl ich über Vor- und Nachteile noch nicht nachgedacht habe. Aber "denkenswert" ist das bestimmt

Gruß
Andreas

Ihr könnt ja schon mal die Vorarbeiten machen und den Ausgabeplugins über einen Parameter beibringen, keinen OsdProvider zu erstellen, wenn sie aktiviert werden.
Am besten alle mit dem gleichen, z.B. --no-osd oder so.

Dann wäre das Bauen eines OSD-Plugins nur noch eine Fingerübung...

Lars.

Zitat von mini73

Ihr könnt ja schon mal die Vorarbeiten machen und den Ausgabeplugins über einen Parameter beibringen, keinen OsdProvider zu erstellen, wenn sie aktiviert werden.

Meinst du sowas:

rpihddevice (1.0.2) - HD output device for Raspberry Pi


  -d,       --disable-osd  disable OSD
  -v,       --video-layer  dispmanx layer for video (default 0)
  -o,       --osd-layer    dispmanx layer for OSD (default 2)
            --display      display used for output:
                           0: default display (default)
                           4: LCD
                           5: TV/HDMI
                           6: non-default display

Gruss
Thomas

Zitat von louis

ich hätte auch kein Problem damit, die "Verantwortung" für den OpenGL Teil abzutreten Wenn sich jemand dazu bereit erklärt, das ganze in ein eigenes Plugin auszulagern...nur zu!

In Sachen OpenGL kenne ich mich zu wenig aus und aktuell bin ich mit dem Umbau von rpihddevice gut ausgelastet. Aber ich übernehme gerne die Raspi-spezifischen Anpassungen und helfe natürlich mit beim Testen!

Gruss
Thomas