[Beta] RPI Ausgabeplugin

  • Vielleicht liegt es an den installierten abhängigen Paketen ?
    Ich verwende Arch-Linux.


    Hier die Komponenten:

    ASRock ION 330HT mit TT-connect S2-3600
    Arch Linux VDR 2.2.0
    VDR user #2043

  • Vielleicht liegt es an den installierten abhängigen Paketen ?

    Kann ich mir nicht vorstellen, das Kreieren von Pixmaps nutzt keine externen Libraries, ausser jenen von Broadcom. Hast du mal versucht, das Plugin mit "make DEBUG=1" zu übersetzen und die Logs verglichen? Irgendwie muss das Timing beim zweiten Start anders sein, so dass der OpenVG-Thread scheinbar verzögert anläuft, und beim Zeichnen auf das OSD noch nicht bereit ist.


    Gruss
    Thomas

  • @tintin-tux: Kannst du bitte mal folgenden Patch testen:



    Nur so als Versuch, ob es wirklich nur ein Timing-Problem ist.


    Gruss
    Thomas

  • Hi,


    auf meinem RPI2 mit Gentoo lässt sich das Plugin leider nicht starten. :(


    Code
    May 13 18:00:24 [vdr] [8756] ERROR: /usr/lib/vdr/plugins/libvdr-rpihddevice.so.2.2.0: undefined symbol: vgClear
  • auf meinem RPI2 mit Gentoo lässt sich das Plugin leider nicht starten. :(

    Nutze auf meinen Himbeeren auch Gentoo, und soweit ohne Probleme. Beim letzten Update von media-libs/raspberrypi-userland musste ich zwar ein paar Symlinks von Hand erstellen, da manche libs plötzlich nicht mehr unter /opt/vc waren, aber das ging dann schon beim Linken schief.


    Hast du das Plugin von Hand übersetzt oder via portage installiert?


    Gruss
    Thomas

  • userland habe ich via Portage installiert, den VDR und das Plugin habe ich "von Hand" compiliert, bzw. mit meinem Buildscript. ;)


    Verlinkt habe ich das so:


  • Sehe gerade, dass es beim Bauen schon Probleme gibt: :(


  • Habe es mal so versucht:



    Damit lässt es sich zwar fehlerfrei bauen,



    allerdings startet dann der VDR nicht mehr.



  • Hast du mal versucht, das Plugin mit "make DEBUG=1" zu übersetzen und die Logs verglichen?


    Beim Vergleich des Debug-Logs (1.Lauf / 2.Lauf) fällt in der Tat auf, dass folgende Zeilen im 2. Lauf weiter unten stehen:

    Code
    ovgthread thread started (pid=193, tid=205, prio=high)
    rpihddevice: cOvgThread() thread started


    Hinweis: Ich habe den VDR über ssh und ohne angeschlossenen Monitor gestartet (siehe run1.txt und run2.txt).



    Irgendwie muss das Timing beim zweiten Start anders sein, so dass der OpenVG-Thread scheinbar verzögert anläuft, und beim Zeichnen auf das OSD noch nicht bereit ist.


    Nach Einbringen des Patches gab es keinen Absturz mehr.
    Den Hinweis "rpihddevice: [OpenVG] OSD not ready.." sehe ich reproduzierbar bei jedem zweiten Aufruf des VDR.
    Danach taucht er ab und zu auf, aber ohne erkennbare Regelmäßigkeit.


    Siehe dazu run3-hdmi.txt (mit angeschlossenem Monitor).

  • Timing?!
    Ich kompiliere die VDR-Pakete grundsätzlich mit -O3, nachdem das von Klaus seit VDR 1.7.17 als Default angegeben wird.
    http://projects.vdr-developer.…dr.git/tree/HISTORY#n6546
    Edit: Alles natürlich unter der Annahme, dass er meine Pakete verwendet.


    Wenn das Build-Skript aus dem AUR von Dir ist:
    Ich habe auf den Tarball referenziert ("http://projects.vdr-developer.org/attachments/download/1918/${pkgname}-${pkgver}.tgz") und den git-Verweis entfernt.
    Evtl. sollte man zwei Pakete bereitstellen.


    Gebaut wird das Plugin sowohl mit Compiler-Schalter -O2 und -O3. Da O3 später auftaucht, gewinnt O3.
    Mir ist allerdings nicht klar, wo die Optimierungen herkommen. Aus dem Makefile offensichtlich nicht.

    ASRock ION 330HT mit TT-connect S2-3600
    Arch Linux VDR 2.2.0
    VDR user #2043

  • Gebaut wird das Plugin sowohl mit Compiler-Schalter -O2 und -O3. Da O3 später auftaucht, gewinnt O3.
    Mir ist allerdings nicht klar, wo die Optimierungen herkommen. Aus dem Makefile offensichtlich nicht.


    Das müsste aus den Build-Flags für den VDR (über die Make.config) und den Build-Optionen aus der /etc/makepkg.conf stammen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • allerdings startet dann der VDR nicht mehr.


    Mit den Änderungen im Makefile sorgst du zwar dafür, dass der Compiler die Libs kennt, allerdings fehlen sie dann immer noch im Suchpfad wenn der VDR startet. Ich habe bei mir die Links so gesetzt:


    Code
    localhost lib # ls -lh /usr/lib/libG*
    lrwxrwxrwx 1 root root 35 Apr  4 18:32 libGLESv2.so -> opengl/raspberrypi/lib/libGLESv2.so
    localhost lib # ls -lh /usr/lib/libE*
    lrwxrwxrwx 1 root root 32 Apr  4 18:33 libEGL.so -> opengl/raspberrypi/lib/libEGL.so


    Gruss
    Thomas

  • Nach Einbringen des Patches gab es keinen Absturz mehr.
    Den Hinweis "rpihddevice: [OpenVG] OSD not ready.." sehe ich reproduzierbar bei jedem zweiten Aufruf des VDR.
    Danach taucht er ab und zu auf, aber ohne erkennbare Regelmäßigkeit.

    Danke fürs Testen. Werde den Fix so einchecken, allerdings ohne die Fehlermeldung. Kann natürlich schon sein, dass der Thread noch nicht läuft, daran habe ich nicht gedacht. Warum das bei dir allerdings jedes zweite Mal passiert, kann ich mir nicht erklären.


    Gruss
    Thomas

  • Wenn das Build-Skript aus dem AUR von Dir ist:
    Ich habe auf den Tarball referenziert ("http://projects.vdr-developer.org/attachments/download/1918/${pkgname}-${pkgver}.tgz") und den git-Verweis entfernt.
    Evtl. sollte man zwei Pakete bereitstellen.


    Ohh, ich sehe gerade dass das PKGBUILD im AUR total veraltet ist. Ich muss morgen unbedingt mal nach dem Upload Skript schauen.
    Das mit dem Git-Verweis wurde mir so von den TUs erlaubt, solange es auf eine feste Revision gebaut wird. Ist es dynamisch müsste ich -git hinten am Paketnamen anhängen.



    Soviel zu den Arch-Eigenheiten. Back to Topic

  • Code
    May 14 11:57:47 [vdr] [2028] rpihddevice: OmxError(InsufficientResources)

    Wie viel vom Arbeitsspeicher darf sich die GPU denn abknapsen?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo Thomas,
    - könnte man bei zu wenig Speicher, nicht vom Plugin aus, eine passende Fehlermeldung ins Log schreiben? Z.B. Bitte der GPU mehr Arbeitsspeicher spendieren...
    - sollte die Spannung zu gering sein, könnte man auch gpio35 abfragen und bei unterschreiten einer Spannung von 4,7V eine Fehlermeldung generieren. Z.B. Eine OSD Fehlermeldung (siehe hier: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=82373 )


    Was meinst?

Jetzt mitmachen!

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