softhddevice mit High Level OSD

    Moin,


    im aktuellen softhddevice-opengl Git habe ich jetzt mal eingebaut, dass eine gesetzte Displayvariable für das glutInit() auch benutzt wird, ist keine gesetzt, wird "0:0" benutzt.


    Zusätzlich habe ich einige Logausgaben eingebaut. Um dem Problem mit dem attachen / detachen genauer auf die Spur zu kommen, bräuchte ich von den Betroffenen mal ein komplettes Debug Log vom Start bis dorthin, wo es dann nicht mehr funktioniert. Vielleicht sehe ich dann ja, was genau schief läuft...


    Das Log natürlich bitte mit der aktuellen Git Version ;)


    Ciao Louis

    Zitat von louis

    rell: oder so rum ;) Ist schon ne Zeit her, dass ich mich damit intensiv beschäftigt habe. Ich habe zumindest erst mal 4 Wochen gelesen, bis ich mit OpenGL einigermaßen was hinbekommen habe...inkl. einiger Versuche, die komplett in die Hose gingen. Das meiste davon habe ich schon wieder vergessen :D


    Das Gerüst hätte ich, und wie man sieht, sind es gar nicht so viele Dinge, die sich zu ES unterscheiden. Wenn da jemand helfen will, gerne ;)
    Ich mache mich jetzt erstmal an den vdpau Teil...


    Gruß Andreas

    louis
    Ich habe nun mit der letzten vdr-plugin-softhddevice - 0.6.1rc1-9-082606f-0frodo0~trusty von heute getestet.
    Im Verhalten gibt es nun eine Änderung nach dem beenden erscheit das yaVDR Logo mit Mauszeiger d.h. Kodi beendet sich und X-Windows ist wieder da.
    Danach versuchen die yaVDR Skripte das vdr-frontend zu starten und der Bildschirm ist wieder schwarz.


    Anbei die Logdateien.


    /var/log/syslog


    /var/log/upstart/vdr.log


    /var/log/upstart/vdr-frontend.log


    /var/log/upstart/kodi.log


    /var/log/upstart/kodi-exit.log


    /var/log/upstart/toggle.log


    Vielleicht kann einer der yaVDR Skripter über die Logs schauen, für mich ist das python Zeugs nicht lesebar ;(


    Wie gehabt, habe ich erst wieder ein Bild nachdem ich "service vdr restart" ausführe. Das habe ich aber erst getan nachdem ich die Logs kopiert habe.

    Gruß
    Frodo

    Zitat

    Im Verhalten gibt es nun eine Änderung nach dem beenden erscheit das yaVDR Logo mit Mauszeiger d.h. Kodi beendet sich und X-Windows ist wieder da.

    Ja ist bei mir auch so, sonst kam immer ein Bild mit der Meldung "Frontend ist detached. Press any key..."
    EDIT: Bei mir ist es aber definitiv noch so, dass VDR nicht startet, wenn -wie bei yavdr Standard ist- softhddevice mit Parameter -D gestartet wird. Ist VDR einmal gestartet, funktioniert das Attachen/Detachen. Getestet mit den aktuellen frodo-Paketen von vdr-testing.
    Hier noch der Log vom VDR-Start

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    2 Mal editiert, zuletzt von maz ()

    Moin,


    im aktuellen Git ist nun ein Fix, der den Crash beim booten mit detachtem SHD (wie es bei maz war) nun hoffentlich behebt ;) Ich konnte den Fehler zumindest bei mir nachstellen und eliminieren.


    Könnte das ein yaVdr User mal bitte testen? Falls es immer noch knallt, bitte ein Debug Log und einen Backtrace vom Crash...


    Ciao Louis

    Frodo: aus deinem Log werde ich nicht ganz schlau...kann es sein, dass der VDR beim Zurückschalten auf von Kodi auf SHD auf svdrp / dbus2vdr Befehle gar nicht mehr reagiert? Ich sehe da so einige Timeouts...


    Der OpenGL Worker Thread wird laut deinem Log korrekt gestoppt, aber es wird gar nicht mehr versucht, den Thread wieder zu starten. Irgendwo hängt sich da zwischendurch was auf...


    Ciao Louis

    Zitat von louis


    ...falls du konkrete Fragen zum Code hast, als her damit ;)


    Ok, dann fang ich mal an:
    1) GL_CLAMP_TO_BORDER gibts bei ES2.0 nicht. Könnte man das anders lösen, bzw. wie wahrscheinlich ist, dass mit der Fläche außerhalb was angestellt werden muss?
    2) Wie könnte man den blit umschreiben, damit das ohne glBlitFamebuffer klappt? glBlitFramebuffer, GL_DRAW_FRAMEBUFFER und GL_READ_FRAMEBUFFER gibts bei ES2.0 auch nicht.
    3) Über die glut/window Sachen muss ich nochmal mehr nachdenken. Ich habe noch nicht verstanden, warum man das braucht... Als dummy, damit OpenGL funktioniert? Soweit ich sehe, wird ein 1*1 Fenster erstellt und versteckt. Um die Darstellung kümmert sich ja VDPAU...


    Der Rest sollte einigermaßen an OpenGL/ES angepasst sein. Mal sehen, wenn das backend fertig ist, aber vielleicht kann mir ja in der Zwischenzeit jemand mit den offenen Punkten helfen...
    Achja, der Code liegt hier.


    Gruß Andreas

    Hi,

    Zitat von rell

    1) GL_CLAMP_TO_BORDER gibts bei ES2.0 nicht. Könnte man das anders lösen, bzw. wie wahrscheinlich ist, dass mit der Fläche außerhalb was angestellt werden muss?


    Naja, das setzt ja nur die Option, wie die Textur skaliert wird, falls sie nicht in den Ausgabebereich passt. Das sollte in ES auch irgendwie konfigurierbar sein. Genaues wirst du dann sicherlich sehen, wenn du so weit bist, das zumindest irgendwas ausgegeben wird ;)

    Zitat von rell

    2) Wie könnte man den blit umschreiben, damit das ohne glBlitFamebuffer klappt? glBlitFramebuffer, GL_DRAW_FRAMEBUFFER und GL_READ_FRAMEBUFFER gibts bei ES2.0 auch nicht.


    Hm, dann musst du das blitting wohl mit "normalen" Renderfunktionen nachbilden. Ich gehe ja wie folgt vor:

    • Erstellung eines Framebuffers als Zwischenspeicher ("Output Framebuffer")
    • Jede (cOgl)Pixmap beinhaltet einen eigenen Framebuffer, auf dem der Inhalt der Pixmap gezeichnet wird
    • Beim Flush werden dann alle Pixmaps (bzw. deren Framebuffer) inkl. alpha blending unter Berücksichtigung des Layers auf den Output Framebuffer gerendert
    • Dieser Output Framebuffer wird dann per blitting auf das VDPAU Output Surface gerendert


    Den letzten Schritt musst du dann eben auch "manuell" machen. Mit blit ist das halt ein bisschen einfacher...

    Zitat von rell

    3) Über die glut/window Sachen muss ich nochmal mehr nachdenken. Ich habe noch nicht verstanden, warum man das braucht... Als dummy, damit OpenGL funktioniert? Soweit ich sehe, wird ein 1*1 Fenster erstellt und versteckt. Um die Darstellung kümmert sich ja VDPAU...


    Ja genau. Über Glut wird das "Dummy" Ausgabefenster erzeugt. Das braucht man leider immer, auch wenn man nur Off Screen Rendering machen will (so wie wir das ja wollen). So stand das zumindest in den wenigen Quellen, die ich zu dem Thema im Web gefunden habe. Dieses hierfand ich recht hilfreich. Ist aber für OpenGL, für ES passt das wohl nicht so ganz.


    Ciao Louis

    Zitat von louis

    Hi,
    Naja, das setzt ja nur die Option, wie die Textur skaliert wird, falls sie nicht in den Ausgabebereich passt. Das sollte in ES auch irgendwie konfigurierbar sein. Genaues wirst du dann sicherlich sehen, wenn du so weit bist, das zumindest irgendwas ausgegeben wird ;)

    Wie wahrscheinlich ist es, dass das nicht passt? Alternativen gibt es, aber keine die wie _BORDER einen schwarzen Rand erzeugt.

    Zitat


    Hm, dann musst du das blitting wohl mit "normalen" Renderfunktionen nachbilden. Ich gehe ja wie folgt vor:

    • Erstellung eines Framebuffers als Zwischenspeicher ("Output Framebuffer")
    • Jede (cOgl)Pixmap beinhaltet einen eigenen Framebuffer, auf dem der Inhalt der Pixmap gezeichnet wird
    • Beim Flush werden dann alle Pixmaps (bzw. deren Framebuffer) inkl. alpha blending unter Berücksichtigung des Layers auf den Output Framebuffer gerendert
    • Dieser Output Framebuffer wird dann per blitting auf das VDPAU Output Surface gerendert


    Den letzten Schritt musst du dann eben auch "manuell" machen. Mit blit ist das halt ein bisschen einfacher...


    Ok, heißt für mich, ich sollte mir cOglCmdRenderFbToBufferFb::Execute ansehen und den Weg über Shader gehen?

    Zitat


    Ja genau. Über Glut wird das "Dummy" Ausgabefenster erzeugt. Das braucht man leider immer, auch wenn man nur Off Screen Rendering machen will (so wie wir das ja wollen). So stand das zumindest in den wenigen Quellen, die ich zu dem Thema im Web gefunden habe. Dieses hierfand ich recht hilfreich. Ist aber für OpenGL, für ES passt das wohl nicht so ganz.


    Jetzt auch verstanden. Das werd ich dann auch gelöst bekommen...


    Theoretisch müsste der Code auch jetzt schon mit NVidia laufen, wenn man die #ifdefs bei den offenen Punkte rausnimmt und die GL Variante benutzt... Leider kann ichs grad nicht ausprobieren.


    Gruß Andreas

    Moin,

    Zitat von rell

    Wie wahrscheinlich ist es, dass das nicht passt? Alternativen gibt es, aber keine die wie _BORDER einen schwarzen Rand erzeugt.


    Keine Ahnung, das liegt wohl an dir ;)

    Zitat von rell

    Ok, heißt für mich, ich sollte mir cOglCmdRenderFbToBufferFb::Execute ansehen und den Weg über Shader gehen?


    Genau. Falls das mit den Vertex Buffern bei ES genauso funktioniert...


    Magst du bei weiteren Fragen bitte einen separaten Thread aufmachen? Hier gibts ja auch noch das ein oder andere Problemchen, ansonsten wird das ganze etwas unübersichtlich. Danke ;)


    Ciao Louis

    Zitat von louis


    Magst du bei weiteren Fragen bitte einen separaten Thread aufmachen? Hier gibts ja auch noch das ein oder andere Problemchen, ansonsten wird das ganze etwas unübersichtlich. Danke ;)


    Mach ich. Danke für deine Hilfe bisher, ich glaub, ich habs eh fast. Bei Fragen mach ich woanders weiter.
    Gruß Andreas

    Zitat von louis

    Frodo: aus deinem Log werde ich nicht ganz schlau...kann es sein, dass der VDR beim Zurückschalten auf von Kodi auf SHD auf svdrp / dbus2vdr Befehle gar nicht mehr reagiert? Ich sehe da so einige Timeouts...


    Der OpenGL Worker Thread wird laut deinem Log korrekt gestoppt, aber es wird gar nicht mehr versucht, den Thread wieder zu starten. Irgendwo hängt sich da zwischendurch was auf...


    Ciao Louis


    Ja genau so ist es. Der VDR läuft zwar noch zumindest ist der noch in der Prozessliste, aber zugreifen kann ich nicht mehr auf ihn. svdrsend endet in timeouts . Den Cache der Logos habe ich im Skindesigner Plugin deaktiviert.

    Gruß
    Frodo

    Hallo,


    hab das letzte softhd-opengl git von ca. 19:00 genommen und skindesigner 0.8.3 aus dem yavdr ppa (ja, nicht schlagen - unstable) nun am Laufen. Einige Skins habe ich via OSD installiert - jetzt ist zZ simplex aktiv. Läuft super - kaum zu glauben, wie die alte Kiste "zackig" geworden ist :tup :mua


    Schönen Dank! Echt cool :]


    PS: bzgl. Kodi und "exit" - habe ähnliche Symptome. vdr prozess ist aktiv, schreibt logs (nicht weiterführende hier) - aber unbedienbar. "service vdr stop" führt zu nichts, nur ein kill des vdr-binary und dann Neustart hilft.


    Gruß!

    Zitat

    Könnte das ein yaVdr User mal bitte testen? Falls es immer noch knallt, bitte ein Debug Log und einen Backtrace vom Crash...


    Hm, die gute Nachricht: VDR startet jetzt auch mit softhddevice Parameter -D :tup
    Die schlechte Nachricht: Mit dieser Version hab ich keinen Ton. Etwas komisch, aber ich hab 2x den Rechner neugestartet => kein Ton. Danach die softhddevice lib wieder gegen die vorherige lib (von Frodo testing-vdr) getauscht => Ton wieder da.

    Meine VDRs:
    >>>Mac mini 2010 mit 2x Sundtek SkyTV Ultimate III, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>ZOTAC D2550 ITX-WIFI Supreme mit DD Cine S2, Gehäuse OrigenAE M10, Logitech Harmony 300i, yavdr-0.5a mit softhddevice<<< >>>Raspberry Pi         2 mit Sundtek SkyTV Ultimate IV, raspbian, rpihddevice-Plugin, Logitech Harmony 200<<<

    .. so sieht das syslog (wahrschnlich nicht dbg? ) bei kodi exit aus:


    :monster1

    Zitat von maz

    Die schlechte Nachricht: Mit dieser Version hab ich keinen Ton. Etwas komisch, aber ich hab 2x den Rechner neugestartet => kein Ton. Danach die softhddevice lib wieder gegen die vorherige lib (von Frodo testing-vdr) getauscht => Ton wieder da.


    Seltsam...keine Ahnung warum das bei dir den Ton kaputt macht. Hast du da irgendwie eine besondere Konstellation?


    Ciao Louis


    Edit: was mir eben noch eingefallen ist: beim attachen vom SHD kann man ja per -a auch das zu verwendente Audiodevice mitgeben...wird das bei dir gemacht? Falls nicht könnte das ggf. was bringen.

    Bzgl. Hin- und Zurückschalten auf Kodi: bei mir unter Gen2Vdr funktioniert das. Ich schalte aber mit einem speziellen Knopf auf der Fernbeidienung um, über die im Hintergrund ein Script aufgerufen wird, das SHD detached und Kodi startet. Bei yavdr wird ja anscheinend aus dem VDR Menü heraus umgeschalten.


    Kann es deshalb sein, dass das OSD beim detachen vom SHD noch offen ist und deswegen der OpenGL Kontext nicht korrekt deinitialisiert werden kann? Wäre es möglich, das OSD vor dem detachen z.B. per "svdrpsend hitk menu" zu schließen?


    Falls das nichts bringt, müsste man mal genauer analysieren, was beim Starten und Beenden von Kodi genau an Scripten gefahren wird...da müsste dann mal ein yaVdr Profi ran :D


    Ciao Louis

    Moin,


    zum Thema Umschalten zu Kodi und zurück: seahawk hat hier einen Workaround gepostet. Dank seiner Mithilfe konnten wir eindeutig identifizieren, dass das Problem nur auftritt, wenn das OSD beim detachen vom SHD noch geöffnet ist.


    Warum das allerdings passiert, das muss ich noch genauer untersuchen ;)


    Ciao Louis

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden