[Prototyp] RPI Ausgabeplugin

  • Leider bleibt er bei mir damit immer noch beim Initialisieren des rpihddevice-Plugins hängen:

    Code
    Apr 02 18:06:10 archberry vdr[281]: [285] video directory scanner thread started (pid=281, tid=285, prio=high)
    Apr 02 18:06:10 archberry vdr[281]: [286] epg data reader thread started (pid=281, tid=286, prio=high)
    Apr 02 18:06:10 archberry vdr[281]: [284] video directory scanner thread started (pid=281, tid=284, prio=high)
    Apr 02 18:06:10 archberry vdr[281]: [281] initializing plugin: rpihddevice (0.0.8): HD Ausgabegerät für Raspberry Pi
    Apr 02 18:06:10 archberry vdr[281]: [286] reading EPG data from /var/cache/vdr/epg.data
    Apr 02 18:06:10 archberry vdr[281]: [281] rpihddevice: using HDMI video output at 1280x1024p
    Apr 02 18:06:10 archberry vdr[281]: [281] new device number 1
    Apr 02 18:06:15 archberry vdr[281]: [286] epg data reader thread ended (pid=281, tid=286)
    Apr 02 18:06:46 archberry vdr[281]: [284] video directory scanner thread ended (pid=281, tid=284)
    Apr 02 18:06:46 archberry vdr[281]: [285] video directory scanner thread ended (pid=281, tid=285)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • mit gcc 4.6 läufts, mit gcc 4.8 nicht. Compilieren tun beide, aber das Compilat vom gcc 4.8 ist auch 640k groß, das vom gcc 4.6 nur 517k (beides mit gleichen Einstellungen compiliert)


    Vielen Dank fürs Feedback - hmm... langsam aber sicher verstehe ich die Welt nicht mehr.


    Ratlos,
    Thomas

  • wenn der gcc im Arm Bereich vielleicht noch weitere Bugs beinhaltet,
    was spricht eigentlich dagegen, derzeit die Empfehlung für ein Downgrade auf gcc 4.6 auszusprechen.


    Code
    root@pi:/var/log# cat /etc/issue
    Debian GNU/Linux jessie/sid \n \l


    unter jessie ist bei mir bsw. gcc 4.6 und 4.8 parallel installiert. Da brauche ich nur den gcc-Link von 4.8 auf 4.6 zu ändern.

  • Hi,


    stören tut der Patch jedenfalls nicht ;)


    Ich hab übrigens einfach das Makefile um diese Zeilen erweitert:

    Code
    CC  = gcc-4.6
    CXX = g++-4.6


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • wenn der gcc im Arm Bereich vielleicht noch weitere Bugs beinhaltet,
    was spricht eigentlich dagegen, derzeit die Empfehlung für ein Downgrade auf gcc 4.6 auszusprechen.

    Na ja, die Wahrscheinlichkeit dass es sich um einen Fehler im Compiler handelt, ist wohl recht klein. Hier ist auch die Rede davon, dass 4.7 und 4.8 schnellere Kompilate erzeugen - und da diese scheinbar auch grösser sind, wird wohl einfach anders optimiert. Ich vermute deshalb das Problem bei der Reihenfolge, wie die Threads im Plugin gestartet werden, und dass sich da vielleicht ein Deadlock ergibt, weil neuere Compiler anders optimieren. Das ist momentan die logischste Erklärung die ich mir machen kann.


    Gruss
    Thomas

  • Hi,


    bist Du denn schon dazu gekommen, das ganze auch Fehler beim Speicherzugriff zu untersuchen, so wie ich das vor ein paar Tagen vorgeschlagen hatte, oder ist das aktuell diskutierte Problem noch ein anderes?


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • bist Du denn schon dazu gekommen, das ganze auch Fehler beim Speicherzugriff zu untersuchen, so wie ich das vor ein paar Tagen vorgeschlagen hatte, oder ist das aktuell diskutierte Problem noch ein anderes?


    Nein, das versuche ich heute Abend. Aber es gab auch ein Problem, bei dem im Log die Meldungen "rpihddevice: failed to pass buffer to video decoder!" auftauchen - dieser Fehler sollte mit dem Patch eigentlich behoben sein. (OMX-Events gehen verloren, dadurch wird die Video-Pipe nicht komplett aufgesetzt und der Decoder "verstopft") Meine Hoffnung war halt, dass das Compilerproblem auch damit zusammenhängt - ist aber scheinbar nicht so.


    Gruss
    Thomas

  • Also, mit DUMA (Nachfolger von efence) startet nicht mal mehr plain vdr ohne abzustürzen und valgrind meint bei der Installation:

    Code
    checking for a supported CPU... no (armv6j)
    configure: error: Unsupported host architecture. Sorry


    So wirklich Spass machen tut das so nicht...


    Gruss
    Thomas

  • Capulet:
    HW: Dell Dimension 3100, Pentium 4 3GHz, 2GB RAM, 160GB HDD (System), 1TB HDD (Video), 1 x TT S2-1600, 1 x Technisat Skystar HD | SW: Debian 7.4, VDR 2.0.4 (selfcompiled), dummydevice 2.0.0, streamdev-server 0.6.1, NFS-Server


    TiViPi01:
    HW: Raspberry Pi Mod. B Rev. 2, 512MB RAM, 8GB SD-Card, Teko TEK-BERRY.9 Gehäuse, Ednet 85024 USB 2.0 Hub, Digitainer X10 Funk-Fernbedienung | SW: Raspbian 01/2014, VDR 2.0.4 (selfcompiled), rpihddevice 0.0.8, ffmpeg 1.0.8, streamdev-client 0.6.1, NFS-Client


  • Nein, das versuche ich heute Abend. Aber es gab auch ein Problem, bei dem im Log die Meldungen "rpihddevice: failed to pass buffer to video decoder!" auftauchen - dieser Fehler sollte mit dem Patch eigentlich behoben sein. (OMX-Events gehen verloren, dadurch wird die Video-Pipe nicht komplett aufgesetzt und der Decoder "verstopft") Meine Hoffnung war halt, dass das Compilerproblem auch damit zusammenhängt - ist aber scheinbar nicht so.


    Gruss
    Thomas


    Hallo Thomas,


    ich habe mir gerade einmal den Source von cOmx angesehen, ich denke, da fehlt auch ein Mutex und zwar für "m_portEvents".
    diese Queue wird in Action verarbeitet, aber der push erfolgt vielleicht in einem anderen Thread.


    Teilst du meine Meinung.


    Guido

  • Hi Guido

    ich habe mir gerade einmal den Source von cOmx angesehen, ich denke, da fehlt auch ein Mutex und zwar für "m_portEvents".
    diese Queue wird in Action verarbeitet, aber der push erfolgt vielleicht in einem anderen Thread.

    Hast du dir die Sourcen aus dem GIT angeschaut, oder hast du diesen Patch schon appliziert?


    Mit dem Patch sind die direkten Zugriffe auf die Queue (IMHO) alle geschützt, geschrieben werden die Events grundsätzlich nur via Callbacks aus dem OMX-Kontext.


    Gruss
    Thomas


  • Danke für die Links! Bei Valgrind komme ich mir der Anleitung bei "./configure" bis zu:

    Code
    checking the GLIBC_VERSION version... unsupported version 2.15
    configure: error: Valgrind requires glibc version 2.2 - 2.14


    Den Downgrade von glibc auf 2.14 mochte mein System gar nicht... zum Glück mounte ich das Filesystem über NFS, da war das schnell wieder geflickt.


    Bleibt noch efence als letzter Versuch.


    Gruss
    Thomas

  • reufer:


    aktuelle Version aus dem GIT + Patch:


    Bisher sind die von dir beschriebenen Log-Meldungen nicht mehr aufgetreten.


    Was ich immer noch regelmäßig beobachte: "Butter stall"


    Zudem hängt sich der VDR beim beenden einer Wiedergabe alle 2-3 Tage komplett auf so dass der Watchdog nach der eingestellten zeit zuschlägt.
    Es kommen aber keine Meldungen etc...


    CU
    GTR

  • Bisher sind die von dir beschriebenen Log-Meldungen nicht mehr aufgetreten.

    Das ist schon mal gut - danke fürs Testen!


    Was ich immer noch regelmäßig beobachte: "Butter stall"

    Wie regelmässig? Sehe ich bei mir auch zwischendurch, vielleicht jedes zwanzigste Mal, wenn ein neuer Stream startet (Kanalwechsel oder Starten einer Aufnahme).


    Zudem hängt sich der VDR beim beenden einer Wiedergabe alle 2-3 Tage komplett auf so dass der Watchdog nach der eingestellten zeit zuschlägt.
    Es kommen aber keine Meldungen etc...

    Du hast nicht per Zufall das Log, was vorher passiert ist? Interessant zu wissen wäre auch, ob die CPU-Last dabei hoch geht, weil z.B. ein Thread in einer Endlosschleife dreht.


    Gruss
    Thomas


  • Hallo Thomas,


    aus dem GIT.


    Guido

  • Zum Thema gcc: Da die Probleme scheinbar ab Version 4.7 auftreten, habe ich mir mal dessen Release Notes angesehen:

    Zitat

    On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or ARMv7-M, the new option -munaligned-access is active by default, which for some sources generates code that accesses memory on unaligned addresses. This requires the kernel of those systems to enable such accesses (controlled by CP15 register c1, refer to ARM documentation). Alternatively, or for compatibility with kernels where unaligned accesses are not supported, all code has to be compiled with -mno-unaligned-access. Upstream Linux kernel releases have automatically and unconditionally supported unaligned accesses as emitted by GCC due to this option being active since version 2.6.28.


    Könnte das ein Problem sein? Wenn ja, könnte jemand mit gcc-4.7 den Test aufs Exempel machen, und das Plugin mit dem Flag "-mno-unaligned-access" kompilieren? Ich denke mal, das müsste dann so aussehen:


    Gruss
    Thomas

  • Für mich ändert sich mit dem gcc-4.8.2 damit leider nichts, er bleibt immer noch beim Initialisieren des Plugins hängen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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