Posts by FireFly


    Die Pipes "|" sind Zeilenumbrüche in der epg.data, die werden vom VDR seit jeher darin so abgespeichert und das funktioniert auch. Ich denke, das liegt an Eurem epgd bzw. was dahinter steckt. Mit EPG via DVB-S habe ich keine Probleme.

    Bin ich wirklich der einzige, der den Fehler hat?

    Scheinbar ... habe es gerade mal ausprobiert, live und Aufzeichnung:

    Code
    1. S19.2E-1-1019-10301 Das Erste HD
    2. E 147 1586966400 3000 4E 1D
    3. T Wer weiß denn sowas?
    4. S mit Kai Pflaume
    5. D Gäste: Benno Fürmann / Jürgen Vogel|Die beiden Rätselmeister Bernhard Hoëcker und Elton stellen sich erneut den unglaublichen, amüsanten und überraschenden Fragen von Moderator Kai Pflaume. Sie spielen im Team mit jeweils einem prominenten Studiogast, denn es gilt, richtige Antworten auf skurrile und knifflige Fragen aus Wissenschaft, Tierwelt und dem täglichen Leben zu finden.

    Die Gäste werden im OSD (skinElchi) auch so angezeigt.

    Evtl. ein Patch (zu viel)?

    Im Prinzip wird das Plugin noch gepflegt, aber eigentlich arbeite ich seit Jahren am Nachfolger (der endlich TrueColor unterstützt) und finde einfach zu wenig Zeit dafür.

    Mit neueren VDR-Versionen ist durch das Locking einiges nicht mehr möglich (zumindest ohne Verrenkungen). Das Tracelog von Dir zeigt den Check bei der Kanalanzeige, ob ein Timerevent gerade läuft, um dann das REC-Symbol andersfarbig darzustellen. Dafür habe ich in VDR 2.4+ bisher noch keine Möglichkeit gefunden außer die Funktion zu disablen, weshalb ich bisher keine neue Version veröffentlicht habe.

    Ich denke, vermeiden kann man das nicht. Wenn die Info im DVB-Stream z.B. zu selten gesendet und damit zu spät kommt, hat VDR schon die info-Datei geschrieben. Da der VDR in aktuellen Versionen bei ihm bereits bekannten Aufnahmen die info-Datei beim Rescan (touch .update) nicht neu einliest hilft nur ein VDR-Neustart oder Umbenennen der Aufnahme auf der Komandozeile und anschließendes touch .update

    Für Serienaufnahmen ist das im VDR eigentlich so gedacht, dass Du ein Verzeichnis "Zu Tisch" (EPG Title) hast und darin je eine Aufnahme mit "Lyon", "Paris", "Frankfurt" etc. (EPG ShortText). Dazu musste aber der Timer entsprechend gesetzt sein.

    VDRadmin zeigt das nur so an wie es auf de Platte ist.

    Hallo Zabrimus,


    was mich bzw. meinen Code angeht kannst Du das Plugin gerne weiter entwicklen/verwurschten/verunstalten/benutzen ;-) und auch in Dein Repo aufnehmen, aber ich bin auch nicht der erste Ersteller des Plugins. (Filterplugin für hbbtv, ... wie die Zeit vergeht ....)

    Bei Fragen dazu kann ich auch gerne helfen, nur möchte ich keinen Aufwand in die CE-HTML Dekodierung stecken wie o.a. Wenn das CE-HTML aber von einem Browser-Plugin komplett erschlagen würde, wäre das eine Lösung, vorausgesetzt man kann das Bild über dem VDR-Bild darstellen.


    FireFly

    FireFly Ich denke du musst das glewinit mal debugen. Das Missing GL version kommt ja daher und da musst du mal in den Quellen schauen wo das erzeugt wird. Soweit ich das gesehen habe gibt es da eine Funktion die die aktuelle GL Version versucht zu ermitteln und das geht bei dir irgendwie schief. Da musst du mal ein paar debug prints reinbauen um zu sehen wo es hackt.

    Ja, genau das habe ich ja gemacht. Allerdings kann er die GL Version in glewInit() ermitteln, aber anschließend ruft glewInit() die Funktion eglewInit() auf wo es dann fehlschlägt (das GLEW_ERROR_NO_GL_VERSION ist so ne Art Universalfehlmeldung wenn beim Init irgendetwas schief geht):

    Code
    1. /* Load necessary entry points */
    2. initialize = (PFNEGLINITIALIZEPROC) glewGetProcAddress("eglInitialize");
    3. queryString = (PFNEGLQUERYSTRINGPROC) glewGetProcAddress("eglQueryString");
    4. if (!initialize || !queryString)
    5. return 1; // <== das return wird nicht aufgerufen
    6. /* query EGK version */
    7. if (initialize(display, &major, &minor) != EGL_TRUE) //<== das initialize (=eglInitialize) liefert EGL_FALSE zurück
    8. return 1; // <== '1' == GLEW_ERROR_NO_GL_VERSION

    Das eglInitialize steht dann in libEGL, das wiederum Funktionen in libglnvd aufruft, was an die HW-spezifischen Treiber weiterleitet oder so. Das habe ich nicht weiter gedebuggt.

    Hast Du wirklich nur das ligGLEW selbst kompiliert? Mir kommt es so vor, als würde da bei mir noch was fehlen. Immerhin meldet das Beispielprogramm auch den Fehler, ist also reproduzierbar. Wenn man das return aber auskommentiert läuft es ohne sichtbare Probleme weiter :->

    Der OpenGL Benchmark glmark2-es2 bricht ebenfalls ab, glmark2 (ohne ES) funtkioniert. Geht das bei Dir?


    Was gibt bei Euch denn ein glxinfo | grep OpenGL aus? Ist das normal dass dort oben 4.5 als Core Profile steht, aber unten dann nur 3.0 als version string? Bei VAAPI scheint das "normal" zu sein, bei NVidia steht da die gleiche OpenGL version wie bei core Profile: OpenGL version string: 4.6.0 NVIDIA 390.132

    Code
    1. OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2
    2. ....
    3. OpenGL version string: 3.0 Mesa 18.3.2

    Das DRM plugin nutzt ja auch vaapi als dekoder. Ich bin immer noch der Ansicht das die glew installation nicht sauber ist. DRM nutzt im OSD kein glew und VAAPI nutzt glew im OSD. Wenn man glew neu übersetzt und dann mit ldconfig lädt, dann übermangelt Suse es wieder mit der alten Version. Deswegen sollte man es nach usr/local/lib installieren und im ld.so.conf den Pfad /usr/local/lib nach vore legen. Dann nimmt er die neue glew zuerst.

    Da hast Du insofern Recht als dass in meinem selbstgebauten RPM noch ein Fehler drin war (beim install baute er es nochmal ohne EGL). Jetzt passt es aber:

    Code
    1. # ldconfig
    2. # ldd /usr/lib64/vdr/libvdr-softhdvaapi.so.2.4.1|grep -i glew
    3. libGLEW.so.2.1 => /usr/lib64/libGLEW.so.2.1 (0x00007fb7f3b3e000)
    4. # ldd /usr/lib64/libGLEW.so.2.1|grep -i egl
    5. libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fea10548000)

    Erfolg hat das aber nicht gebracht:

    Code
    1. vdr: [1808] oglThread thread started (pid=1724, tid=1808, prio=high)
    2. vdr: [1808] [softhddev]OpenGL using display :0
    3. vdr: [1808] [softhddev]glewInit failed with 'Missing GL version', aborting
    4. vdr: [1808] [softhddev]Could not initiate OpenGL Context
    5. vdr: [1808] [softhddev]OglThread cleanup
    6. vdr: [1808] oglThread thread ended (pid=1724, tid=1808)

    Ich habe schon versucht die GL Version zu setzen im Source Code oder mit MESA Umgebungsvariable, ohne Erfolg. Auch mit und ohne .drirc


    Update: Ein Testprogramm liefert jetzt ebenfalls bei glewInit() keine GL Version - ich versuche das mal zu debuggen

    Update2: in libglew schlägt eglInitialize() fehl, sowohl auf dem Nvidia-PC als auch auf dem Intel-PC. EGL Libs scheinen aber alle installiert zu sein

    Nachdem bei mir immer noch kein OSD mit vaapi angezeigt wird habe ich mal drm ausprobiert und da bekomme ich das OSD angezeigt, aber nach kurzer Zeit ruckelt das Bild, es gibt Artefakte bis zur Unkenntlichkeit des Bildes und buffer overflows im Log. Die GPU ist zwar lt. gpu-top zu 25% mit rendern beschäftigt, aber offenbar wird ja ein Großteil der Arbeit von der CPU verrichtet. Wo wird das das konfiguriert, wo kann man da was nachsehen?

    Kann für das OSD mit vaapi irgendwo Testcode in das Plugin einbauen? Wenn ja wo?

    FireFly : Kannst Du zum Testen einmal folgende Variablen vor dem VDR-Aufruf setzen:

    Code
    1. MESA_VENDOR_OVERRIDE="mesa" MESA_RENDERER_OVERRIDE="mesa" MESA_GL_VERSION_OVERRIDE=4.5COMPAT vblank_mode=0 mesa_glthread=true

    Das macht dann die Dekodierung in Software, oder? Weil es ruckelt und der Ton wird asynchron nach kurzer Zeit. OSD wird aber auch keins angezeigt und beim zweiten Einblenden bleibt das Videobild auch hängen. Die GPU ist aber trotzdem zu 100% mit Render beschäftigt lt. intel_gpu_top bei der max. GPU-Frequenz.

    Ich kann dir mal ne Liste machen mit allen Paketen die ich installiert habe.

    Ja bitte, am besten per PN, auch wenn ich vorr. erst nächstes Wochenende wieder zum Testen komme.


    Hattest du auf dem Rechner evtl. mal den NVIDIA Treiber installiert. Der würde die Mesa installation kaputt machen (nur so ne Idee).

    Nee, außer wenn es durch ne Abhängigkeit installiert worden wäre. Aber in dem Rechner war nie ne NVidia-Karte drin. Außerdem habe ich erst die neueren und dann wieder die alten Mesa-Pakete installiert.

    Das mit dem externen setzten von VAAPI=1 kann ich gerne einbauen. Nur leider bin ich kein Makefilespezialist. :-) Kannst du da helfen ?

    Einfach mit Name ?= Wert, dann wird Name nur definiert wenn es bisher nicht definiert war (wobei ein leerer Name bereits als definiert gilt)

    FireFly Gehts denn nun ?

    Nö, sonst hätte ich das geschrieben. Immer noch das gleiche Verhalten: Nach dem Start des VDR kommt das Videobild ohne OSD und wenn das zweite mal ein OSD aufgemacht werden soll bleibt das Videobild stehen (immer noch ohne OSD) und nur noch der Ton läuft weiter.

    Alle openGL Testprogramme, die im Netz finde und kompiliere, oder glmark2 funktionieren aber.

    Ich verliere langsam die Lust weiter zu suchen .... :(


    Schreibe doch mal die Voraussetzungen ins Readme.

    Außerdem wäre es schön wenn man für die Paketerstellung das VAAPI=1 etc extern setzen könnte und nicht das Makefile patchen muss

    Mit COMPATIBILITY_PROFILE

    Code
    1. glutInitContextVersion( 3, 3 );
    2. glutInitContextProfile( GLUT_COMPATIBILITY_PROFILE );

    stürzt er mir ab:

    Code
    1. vdr[2101]: X Error of failed request: GLXBadFBConfig
    2. vdr[2101]: Major opcode of failed request: 151 (GLX)
    3. vdr[2101]: Minor opcode of failed request: 34 ()
    4. vdr[2101]: Serial number of failed request: 41
    5. vdr[2101]: Current serial number in output stream: 40
    6. vdr[2101]: terminate called without an active exception


    Mit CORE_PROFILE:

    bekomme ich openGL 4.5, was ja langen sollte, auch mit dem "alten" Mesa 18.3.2:

    Code
    1. vdr: [2188] oglThread thread started (pid=2161, tid=2188, prio=high)
    2. vdr: [2188] [softhddev]OpenGL using display :0
    3. vdr: [2188] [softhddev]openglosd 4a OpenGL Version 4.5 (Core Profile) Mesa 18.3.2 GLSL 4.50

    Irgendwie gefällt mir das nicht ....

    Immer noch 3.0 .... Hat aber wohl nicht viel zu bedeuten denn:

    Code
    1. MESA_GL_VERSION_OVERRIDE=3.3 glewinfo|more
    2. ---------------------------
    3. GLEW Extension Info
    4. ---------------------------
    5. GLEW version 2.1.0
    6. Reporting capabilities of display , visual 0x143
    7. Running on a Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2) from Intel Open Source Technology Center
    8. OpenGL version 3.3 (Compatibility Profile) Mesa 19.2.6 is supported


    Mit der Mesa Version hat das nichts zu tun: auf meinem PC mit ner Uralt NVidia Karte meldet glewinfo openGL 4.6.0

    FireFly Das bringt mich auf eine Idee. Bau doch mal in openglosd.cpp folgendes ein:

    Code
    1.     glutInit(&argc, argv);
    2. + glutInitContextVersion( 3, 3 );
    3. + glutInitContextProfile( GLUT_COMPATIBILITY_PROFILE );
    4. glutInitDisplayMode (GLUT_SINGLE | GLUT_RGBA | GLUT_ALPHA);

    Dann findet glewInit hoffentlich eine GL Version

    Damit bekomme ich:

    glewinfo zeigt übrigens:

    GLEW version 2.1.0

    Reporting capabilities of display , visual 0x143

    Running on a Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2) from Intel Open Source Technology Center

    OpenGL version 3.0 Mesa 18.3.2 is supported

    ... und das erste MISSING kommt bei GL_VERSION_4_1


    Wenn ich glutInitContextVersion( 3, 0 ); nehme habe ich kein Videobild mehr (OSD auch nicht). Ich versuche mal das glew in ein RPM-Paket zu bekommen


    Da ist wohl immer noch etwas faul mit dem glew. Nun stürzt der OSD thread ab. Versuch erstmal dein GLEW inOrdnung zu bringen.Das kannst du mit glewinfo testen.

    Was meinst Du mit "in Ordnung bringen"? ich habs mit SYSTEM=linux-egl kompiliert und die originalen Libs vom RPM mit den neuen überschrieben. Was gibt bei Dir

    glewinfo |grep -i egl|grep -c OK

    und

    glewinfo |grep -i egl|grep -c MISSING

    Oder hänge mal bitte den kompletten Output Deines glewinfo an.

    Müssen evtl. noch mehr Libs selbst kompiliert werden?


    Habe mir den Error mal ausgeben lassen:

    Code
    1. vdr: [2892] oglThread thread started (pid=2853, tid=2892, prio=high)
    2. vdr: [2892] [softhddev]OpenGL using display :0
    3. uhdvdr vdr: [2892] [softhddev]glewInit failed with 'Missing GL version', aborting
    4. uhdvdr vdr: [2892] [softhddev]Could not initiate OpenGL Context
    5. uhdvdr vdr: [2892] [softhddev]OglThread cleanup
    6. uhdvdr vdr: [2892] oglThread thread ended (pid=2853, tid=2892)
    7. uhdvdr vdr: [2853] [softhddev]openGL Thread NOT successfully started

    Das sieht aber so aus als wäre glew ok