Posts by stl

    Liegt vermutlich an dem Patch den MLD für yaUsbIr verwendet. Dies ist nicht der neueste der hier veröffentlicht ist:
    yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter
    MLD: http://www.minidvblinux.de/svn-3/lirc/bra…a_usbirv2.patch


    Beim Selberbauen von lirc stell ich mich aber irgendwie ungeschickt an denn es klappt nicht nachdem ich die MLD Patches und den aktuellen yaUsbIr Patch angewendet habe.

    Code
    ..
    make[2]: Entering directory `/usr/local/src/lirc-0.9.0/tools'
    /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I..    -O2 -g -Wall -MT lirc_client.lo -MD -MP -MF .deps/lirc_client.Tpo -c -o lirc_client.lo lirc_client.c
    mv -f .deps/lirc_client.Tpo .deps/lirc_client.Plo
    mv: der Aufruf von stat für „.deps/lirc_client.Tpo“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
    make[2]: *** [lirc_client.lo] Fehler 1
    make[2]: Leaving directory `/usr/local/src/lirc-0.9.0/tools'
    make[1]: *** [all-recursive] Fehler 1
    make[1]: Leaving directory `/usr/local/src/lirc-0.9.0'
    make: *** [all] Fehler 2

    MLD fehlt zur Konfiguration von yaUsbIr auch noch das Kommando irsend; oder wo ist das versteckt?

    Gruß
    Stefan

    Hi,

    ich habe ein Problem mit yausbir. Aktuell verwende ich die angehängte lircd.conf unter MLD 3.0.2.
    Von den dort definierten Fernbedienungen erhalte ich nur von der Terratec TTS35AI eine Antwort - und auch
    das nur wenn ich mindestens 1 Sekunde lang eine Taste gedrückt halte. Die anderen Fernbedienungen
    generieren kein Ergebnis.
    Stelle ich auf den Treiber lirc_serial um und verwende den alten selbstgebauten Empfänger so funktionieren
    alle definierten Fernbedienungen mit sofortiger Reaktion auf Tastendrücke einwandfrei ;) .

    Die LED von yausbir flackert nur wenn eine Taste betätigt wird. Somit schließe ich ein Störtsignal aus.

    Hat jemand eine Idee worin das Problem bestehen könnte?

    Gruß
    Stefan

    Bin einen großen Schritt weiter :) .

    Durch den Upgrade in MLD-3.0.2 wurde in /boot zwar "initramfs -> MLD-3.0.2_initramfs-1.20.2_405.gz"
    aktualisiert, aber der neue Kernel nicht :( und somit paßte der Treiber der Karte nicht.
    Habe den Kernel manuell heruntergeladen und den Link entsprechend angepaßt.

    So sieht es jetzt aus:

    Code
    MLD> ls -l /boot
    lrwxrwxrwx    1 root     root            33 Mar  3 22:25 initramfs -> MLD-3.0.2_initramfs-1.20.2_405.gz
    drwxr-sr-x    2 root     root          4096 Dec 20 14:03 isolinux
    lrwxrwxrwx    1 root     root            33 Mar  4 21:48 kernel -> MLD-3.0.2_kernel-3.6.2.157_162.gz
    -rw-rw-r--    1 root     root       4717772 Mar  3 22:25 MLD-3.0.2_initramfs-1.20.2_405.gz
    -rw-rw-r--    1 root     root       3279328 Dec 20 13:53 MLD-3.0.2_kernel-3.6.2.151_151.gz
    -rw-r--r--    1 root     root       3611872 Mar  4 21:33 MLD-3.0.2_kernel-3.6.2.157_162.gz
    -rw-r--r--    1 root     root         12954 Dec 20 13:53 rootimg.gz

    Mit dem Nvidia-Modul stimmte wohl auch was nicht:
    [codde]jarada mld-3.0.2 # diff /data/cd_boot/MLD-3.0.2-sfs/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs etc/addons/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs
    Binärdateien /data/cd_boot/MLD-3.0.2-sfs/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs and etc/addons/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs sind verschieden.
    jarada mld-3.0.2 # cp /data/cd_boot/MLD-3.0.2-sfs/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs etc/addons/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs[/code]

    Das hatte ich manuell geladen: /data/cd_boot/MLD-3.0.2-sfs/MLD-3.0.2_kernel-3.6.2.157_xorg-nvidia-310.32_84.sfs

    Nachdem jetzt der passende Kernel gebootet wurde klappts auch wieder mit streamdev und ssh.
    Auch das eigentliche Thema kann als erledigt betrachten werden: NFS klappt :-))) .

    Code
    /dev/loop25               2688      2688         0 100% /var/spool/apm.mnt/network-drivers
    /dev/loop26              21120     21120         0 100% /var/spool/apm.mnt/xorg-nvidia
    none                      5120         0      5120   0% /run/lock
    none                   1035832         0   1035832   0% /run/shm
    192.168.192.4:/data/ 637514752 604568576  32946176  95% /mnt/data
    MLD>

    Gruß
    Stefan

    Ich kann leider noch nicht bestätigen das nfs jetzt läuft.
    Habe gerade ein Update in dem MLD 3.0.2 System gemacht und habe jetzt gar
    keine Netzwerk mehr zur Verfügung :-((.

    Die Fehler aus /var/log/messages lassen nichts Gutes erahnen.
    Vermutlich ist die Selbstzerstörung wieder aktiviert. Diese hat
    gestern mein MLD 3.0.1 System zerlegt (siehe fsck Protokoll).

    Gruß
    Stefan

    Der Eintrag in der fstab sah schon korrekt aus.

    Der Unterschied zwischen unseren Systemen ist:
    - ich versuche MLD-3.0.2 ans Laufen zu bringen
    - du hast nach deiner Signatur aber MLD-3.0.1.

    Jetzt habe ich auch mal ein MLD-3.0.1 Client aufgesetzt und siehe da: der kann NFS vom Server mounten :)

    Gruß
    Stefan

    Danke für die Antwort, aber den NFS-Server hatte ich erst später nachinstalliert in der Hoffnung das die Serverkomponente was enthält das dem Client fehlt.

    Beim Booten kommt noch ein:
    nfs-client seems to hang! continue now...


    Ein showmount -e SERVER_IP zeigt die vom NFS-Server exportierten Verzeichnisse an.
    Ich hatte das Verzeichnis auch per OSD ausgewählt.

    Beim Runterfahren des MLD Rechners gibt es bzgl. RPC ein paar Meldungen:

    rpcbind: cannot open file = /run/rpcbind/rpcbind.xdr for writing
    rpcbind: cannot save any registration

    Aber das ist m.E. nicht die Ursache.

    Gruß Stefan

    Bei meiner MLD Baustelle gehts langsam weiter.

    Code
    MLD> mount 192.168.x.y:/data/ /mnt/192.168.x.y__data/
    mount.nfs: Protocol not supported
    mount: mounting 192.168.x.y:/data/ on /mnt/192.168.x.y__data/ failed: Protocol not supported


    Das nfs Module ist aber geladen.

    Code
    MLD> lsmod
    Module                  Size  Used by    Tainted: P  
    nfs                    80538  0 
    dns_resolver            3148  1 nfs
    nfsd                  160468  4


    Die Addons nfs-client und nfs-server sind installiert.

    Auf den Server (192.168.x.y / gentoo) gibt es zu der Zeit keine Meldung.

    Gruß
    Stefan

    Ist die angegebene Version. Hab als yavdr-Neuling die entsprechende Info im Web-Frontend nicht gefunden.

    Hi
    hab ein Problem mit dem Erkennen des sundtek DVB-S2 sticks.
    Trotz LD_PRELOAD wird immer noch nach libmcsimple.so gesucht und nicht gefunden.
    Kann Jemand einen Tipp geben.

    Danke
    Gruß Stefan

    So da bin ich wieder.
    Hab bei mir schon die 2. Installation von USB-Stick auf USB-Stick zerschrotet. Das Bootfilesystem war bei fsck komplett hin.
    Auch bei einem Bekannten war das Rootfilesystem auf einer SSD sata ziemlich hinüber.
    Das passierte nach der Installation von Updates.
    Aber was da so alles nach einem fsck unter "lost+found" auftauchte ...

    Da eine Neuinstallation ziemlich schnell von der Hand geht ist das auch nicht so das Thema.
    Ist nur ärgerlich, für den Produktionsbetrieb ist das aber problematisch ;) .

    Der DVB-S Stick von Sundtek hat die USB ID 2659:1208 . Das mußte ich im script /etc/init.d/dvb-sundtek (oder so) anpassen.

    Mit Intelboards (bei mir und dem Bekannten) ruckelt das Bild sehr stark wenn beim Booten die Option "quiet" gesetzt war.
    "verbose" war notwendig um mit dem Default-Ausgabeplugin eine flüssige SD-Wiedergabe zu erreichen.

    Aktuell sind keine VDR-Plugins mehr auswählbar :( .

    Gruß
    Stefan

    Hi Claus, bei mir gibt es leider keinen Fortschritt. Beim Booten von CD ist das Ergebnis das Gleiche wie bisher. Das CD-Laufwerk wurde ja vor auch schon erkannt (siehe Screenshot oben PLEXTOR DVDR).

    Wer sorgt denn dafür, das das Label gelesen wird und unter /dev/disk/by-label zugreifbar ist?

    Gruß Stefan

    So hab nun noch ein paar Tests gemacht mit dem Ergebnis, daß von dem internen CD-Laufwerk via IDE -> SATA Adapter nichts läuft.
    Weder MLD-3.0.2 (2012.10.30_55) noch MLD-3.0.1 (2012.11.07_55 / 2012.07.19_46).

    Ob der Adapter die Ursache ist kann ich so noch nicht sagen. Müßte es noch mal mit einenm interen SATA Laufwerk versuchen.

    Bei Verwendung eines externen Laufwerks (BP40NS20) ging es über die genannte Hürde hinweg (MLD-3.0.2).
    Hatte dann aber noch ne andere Schwierigkeit die ich mir erst morgen noch mal genauer anschauen werde.

    Gruß Stefan

    Hi,

    wollte mal so eben schnell eine MLD Installation durchführen wurde aber durch die Meldung

    Code
    System device 'LABEL=MLD-3.0.2' not found

    ausgebremst.
    Installiert werden sollte auf einem 8GB USB-Stick (sda).

    Die Besonderheit hier ist das IDE CD-Laufwerk, welches über einen IDE -> SATA Adapter angeschlossen ist.

    Die CD basiert auf dem Standardimage ...2012.10.30... .
    http://www.minidvblinux.de/download.php?f…12.10.30_55.iso

    Kernel usw. sollten aber schon von CD geladen sein.
    Das CD Label stimmt soweit auch.

    Gruß
    Stefan

    Ist es möglich bei MLD die Suntek-Treiber wie von Sundtek vorgesehen unter /opt zu installieren?
    Aktuell funktioniert der sundtek client nicht (per default):

    Im mediaclient sind wohl Hardcoded einige Pfadnamen drin (von einem anderen Rechner):

    Code
    vdr@jarada ~ $ strings /opt/bin/mediaclient|grep mediasrv
    timed out reading confirmation from mediasrv
    /opt/bin/mediasrv -d --pluginpath=/opt/bin
    vdr@jarada ~ $

    Alternativ geht auch folgendes (und schon klappst mit dem Nachbarn):

    Gruß
    Stefan

    Danke für den Tipp.
    Yaepg war zwar per define aktiviert aber beim Aufruf nicht verwendet da es mit yaepg nur Segfaults ohne Fehlermeldung gab.
    Es fehlte der Teil des yaepg Patches für osd.c. Kommt davon wenn man das per Hand editieren muß.
    Der Patch ist halt für VDR-1.6.0 und mittlerweile gibts es kein dvbosd.c mehr.

    Hinzu kommt das im yaepg die Fehlermeldungen ohne ein "#define DEBUG 1" unterdrückt werden (#define YAEPG_ERROR(...)).

    Code
    Jul  8 10:57:58 bodega3b vdr: [4052] starting plugin: yaepghd
    Jul  8 10:58:07 bodega3b vdr: [4052] INFO: YaEPGHD: bool cYaepgTheme::Load(std::string): Loading theme: default
    Jul  8 10:58:07 bodega3b vdr: [4052] INFO: YaEPGHD: int cYaepgTheme::LoadImage(char*): Loading image '/usr/local/src/video/vdr-conf-1.7.28//plugins/yaepghd/default/bg.png'
    Jul  8 10:58:07 bodega3b vdr: [4052] ERROR: YaEPGHD: int cYaepgTheme::LoadImage(char*): Couldn't load /usr/local/src/video/vdr-conf-1.7.28//plugins/yaepghd/default/bg.png: Magick: no decode delegate for this image f
    Jul  8 10:58:07 bodega3b vdr: [4052] ERROR: YaEPGHD: bool cYaepgTheme::Load(std::string): Error loading image 'bgImage = default/bg.png'
    Jul  8 10:58:07 bodega3b vdr: [4052] ERROR: YaEPGHD: virtual void cYaepghd::Show(): Error loading theme default
    Jul  8 10:58:08 bodega3b vdr: [4052] INFO: YaEPGHD: void cYaepghd::SetTime(time_t): 1 gridEvents == NULL

    So mußte halt imagemagic nochmal übersetzt werden. Diesmal mit png support.

    Mit Nvidia-Vdpau als Ausgabemethode wird zumindest das Gesamtbild in dem Yaepg-Ausschnitt dargestellt.
    Bei Vaapi-Intel ist der Yaepg-Rahmen einfach nur drübergelegt und das Bild nicht im Ausschnitt skaliert.

    Danke.

    Gruß
    Stefan

    Manchmal kommt es vor, das das Menü das Videobild vollständig überlagert
    bzw. der Hintergrund schwarz dargestellt wird und das Alphablending nicht funktioniert.
    Wenn das passiert, tauchen im Log die "Flush:" Meldungen auf.

    Wenn die "slow down" Meldungen kommen, gibt es eine minimale Verzögerung im Bildaufbau
    beim Erscheinen des Menüs.

    Gruß
    Stefan

    Danke das wars :-)) .

    "emerge -DuNv world" ist zwar immer noch am laufen (jetzt mit qt-gui-4.8.1-r1)

    aber der VDR mit softhddevice läuft mit Bild und Ton :) .

    Die CPU-Last liegt bei öffentlich rechtlichen Sendern bei ca. 10% (lt. top).
    Mit softdevice und SD-Sendern lag sie vorher bei ca 55%.

    Dann müßte es also möglich sein mit so einer Karte für ca 60€ meinen anderen
    VDR-Rechner (mit Celeron P-III @ 1,2 GHz) HD tauglich zu machen.
    Na mal sehen.

    Vielen Dank

    Stefan