Beiträge von Jarvelin

    Hallo Zusammen,


    nachdem ich hier im Forum meist nur Empfänger von Informationen bin, möchte ich heute auch mal was zurück geben.


    Um aus dem Banana Pi einen vollwertigen Client zu machen muss man das Gerät ja auch irgendwie aus seinen Schlaf erwecken können.
    Und das ohne extra zum TV latschen zu müssen. (Das ist ja sowas von 2007).
    Ob das generell notwendig ist muss man selber wissen. Der BPi kan problemlos am USB des TV betrieben werden, und startet sobald er Strom kriegt.
    Zum sauberen herunterfahren müsste man dann aber eine kleine Gangreserve vorsehen. Basteln muss man also auf jeden Fall.



    Ein Arduino Mini Pro in Verbindung mit einen TSOP32238, einer Diode, einen Taster und zwei Widerständen soll den Job erledigen..


    Die Aufwändigste Modifikation ist einen Pin an den Banana Pi zu löten. Leider haben es die BPi Entwickler versäumt den PowerOn Pin zugänglich zu machen. Also wird direkt am Power-Taster ein Header-Pin angelötet und mit Kleber fixier. Ich empfehle hier einen Kleber der bei UV Bestrahlung aushärtet. So kann man erst die Position gut korrigieren, und hat das Teil dann in 10 Sekunden ausgehärtet.


    Kurz das Gehäuse ein wenig bearbeitet, und schon kann das Teil einziehen. Der Arduino Mini Pro wird vom BPi auch im heruntergefahrenen Zustand mit Strom versorgt. Die 3,3V Schiene wird im heruntergefahrenen Zustand "abgeschaltet" (1V kann man noch messen) und wird als Indikator genommen ob der BPi an ist, oder nicht. Zum einschalten wird der neue Pin für 2 Sekunden auf Masse gezogen. Die Diode soll dazu dienen einen Stromfluss vom Arduino zum BPi zu verhindern.


    Funktion: Nach dem Start leuchtet die grüne LED am Arduino dauerhaft und Signalisiert den Grundzustand.
    Drückt man den Taster zum Anlernen blinkt die LED 3 Mal und erlischt.
    Zum Anlernen muss die entsprechende Taste 5 mal betätigt werden. Jeder erfolgreiche Tastendruck wird mit einen blinken quittiert in der Anzahl der Stufe in der er sich befindet. Wird zwischendurch eine andere Taste betätigt fängt das spiel von Vorne an. Nach erfolgreichen anlernen wird der Wert im EEPROM gespeichert und wieder in den Grundzustand gewechselt.
    Empfängt der Arduino jetzt den Code wird der Pin für 2 Sekunden auf Masse gezogen. In dieser Zeit erlischt auch die LED.
    Wenn der BPi läuft wird der Code einfach ignoriert um ein unbeabsichtigtes betätigen des Tasters zu verhindern.


    Vlt. kann es ja jemand gebrauchen.


    Gruß,
    Jarv


    Edit:
    Es soll nicht unerwähnt bleiben das ich mir diese Idee vom Kollegen bloern abgeschaut habe. Danke.

    Nabend,


    yes!


    Es läuft. Scheinbar war es wirklich noch ein libav-Paket das ich versehentlich installiert habe. Asche über mein Haupt!


    Ich habe mich an diese Anleitung gehalten, aber abweichend nur folgende Pakete zum kompilieren installiert.


    Code
    apt-get install libmagick++5 liblockdev1 autoconf autopoint qt3-dev-tools
    qt4-qmake libqt4-dev mercurial libcxxtools-dev libpcre3-dev libtntnet-dev
    libboost-dev libtool libcdio-dev libvcdinfo-dev libcap-dev libjpeg-dev
    vflib3-dev gettext libfribidi-dev libncurses5-dev libncursesw5-dev vim libssl-dev imagemagick
    libmagick++-dev libproc-processtable-perl libmpg123-0 libmpg123-dev libva-dev


    Dann vectras Pakete, VDR, usw.


    Jetzt get es ans Testen.


    Danke für die Mithilfe!


    Jarv

    Nabend,


    beim Abarbeiten der Raspi-Installationsanleitung bin ich darauf gestoßen das libpostproc wohl libavutil51 mitbringt.


    Nach entfernen der zwei Pakete baue ich gerade VDR 2.1.4, rpihddevice 0.0.8 und streamdev mit den oben verlinkten Paketen.
    Damit sollte ich eigentlich den gleichen Softwarestand wie vectra130 haben.


    Bin gespannt...

    Hallo,


    so, Kinder ins Bett gesteckt, jetzt kann es weiter gehen...


    Also. Ich war der meinung das bei Rasbian "Console" libav nicht installiert wäre. Die Pakete libavcodec und libavformat waren nicht da.




    Jarv


    PS: Wie ich gerade sehe gibt es noch mehr libav-Pakete. DA werde ich nochmal aufräumen müssen





    EDIT:

    Code
    aptitude purge libav-tools libavutil libavformat libavcodec libswscale


    Keins dieser Pakete war installiert.

    Hallo Vectra,


    ich habe Deine Pakete installiert und den VDR, rpihddevice und streandev neu kompiliert.


    Gleiche Fehlermeldung wie zuvor. Werde zu Hause nochmal eine frische SD Karte nehmen und neu beginnen.



    @bobmeier


    Ich hab derweil ein wenig in den Foren gestöbert, und einige Probleme dieser Art mit VLC gefunden. Dort hieß die Lösung downgrade. Wie weit zurück konnte ich aber irgendwie nicht herausfinden.



    Gibt es überhaupt jemanden der Rasbian und ffmpeg-rpihddevice am laufen hat?



    Jarv

    Ok, nachdem ich also


    Code
    libva-dev
    x264
    mp3lame
    faac


    installiert, kompiliert und wiedermals installiert habe (wie es in jeden Handelsüblichen ffmpeg Howto beschrieben wird) bin ich genauso weit wie letzte Woche als ich ffmpeg noch von Hand durchgedreht hatte: (Hier der Link zum damaligen Post )


    Code
    vdr: /usr/lib/libavcodec.so.54: symbol av_asprintf, version LIBAVUTIL_51 not defined in file libavutil.so.51 with link time reference


    In einen forum hab ich gelesen das sowohl x264 als auch ffmepeg mit --enable-shared kompiliert werden soll.


    Bei x264 hab ich das. Wie siehts mit ffmpeg aus?


    Jarv

    Hallo bobmeier,


    dank gda bin ich der Sache schon auf die schliche gekommen und hab das Paket installiert.


    In der zwischenzeit hab ich schon x264 kompiliert, und bin jetzt bei libmp3lame dran.


    Wenn ich die Abhängigkeiten durch hab melde ich mich nochmal.


    Jarv

    Hallo vectra 130,


    danke für Deine mühen dieses Paket zu erstellen. :tup
    Ich hab ffmpeg selber schonmal auf dem Raspi (erfolglos?) kompiliert. Ich konnte zwar alles durchdrehen, doch lief es im nachhinein nicht.


    Frisches Rasbian genommen, Dein Paket installiert und danach VDR 2.0.5 und rpihddevice kompiliert.
    Soweit ich sehen konnte Fehlerfrei durchgelaufen.


    Jedoch startet der VDR mit folgender Meldung nicht:


    Code
    vdr: libva.so.1: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden


    Ideen?


    Jarv

    Hallo Zusammen,


    ich verzeifel gerade ein wenig beim Bau des Plugins. Bisher habe ich die libav.org Pakete verwendet. Hier wird aber immer wieder betont das mit den ffmpeg.org Codecs gearbeitet wird.


    Also wollte ich mir auch die Mühe machen und das ganze neu durchzudrehen.



    • Raspbian
    • ffmpeg 1.0.8
    • vdr2.0.5
    • rpihddevice 0.0.8
    • streamdev latest git


    Als erstes gab es ein remove der Pakete libavcodec-dev und libavformat-dev und deren 53er Varianten.


    Ich habe erst das ffmpeg gebaut, direkt auf dem Raspi. Dazu habe ich die Flags von reufer auf Seite 30 genommen. (Abzüglich der Flags fürs Cross compiling)


    Danach gings an VDR und Plugins per make && make install.


    Das ist auch alles ohne Probleme durchgelaufen, jedoch startet der VDR nicht.


    Code
    vdr: /usr/lib/libavcodec.so.54: symbol av_asprintf, version LIBAVUTIL_51 not defined in file libavutil.so.51 with link time reference




    Wäre super wenn mir jemand ein wenig helfen könnte. Ich nahm an das die libavcodec und libavutil beide durch das ffmepg erzeugt werden und dann auch zueinander passen müssten. Oder sind das Reste der libav.org Pakete. Kriegt man das irgendwie heraus?


    :(


    Gruß,


    Jarv

    Hallo,


    danke Gerald. Bisher hat alles supi funktioniert, daher bin ich in dieser Thematik (noch) nicht sehr tief drin.


    Das bedeutet das die lircd.conf die einzige Stelle sein sollte wo etwas geändert werden sollte.



    @seahawk1986


    Die lircd.conf im Github scheint in meinen Augen Falsch zu sein.


    Laut VDR Wiki:

    Code
    Achtung: In der Harmony-Konfiguration gibt es drei Buttons "Power
     Toggle", "Power On/Off" und "PowerOff". Um den VDR mit der hier 
    gezeigten lircd.conf und remote.conf Kombination den VDR auzuschalten, 
    muss der Button "PowerOff" benutzt werden. ("PowerOff" sendet "0x12cc", 
    0x12cc -> lircd.conf -> "Standby" -> remote.conf -> 
    "LIRC.Power")


    Im Github ist der Code 0x12CC mit KEY_ZOOM bezeichnet, sollte aber KEY_POWER2 sein, da das in der remote.conf ja für LIRC.Power zugeordnet ist.




    Jarv

    Nabend,


    bei mir gibts genau das gleiche verhalten.


    yaVDR 0.5 Final


    Harmony 555 mit KLS 1.6
    Lirc Config übers WebInterface Uart Homebrew KLS.6


    Der Power Button erzeugte gemäß der lircd.conf ein KEY_ZOOM (irw).


    Laut VDR Wiki sollte der Code 0x12cc aber STANDBY heißen.


    lircd.conf

    Code
    KEY_ZOOM       	0x12cc
    KEY_POWER2  	0x12cb



    remote.conf

    Code
    LIRC.Power KEY_POWER2



    Nach ändern


    lircd.conf

    Code
    KEY_POWER       	0x12cc
    KEY_POWER2  	0x12cb


    und


    remote.conf

    Code
    LIRC.Power KEY_POWER


    Die Änderungen in der Lircmap.xml sind analog auszuführen.




    Ich vermute das beim umsetzen in das neue KEY_ -Format ein Fehler passiert ist? Die Remote.conf wird glaub ich ja automatisch erzeugt, und sucht vermutlich nach dem Schlüsselwort "KEY_POWER". Daher gibts keine korrekte Zuordnung der Taste?




    Gruß,
    Kai

    Nabend,


    was funktioniert kann ich Dir ohne weiteres nicht sagen, aber das Ausschussverfahren ist ja auch nicht schlecht.


    Vergessen kannste vollkommen diese USB <-> Centronics Druckerkabel. Denen fehlen leider etliche Steuerleitungen für nen echten Parellelport-Betrieb.
    Hab ich schon Probiert und danach nen Alphacool USB gekauft. (Kann ich auch nicht empfehlen. Schlechter Kontrast)



    Gruß,
    Jarv

    Servus,


    hast Du mal die Deinterlacer Optionen angeschaut? Bei HD ist Bob standart, was bei mir schon zu irritationen am Sehnerv hervorruft.


    Bei meinen Zotac Ion ITX -F ist das Bild bei gleichen Einstellungen deutlich besser. Besonders das Flackern bei Weiß/Rot Kontrasten war früher recht unschön...


    Gruß,
    Jarv

    Hallo durchflieger,


    ich hab das mit den Paketen mal ausprobiert.
    Und du hast recht ;D


    Wahrscheinlich hab ich nicht gut genug gelesen. Prinzipiell hätte die Install Anweisung schlicht heißen können:


    1) dpkg-buildpackage -b -D -tc -sd -us -uc
    2) dpkg -i dfatmo_0.1-0_amd64.deb
    3) dpkg -i libxine-dfatmo-plugin_0.1-0_amd64.deb


    Einzige schwierigkeit wäre dann noch das Template für yaVDR zu erstellen.


    Unter XBMC einfach das Zip installieren und die Einstellungen im Menü vornehmen. Läuft!


    Damit bist Du eindeutig Entwickler des Monats für mich! (Bis heute war ich es selber, aber private Projekte toppen definitiv geschäftliche :D )


    Anyway, hast darüber nachgedacht mal ein VDR Paket zu erstellen? So das die Einstellungen genauso komfortabel wie unter XBMC vorgenommen werden können und auch das Template unter yavdr überflüssig wird?
    Das wäre echt :tup !



    Danke-sai!
    Lange Tage, angenehme Nächte!


    Jarv

    Nabend Leute,


    nach ein wenig stöbern in den makefile ind mir 2 Sachen aufgefallen:
    1) mir fehlte wohl das libxine-dev Paket
    2) gibt es noch deutlich mehr Ziele für make außer dfatmo. (z.B. xineplugin)


    However: Ein beherztes

    Code
    make all
    cp xineplug_post_dfatmo.so /usr/lib/xine/2.0/post/


    Und läuft!


    Jetzt bin ich mal gespannt wie das unter XBMC geht.


    Gruß,
    Jarv

    Ich denk grad selber nochmal drüber nach...


    Das make dfatmoinstall legt die Dateien "/usr/local/lib"


    Ist das für den VDR so richtig? Hab ein wenig gestöbert, und andere xine post plugins liegen scheinbar woanders.


    "/usr/lib/xine/plugins/2.0/post/xineplug_post_tvtime.so" z.B.



    Wo muss also das plugin liegen?


    Mit xine-Parameter: --verbose= ? müsste ich ja mehr debugausgaben erhalten. Auf welches level soll ich das debug anheben? (Wenn ich wieder zu Hause bin)

    Hallo Leute,


    hab heute mal die 0.4 auf mein Rechner installiert. Läuft soweit ganz gut. Nun sollen die Extras laufen...


    Durchflieger hat für mein geliebtes Atmolight ein neues Plugin erstellt das das bisherige libxine-atmo-plugin ablöst.
    https://github.com/durchflieger/DFAtmo#readme


    Das DFAtmo soll außerdem dann mit XBMC zusammenarbeiten.
    Leider hat es das Plugin nicht mehr in die 0.4 geschafft, daher hab ich versucht es vom GIT zu installieren.


    Nach kompilieren und installieren mit

    Zitat

    make dfatmo


    Code
    root@yavdr:/usr/local/src/atmo/DFAtmo# make dfatmo
    /bin/sh: pkg-config: Kommando nicht gefunden.
    /bin/sh: pkg-config: Kommando nicht gefunden.
    cc -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -O3 -pipe -Wall -fPIC -g -DOUTPUT_DRIVER_PATH='"/usr/local/lib/dfatmo/drivers"' -c -o atmodriver.o atmodriver.c
    cc -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -O3 -pipe -Wall -fPIC -g -shared -fvisibility=hidden -lpthread -ldl -lutil -lm -lpython2.7 -lm -ldl -o atmodriver.so atmodriver.o
    cc -O3 -pipe -Wall -fPIC -g -c -o dfatmo-file.o fileoutputdriver.c
    cc -O3 -pipe -Wall -fPIC -g -shared -fvisibility=hidden -o dfatmo-file.so dfatmo-file.o
    cc -O3 -pipe -Wall -fPIC -g -c -o dfatmo-serial.o serialoutputdriver.c
    cc -O3 -pipe -Wall -fPIC -g -shared -fvisibility=hidden -o dfatmo-serial.so dfatmo-serial.o
    root@yavdr:/usr/local/src/atmo/DFAtmo#

    und

    Zitat

    make dfatmoinstall


    Code
    root@yavdr:/usr/local/src/atmo/DFAtmo# make dfatmoinstall
    /bin/sh: pkg-config: Kommando nicht gefunden.
    /bin/sh: pkg-config: Kommando nicht gefunden.
    install -m 0755 -d /usr/local/lib/dfatmo
    install -m 0644 -t /usr/local/lib/dfatmo atmodriver.so
    install -m 0755 -d /usr/local/lib/dfatmo/drivers
    install -m 0644 -t /usr/local/lib/dfatmo/drivers dfatmo-file.so dfatmo-serial.so
    install -m 0644 -t /usr/local/include dfatmo.h
    root@yavdr:/usr/local/src/atmo/DFAtmo#

    und den Eintragungen in der vdr-frontend.conf kriege ich aber absolut kein Leuchten zustande.


    custom template:


    Code
    ## Adding Xine ATMO-Post Plugin
    XINEOPTS="$XINEOPTS --post=dfatmo:driver=serial,driver_param=/dev/ttyUSB0,top=1,bottom=1,left=1,right=1,brightness=150,enabled=1,filter_delay=2000 "


    Ich kann nichtmals sehen ob im postprocessing das plugin gestartet wird.


    Was kann ich tun um zu prüfen ob das plugin gestartet wird. Xine im debug höher setzen?


    Gruß,
    Jarv

    Hallo UnWitt,


    ich glaube an der Konfiguration von GraphLCD hat sich nichts geändert.
    Die Anleitung die ich verlinkt habe ist sehr detailliert, und mit den Ergänzungen aus dem Post hier solltest Du das hinkriegen unter yaVDR.
    Mit 0.4 hab ich (noch) keine Erfahrung mit graphLCD gemacht.


    Wenn ich nochmal die Wahl hätte würde ich das Megtron Display empfehlen, dort lässt sich auch der Kontrast einstellen. Finde das Alphacool etwas mau in der hinsicht.


    Viel Erfolg :tup


    Jarv

    Servus Gemeinde,


    ich würde gerne mein Alphacool 240x128 Display unter XBMC was anzeigen lassen, also nicht nur die Anzeigen die der VDR im Hintergrund aufs Display schreibt.


    Laut Theorie soll XBMC LCDproc nutzen um maximal 20x4 Zeichen anzuzeigen.
    LCDproc hat die Möglichkeit als Treiber einen nativen [glcdlib]-Treiber als Schnittstelle zu Graphlcd zu nutzen.
    Das Missing-Link, der Treiber der LCDproc und GraphLCD verbindet, soll der glcprocdriver sein.


    Nach Muresan habe ich den Treiber compiliert und installiert.


    Die LCDproc.conf habe ich nach den Hinweisen von Albert Zangerl (Stück weiter runter, Stichwort LC-Display Ärger)
    hoffentlich richtig konfiguriert.


    Ich bin mir relativ sicher das man in XBMC sagen konnte das er ein Display nutzen soll. Aber ich finde es nicht mehr.


    So wie es aussieht wird LCDproc nicht getsartet, und der VDR hat weiterhin zugriff auf das LCD.


    Wäre echt super wenn mir da jemand auf dei Sprünge helfen könnte.


    Gruß,
    Jarv


    Edit:


    Ach ja. Installiert habe ich LCDproc als
    apt-get install lcdproc
    da ich ja nicht das vdr-plugin-lcdproc nutzen will, der VDR nutzt weiterhin vdr-plugin-graphlcd.