softdevice-0.0.7 will nicht unter vdr-1.3.12

    kompilieren geht ohne Probleme nur leiter kommt dann immer in /var/log/messages


    Aug 15 23:19:03 localhost vdr[7029]: VDR version 1.3.12 started
    Aug 15 23:19:03 localhost vdr[7029]: loading plugin: /usr/lib/vdr/plugins/libvdr-softdevice.so.1.3.12
    Aug 15 23:19:04 localhost runvdr: stopping after fatal fail (vdr: /usr/lib/vdr/plugins/libvdr-softdevice.so.1.3.12: undefined symbol: _Z15pp_free_contextPv)


    das kommt immer egal welche unterstützung ich nehme (DFB, XV, FB etc.)

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

    da kommt dann das


    /var/lib/dpkg/info/libpostproc0.shlibs
    /var/lib/dpkg/info/libpostproc0.list
    /var/lib/dpkg/info/libpostproc0.md5sums
    /usr/share/doc/libpostproc0
    /usr/share/bug/libpostproc0
    /usr/lib/libpostproc.so.0.0.1
    /usr/lib/libpostproc.so.0


    ich sollte dazusagen das das ein vorgefertigtes Packet war vielleicht sollte ich es mal von Hand neu machen

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

    so jetzt habe ich mal postproc neu gemacht und jetzt gehts immer noch net


    /usr/lib/libpostproc.so.0.0.1
    /usr/lib/libpostproc.a
    /usr/lib/libpostproc.so.0
    /usr/lib/libpostproc.so
    /usr/share/bug/libpostproc0
    /usr/share/bug/libpostproc-dev
    /usr/share/doc/libpostproc0
    /usr/share/doc/libpostproc-dev


    aber mit einer anderen meldung
    Aug 16 05:11:33 localhost vdr[17579]: loading plugin: /usr/lib/vdr/plugins/libvdr-softdevice.so.1.3.12
    Aug 16 05:11:33 localhost runvdr: stopping after fatal fail (vdr: /usr/lib/libpostproc.so.0: undefined symbol: fast_memcpy)


    Bin so langsam an verzweifeln

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

    Mir kommt das auch sehr Rätselhaft vor. Durch die Neugenerierung von libpostproc hat sich aber die Fehlermelung jetzt geändert. Paßt da evtl. libpostproc nicht mit libavcodec zusammen ? Wenn Du auf die Deinterlacer von libpostproc verzichten kannst: mal im Makefile von softdevice PP_LIB.. auskommentieren.


    Stefan Lucke

    Ja du hast recht jetzt ist der Fehler weg...


    nur leider hängt er jetzt in einer lade schleife ohne Fehlermeldung wieder egal was ich benutze ich glaube langsam das das mit Debian Sarge nicht geht oder vielleicht liegt es ja auch an meinen EPIA Bord.


    Ich hatte auch mal probe halber die MMX unterstützung aus ohne ergebnis


    hier noch mal einen auszug aus der messageslog



    Aug 16 17:40:56 localhost vdr[11102]: initializing plugin: softdevice (0.0.7pre2): A software emulated MPEG2 device
    Aug 16 17:40:57 localhost kernel: Console: switching to colour frame buffer device 128x48
    Aug 16 17:40:57 localhost runvdr: restarting VDR

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

    Ach ein EPIA board ;( . Welche Ausgabe-Methode kommt da bei dir in Frage ? Der Framebuffer muß auf die richtige (tm) Auflösung (min 720x576 bei 16bit Farbtiefe) gesetzt werden (128x48 ist etwas zu wenig). FB-Out ist die am wenigsten entwickelte Methode (keine Skalierung). DirectFB wäre da besser (siehe vdr-ml vom Anfang des Monats) allerdings mit wechselhaftem Erfolg (bei EPIA-Boards). VIDIX hab ich mit diesem Board noch nicht getestet.


    Stefan Lucke

    naja benutze ja auch DFB ja auch alles andere wäre ja mit so eine CPU unrealistisch....


    Leider geht zur zeit nicht Linuxtv.org...


    aber nochmal zur besseren verständnis um DFB zu nutzen muß ich vorher ein framebufferdevice geladen haben oder ?

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

    www.directfb.org ist auch nicht zu erreichen :( .
    Was für ein EPIA-Board hst Du denn ? (bei mir ist es m10000)
    Ja der Framebuffer-Treiber sollte gelagen sein bzw. es sollte zu mindest per Vesa-Treiber eine passende Auflösung eingestellt werden. Das Ändern der Auflösung geht mit fbset MODE_NAME. Bei vesa läßt sich die Auslösung später halt nicht mehr ändern. Mit viafb habe ich halt auch so meine Probleme da die Console-Text-Ausgabe verschwand und ich nur noch remote arbeiten konnte. Das bezieht sich auf ein Gentoo system mit Kernel 2.6.7.

    habe das selbe Bord und das mit viafb treibern unter 2.6.7 kann ich auch unter Debian bestätigen.


    Nach einigen Foren sollte aber eigentlich vesafb und directfb auf den Epia-Bords gut hamonieren deswegen hatte ich auch die Kombination im Sinne.
    Aber langsam glaube ich das es irgendwas mit debian zu tun hat den selbst wenn ich versuch den XV teil zu nehmen hängt der sich in ladeschleife. Ist ja auch schon mit den libpostproc so komisch gewesen.


    Leider habe ich nur ein bischen C++ Kenntnisse aber was hällst du von http://unichrome.sourceforge.net/ den viaXvMC Teil der sollte ja eigendlich auch gut zu deinem Projekt passen. Weil so könnte man die Multimedia Fähigkeiten der Bords gut ausnutzen.

    "Wir kehren unsere miesen Lieder nicht unter dem Teppich, wir spielen sie als Zugabe." Zitat die Ärzte

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden