Posts by anbr

    Jan 6 18:35:04 odin vdr: [11253] ERROR: /vdr/services/vdr/current/PLUGINS/lib/libvdr-streamdev-server.so.1.7.35: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi


    => Das sollte doch im Makefile stehen, oder mach ich was falsch ? Bin ich der einzige der diesen Fehler hat ?
    -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE


    Zum Quick&Dirty-Kompilieren habe im streamdev-Plugin das Makefile, wie folgt angepasst

    Hier baut es auch erst nach folgenden "Hotfix" und nach eines Kopieren/Linken der Datei "gruel_common.i"



    #> ln -s /usr/include/gruel/swig/gruel_common.i /usr/include/gnuradio/swig/gruel_common.i
    Siehe auch http://www.ruby-forum.com/topic/4040797


    #> apt-get install gnuradio-dev libcppunit-dev libgnuradio-core3.5.3.2 swig
    #> autoreconf -i
    #> ./configure
    #> make



    @andr: rtl_fm funktioniert doch ganz passabel, wenn man -W für Wide FM mit angibt.


    Danke für den Hinweis, mein "Checkout" ist wohl zu alt gewesen, verantwortlich ist wohl der Commit vom 23.10.2012 (http://cgit.osmocom.org/cgit/r…7f186e19746658ade01632589)

    kann jemand etwas zu dem in Linux verfügbaren Noxon Treiber sagen? Lassen sich damit DAB Kanäle tunen, also bekommt man einen Lock auf den entsprechenden Frequenzen?


    Die regulär verfügbaren Kernel-Treiber unterstützen nur den DVB-T Empfang.


    Mit rtl-sdr kommt man aber an die Rohdaten des Frequenzspektrum, die der Tuner empfängt.
    Die UKW Dekodierung per rtl_fm (rtl-sdr) FM-Empfang funktioniert leider nur leidlich.
    Mit der multimode RX (GNU-Radio Skript) , sowie gqrx (Standalone GUI) über rtl_tcp (rtl-sdr) funktioniert der FM-Empfang per SDR ganz brauchbar.


    Ein funktionierende DAB+ Dekoder ist mir aber noch nicht über den Weg gelaufen.


    Per Google habe ich bisher nur eine Diplomarbeit für DAB (ohne Plus aber mit Quellcode) "http://www.zsn.zhaw.ch/fileadmin/user_upload/engineering/_Institute_und_Zentren/ZSN/Projekte/dab/Documentation.pdf" gefunden.
    Dort wird GNU-Radio als Framework verwendet, theoretisch müsste rtl-sdr nur als Frontend-Plugin geladen werden.



    Edit Vielleicht bietet das folgende GNU-Radio-Projekt einen Ansatz : https://www.cgran.org/browser/projects/dabp/trunk
    Es wurde aber seit 2 Jahren nicht mehr angefasst und letzter Checkin sagt nur "Testing. Not working yet. Aber es wird mplayer als dekoder verwendet.

    Quote

    this is to test the gr-dabp package for MSC
    to pipe to mplayer using
    ./app_dabp_msc -i subchid -n channel.conf infile | mplayer -ac faad -rawaudio format=0xff -demuxer rawaudio -
    this is to tell mplayer that this is a raw AAC (ADTS) audio stream and to use faad codec


    ....

    An meiner Dockstar hängt ein Pearl LCD. LCD4linux wird beim booten mitgestartet, so dass CPU etc angezeigt wird.
    Jetzt habe ich festgestellt, dass der LCD4linux-Prozess mindestens 12% CPU verbrät. Wenn ich zB ein File auf die dockstar kopiere, geht der Verbrauch sogar auf 30-40%% hoch (dann bleibt für smbd nur noch der Rest...)


    wenn ich einmal killall lcd4linux sage und es neu starte mit /etc/init.d/lcd4linux start, ist alles wie gewohnt, unter 2 %.
    Ich habe wheezy mit kernel 3.2.0-4 installiert.


    Hat jemand eine Idee, woran das liegen könnte?


    Ich weiß nicht, ob es das gleiche Problem ist, aber bei mir hatte der Timercode von LCD4Linux ebenfalls Probleme.
    Hintergrund bei mir, die Dockstar hat kein RTC. Damit startet die Uhr immer mit dem 1.1.1970 und wird erst Sekunden später
    per NTP aktualisiert, wenn das Netzwerk online ist. Der Orignalkode von LCD4Linux kommt aber mit einem so langen Zeitsprung
    nicht klar. Ich habe dies für mich, wie folgt behoben, den Patch aber nie Upstream für eine Review gesendet.


    Hi,


    irgendwie driftet das Thema ab, das Problem ist doch eigentlich das Schnittmarken (marks), die nicht auf einen I-Frame sitzen sich nicht mehr nachträglich bearbeiten lassen, hier sollte der VDR erst mal toleranter werden.


    Andreas

    Hi,


    ja, ist hier auch so, wenn die Schnittmarke nicht auf einem I-Frame liegt, lässt sie sich nicht verschieben.


    Das Problem ist aber schon alt, unter vdr 1.6 hatte ich mir mit folgenden Perl Script geholfen.


    Er verschiebt alle Marken auf das nächste I-Frame. (Aber kann halt nur das alte VDR-Format fixen)
    # cat /opt/vdr/bin/fixmarks.pl

    Soeben ist die DD Cine CT V6 bei mir eingetroffen. Beide Tuner sollen im reinen DVB-C-Modus gefahren werden. Bei SAT ist mir klar, dass hier üblicherweise jeder Tuner sein eigenes Kabel benötigt. Muss bei DVB-C und dieser Karte jeder Tuner mit einem Signal bestückt werden? Bei Kabel gibt's ja kein High/Low und horizontal/vertikal, so dass ein Verteiler durchaus schon auf der Karte integriert sein kann... Ein einfaches Ja/Nein reicht ;).


    BJ1


    Nein, nur der obere Antenneneingang muss angeschlossen werden, der unter Anschluß stellt eine "loop-through" Antennenausgang dar, über den weitere Karten versorgt werden könnten.

    Hi,


    ich kann nur eine für mich funktionierende Methode beschreiben :


    • Ich habe auf meine privaten regulären Webseite den CGI-Skript gemäß VDR-Wiki platziert.
    • Im DSL-Router ist ein Port-Forwarding eingetragen damit alle externen UDP-Pakete von Port 9 auf die interne Broadcast-Adresse 192.168.111.255 (Port 9) weitergeleitet werden.
    • Im VDR-Manager ist die zur regulären Webseite passende WakeUp-URL hinterlegt :


    • HWaddress=AA:BB:CC:DD:EE:FF durch die eigene MAC Adresse ersetzen


    Edith sagt : Falls kein eigener Webspace vorhanden ist, kann auch der Service von Stephan Mestrona genutzt werden : http://stephan.mestrona.net/wol/forum/viewtopic.php?t=923


    Es gibt aber viele Weg das Thema anzugehen,
    Andreas

    Das kannst per ldd überprüfen


    Code
    1. #> ldd /usr/local/bin/lcd4linux
    2. libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x40006000)
    3. libmpdclient.so.2 => /usr/lib/libmpdclient.so.2 (0x40019000)
    4. libm.so.6 => /lib/libm.so.6 (0x4002f000)
    5. libpthread.so.0 => /lib/libpthread.so.0 (0x400d7000)
    6. libc.so.6 => /lib/libc.so.6 (0x400f7000)
    7. librt.so.1 => /lib/librt.so.1 (0x40228000)
    8. libnsl.so.1 => /lib/libnsl.so.1 (0x40237000)
    9. /lib/ld-linux.so.3 (0x2a000000)


    Code
    1. #> dpkg -S /usr/lib/libmpdclient.so.2
    2. libmpdclient2: /usr/lib/libmpdclient.so.2


    => apt-get install libmpdclient2

    Du solltest dir die aktuelle Dev-Version aus dem Subversion Repository ziehen


    Siehe auch http://ssl.bulix.org/projects/lcd4linux/wiki/Download ab Subversion Repository
    bzw. http://ssl.bulix.org/projects/lcd4linux/changeset/1189/trunk?old_path=%2F&format=zip


    Seit http://ssl.bulix.org/projects/lcd4linux/changeset/1149 sollte sich das MPD-Plugin mit aktueller Software übersetzen lassen.


    In Richtung Pearl-dpf kann nicht weiterhelfen, das ich des Display nicht verwende.

    Hi,


    das Thema Module I2C-Core kannst Du ignorieren.


    Unter Debian ist es als Modul konfiguriert
    $ cat /boot/config-3.2.0-2-686-pae | grep CONFIG_I2C
    CONFIG_I2C=m


    Unter Ubuntu ist fest in den Kernel eingebaut.
    $ cat /boot/config-3.2.0-25-generic | grep CONFIG_I2C
    CONFIG_I2C=y