softhddevice mit High Level OSD

  • Moin,


    ich habe jetzt mal den von seahawk vorgeschlagenen Patch ins Git übernommen. Bei zeiten kann man das dann ja immernoch auf "softhddevice" ändern ;)


    Ciao Louis

  • Ausserdem habe ich das default display, falls gar nix gesetzt ist, auf ":0.0" geändert. Damit sollte es auch funktionieren, wenn SHD ganz ohne display variable gestartet wird.


    Danke damit funktioniert es ohne eine Display variable zu setzten.


  • Leider bekomme ich hier schon zwei mal coredumps, die werden aber irgendwie nicht richtig erstellt.
    Es war so VDR gestartet Audio/Video da, dann nach 5min ausgeschaltet. Paar plugin eingebunden, VDR gestartet, es war nur Audio da und kein BIld. Und nach Befehl um VDR suber zu stoppen ist ein coredump erstellt. Mehr Im Log , das passwort ist 'vdr'.


    VDR 2.2.0 und vdr-softhddevice-openglosd (commit 3ed09d43bf8ef5a3fc5eaeade57d86a87750987c)

    Code
    Mar 13 16:13:21 vdr01 vdr[16404]: [16404] deleting plugin: softhddevice
    Mar 13 16:13:21 vdr01 vdr[16404]: vdr: xcb_conn.c:195: write_vec: Assertion `!c->out.queue_len' failed.
    Mar 13 16:13:22 vdr01 systemd[1]: vdr.service: Main process exited, code=killed, status=6/ABRT
    Mar 13 16:13:22 vdr01 systemd[1]: Stopped Video Disk Recorder.
    Mar 13 16:13:22 vdr01 systemd[1]: vdr.service: Unit entered failed state.
    Mar 13 16:13:22 vdr01 systemd[1]: vdr.service: Failed with result 'signal'.
  • Gerade beim VDR stopp einen "video: fatal i/o error" bekommen. Wurde aber kein segfault generiert, vermutlich weil watchdog aktiviert wurde.


  • Moin,


    crow: bist du sicher, dass das Problem nur mit dem OpenGL Fork vorhanden ist? "Mein" Thread ist an dieser Stelle schon beendet. Was du mal machen kannst...der VDR hängt ja offensichtlich beim Beenden. Während des Hängens könntest du mal einen

    Code
    killall -SIGSEGV vdr


    loslassen, dann sollte ein Coredump erzeugt werden und man sieht, wo es genau hängt.


    Ciao Louis

  • Nicht solange ich im Frontend-Skript eine Sonderbehandlung für das Plugin benötige - aber ich kann das auch weiterhin als Patch in unserem Paket pflegen.


    Ein DLIC beim alten OSD schadet doch sicherlich auch nicht, oder?
    Aber das ist ja auch nicht so wichtig.


    Lars

  • Sicher bin ich nicht, aber über systemd stop/start hat es davor funktioniert, muss aber nicht bedeuten das es an opengl Implementierung liegt.
    Was ich gestern noch nicht geschrieben hab, ist das nach „video: fatal i/o error“, und erneutem VDR Start, ich nur Audio bekommen habe, Video ist nicht vorhanden gewesen (nur schwarz). Im Log ist mir nichts merkwürdiges aufgefallen. Kann es sein dass das so etwas in die Richtung was seahawk geschrieben hat ist, das irgendwo ein Video Fenster geöffnet ist?


    Code
    URL: https://pastee.org/utq4m
    Pass: vdr
  • Ändern der Fenstergröße ist auch noch nicht vorgesehen, da müsste ich das OSD neu initialisieren. Müsste ich mal schauen, ob und wie ich die Änderung der Fenstergröße im SHD mitbekomme...


    Ciao Louis


    ich hab hier auch das Problem wenn ich ein pip mit einem zweiten VDR auf den Schirm lege dann geht das OSD reproduzierbar weder im großen PIP noch nach Beendigung wenn der zweite VDR wieder gestoppt ist.


    Nicht so schön, ansonsten angenehme Speed... ! ;)


    Christian


    [Edit] ach mist ich kann ja keinen Screenshot über mehrere vdr Instanzen machen, hab das Foto wieder entfernt [/Edit]

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • ich hab hier auch das Problem wenn ich ein pip mit einem zweiten VDR auf den Schirm lege dann geht das OSD reproduzierbar weder im großen PIP noch nach Beendigung wenn der zweite VDR wieder gestoppt ist.


    Hm, ist das die yaVDR "Speziallösung"? Hast du mal die SHD interne PIP Funktion getestet? Für ersteres tue ich mir mit einem Fix schwer...zweiteres müsste sich in den Griff bekommen lassen.


    Ciao Louis

  • das ist keine Option, das softhd kann weder auf verschiedenen Displays pip machen noch einen splitscreen, ob es das pip fenster zappen kann mag ich nicht sagen. Weiteres Problem ist das die zweite vdr Instanz ja hier keinen eigenen Tuner hat und über satip an den server angedockt ist.


    Was in dem Script passiert ist relativ einfach:


    bevor es losgeht merk ich mir von softhd die fensterid

    Code
    VDRWIN=$(wmctrl -l|egrep "VDR|softhddevice|xine"|cut -d ' ' -f 1)
    echo "VDRWIN=$VDRWIN" > /etc/default/vdr-pip


    dann verkleinere ich das vdr Fenster mit wmctrl und starte einen weiteren vdr.
    Diese beiden softhd Fenster kann ich nun daran unterscheiden das ich von einem die ID kenne, bzw kann ich mir die vom PIP auch einfach raussuchen:

    Code
    PIPWIN=$(wmctrl -l | grep "softhddevice" | grep -v "$VDRWIN" | cut -d ' ' -f 1)


    am Ende einfach rückwärts, den zweiten vdr stoppen und den Hauptvdr mit wmctrl wieder groß


    Also nix besonderes, hat auch immer funktioniert mit softhddev, xine, xinelibout

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Hm, ist das die yaVDR "Speziallösung"?

    Ja, wobei ich glaube, dass CKone da noch ein eigenes Skript hat - aber das generelle Problem dürfte sein, dass da die Größe und Position der softhddevice-Fenster mit wmctrl geändert wird. Soweit ich das im Kopf habe, hattest du geschrieben, dass das Skalieren des Fensters noch nicht unterstützt wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, wobei ich glaube, dass CKone da noch ein eigenes Skript hat


    nö, das sp aus dem git, hab lediglich für den pip vdr streamdev durch satip ersetzt...


    aber das generelle Problem dürfte sein, dass da die Größe und Position der softhddevice-Fenster mit wmctrl geändert wird. Soweit ich das im Kopf habe, hattest du geschrieben, dass das Skalieren des Fensters noch nicht unterstützt wird.


    das denke ich auch, ist relativ trivial nachzustellen und hat egtl nichts mit dem pip selber zu tun.


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()

  • Moin,

    Soweit ich das im Kopf habe, hattest du geschrieben, dass das Skalieren des Fensters noch nicht unterstützt wird.


    jo das ist korrekt. Sobald das "Hauptbild" verkleinert wird, ist aktuell das OSD kaputt, da das Surface, auf dem das OSD gezeichnet wird, eine fixe Größe hat und ich aktuell eine Änderung der Fenstergröße nicht mit bekomme, wodurch ich entsprechend darauf reagieren könnte.


    Ich muss bei Zeit mal schauen, wo ich eingreifen muss, damit ich eine Änderung der Fenstergröße im OSD mitbekomme...wobei es dann wieder mit offenem OSD knifflig wird, das geht dann wohl kaputt.


    Ciao Louis

  • wobei es dann wieder mit offenem OSD knifflig wird, das geht dann wohl kaputt.


    das ist aber glaube ich kein Problem solang du es vor und hinterher aufmachen kannst

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • das ist aber glaube ich kein Problem solang du es vor und hinterher aufmachen kannst


    Wer ist "du"? ;) Klar, der User muss das OSD dann einmal zu und wieder auf machen, dann sollte es wieder passen.


    Ciao Louis

  • Moin,


    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.


    Wie vermutet war es ein bisschen tricky, damit das ganze auch bei geöffnetem OSD funktioniert. Wird bei geöffnetem OSD das Fenster mit wmctrl resized, verschwindet das OSD und man muss einmal das Menü schließen, damit es wieder neu geöffnet werden kann. Verändert man das Fenster bei geöffnetem OSD durch ziehen mit der Maus, dann kackt das ganze ab und zu ab, weil sehr viele Events sehr schnell hintereinander abgefeuert werden. Das finde ich jetzt aber nicht tragisch, wer mit der Maus das Fenster verändert kann auch vorher das OSD zumachen ;)


    Bitte mal testen...Ciao Louis

  • Ich bin nach längerer Zeit mal wieder zum Testen gekommen.


    Leider aber schmiert der VDR bei mir ab, sobald das OSD aufgerufen wird:


    Code
    .....
    Mar 26 12:23:40 [vdr] [21751] [softhddev]SetPlayMode: 1_
    Mar 26 12:23:40 [vdr] [21751] [softhddev]stopping Ogl Thread svdrp DETA
    Mar 26 12:23:40 [vdr] [21751] [softhddev]stopping OpenGL Worker Thread 
    Mar 26 12:23:40 [vdr] [22667] [softhddev]Cleaning up OpenGL stuff
    Mar 26 12:23:40 [kernel] oglThread[22667]: segfault at 7f98ba011100 ip 00007f9a04f863ab sp 00007f98fb7fde80 error 4 in libfreetype.so.6.12.3[7f9a04f72000+ab000]
    Mar 26 12:23:40 [lircd-0.9.0] removed client
    Mar 26 12:23:40 [root] Focus: 1
    Mar 26 12:23:40 [G2V gg_switchhook.sh] /_config/bin/gg_switchhook.sh -switch ActWin <(1058, 1888) 0(Gg_launcher)>
    Mar 26 12:23:41 [root] VDR wurde beendet - RC: 0


    Backtrace

  • Bei mir funktioniert es mit dem aktuellen Git-Stand unter yaVDR unstable mit Skalieren und de/attachen. Etwas schade ist die Verzögerung nach dem Ändern der Fenstergröße, bis das OSD wieder genutzt werden kann - ich vermute da wird das Material neu in den RAM der GPU geladen (der Testrechner hier hat nur eine HDD und einen alten Athlon64 3000+)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 3PO: wie genau startest du den VDR bzw. SHD? Warum detachst du SHD per SVDRP nachdem es gestartet ist? Ist das "Standard G2VDR" oder hast du da selbst irgendwie drann rumgefummelt?


    Bei dir crasht das aufräumen der FreeType Libary, weil SHD per svdrp detacht wird...keine Ahnung warum.


    Ciao Louis

  • Moin,

    Bei mir funktioniert es mit dem aktuellen Git-Stand unter yaVDR unstable mit Skalieren und de/attachen.


    Na das ist doch schonmal prima :)


    Etwas schade ist die Verzögerung nach dem Ändern der Fenstergröße, bis das OSD wieder genutzt werden kann - ich vermute da wird das Material neu in den RAM der GPU geladen (der Testrechner hier hat nur eine HDD und einen alten Athlon64 3000+)


    Mit nix zufrieden die Leut ;) Die gecachten Bilder müssen gelöscht und wieder neu gecacht werden. Du kannst im Skindesigner Setup konfigurieren, ob die Bilder beim Start gecacht werden sollen. Wenn du das deaktivierst, sollte das ganze beim Start etwas schneller sein.


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!