softdevice will nicht mit dummy Audiotreiber

    Ich habe mir heute zum rumspielen ein linvdr in qemu (Emulator) aufgebaut.


    Da ich in dem Emu natürlich kein DVB Device habe, benutze ich das sky Plugin.


    Nun will ich vdr mit dem softdevice Plugin starten.


    Mein Aufruf sieht so aus:
    vdr [...] -D2 -Psky -P "softdevice -ao dummy"


    Damit sollte es doch gehen.


    Leider bricht vdr das starten beim initialisieren des Softdevice Audiogerätes ab.


    Letzte Zeile ist
    [softdevice] Initializing Audio Out


    Im Logfile steht ganz zum schluß:


    [softdevice-audio] Opening elsa device default
    [softdevice-audio] Playback open error: default, No such device FATAL exiting



    Anscheinend versucht das Plugin trotzdem elsa zu laden.
    Ignoriert er das dummy device?
    Kann mir da jemand einen Tip geben?

    Nun habe ich es mal auf einem echten vdr mit dvb Karte versucht.
    Selbe Problem.
    Hier denke ich aber mal das es an den fehlenden audio treibern liegt.
    Es ist leider auch nur ein testboard.
    Ist irgendeine onboard soundkarte drinne.


    Es muß doch aber möglich sein das Plugin auch ohne soundkarte zu starten.

    Zitat

    Original von decembersoul


    Mein Aufruf sieht so aus:
    vdr [...] -D2 -Psky -P "softdevice -ao dummy"


    Schon mal mit:
    vdr [...] -D2 -Psky -P "softdevice -ao dummy:"
    versucht ?

    Ich suche mich jetzt schon ein paar Stunden vogelig, aber finde keine Antwort. Wie finde ich überhaupt mein "devicename" für das alsa device? Es scheint alles richtig konfiguriert, ich kann mit aplay wav Dateien abspielen und bei aplay -l

    Code
    **** List of PLAYBACK Hardware Devices ****
card 0: V8235 [VIA 8235], device 0: VIA 8235 [VIA 8235]
  Subdevices: 4/4
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
card 0: V8235 [VIA 8235], device 1: VIA 8235 [VIA 8235]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

    Ich habe diverse Kombinationen von Card 0, Device 0, via 8235, V8235, etc. verwendet. Mal zusammengeschrieben, mal mit Unterstrich, mal in Anführungszeichen. Nichts war richtig und ich finde auch keine Antwort darauf: wie komme ich an den device name den softdevice für das alsa-Modul erwartet?


    danke

    Hm, ich habe inzwischen herausgefunden, daß aplay -D sich mit den Devicenamen hw:0, hw:0,0 & hw:0,1 betreiben läßt - hw:0,2 funktioniert dagegen nicht. Das Softdevice akzeptiert aber jedes device, was ich ihm hier gebe - hw:0, hw:1,0, etc. - es funktioniert leider bisher mit keinem. Evtl. liegt es doch noch wo anders dran, daß der Ton noch nicht anläuft.

    Exakt.


    /usr/bin/vdr -L /usr/lib/vdr/plugins -P"softdevice -vo dfb: -ao alsa:hw:0,1 -L /usr/lib/vdr/plugins" -v /video0 -c /etc/vdr -w 900 -E /ramdisk/epg.data -s /usr/bin/poweroff.pl - der hängt wahrscheinlich vorher schon irgendwo, denn die CPU Last ist viel zu gering. D.h. er ist wahrscheinlich noch gar nicht im Decodiermodus..

    Ja, vdr läuft auf root.


    Sind das diese Devices:

    Ich hatte erst vermutet, daß es etwas mit dem lirc-Daemon zu tun hat, komme da aber auf keinen grünen Zweig (hat bisher hervorragend funktioniert und an dieser Komponente auch nicht geändert). Je nachdem ob ich mit /etc/init.d/runvdr up vorher oder nicht starte kommt jetzt in beiden Fällen der Aufruf zur Anlernung der Tasten - in erstem Fall steht LIRC als Überschrift, im anderen Fall (ohne runvdr up) softdevice-dfb welches zum Anlernen der Tasten bittet. Kann das softdevice irgendeinen Einfluß auf LIRC haben? Interessant ist evtl. noch, daß aus irgendeinem Grund 2 LIRCd gestartet werden:

    Code
    Apr 19 16:40:05 linvdr user.debug vdr[2248]: DFB remote control thread started (pid=2248)
Apr 19 16:40:05 linvdr user.debug vdr[2249]: LIRC remote control thread started (pid=2249, tid=10251)
Apr 19 16:40:40 linvdr user.err vdr[2249]: ERROR: lircd connection lost
Apr 19 16:40:40 linvdr user.debug vdr[2249]: LIRC remote control thread ended (pid=2249, tid=10251)

    und dies sind die Konsolenausgaben, wenn ich den VDR wie oben genannt starte. im Log steht im wesentlichen das Gleiche. Allerdings wartet er bei der letzten Ausgabe. Wenn ich beende mit strg+c, wird auch ins log geschrieben.


    Ist die Arbeit des softdevice zur initialisierung zu diesem Zeitpunkt bereits abgeschlossen oder wartet das noch auf irgendwas?


    BTW: Wenn ich versuche das PimaryDevice auf '2' statt '1' zu stellen, überschreibt er dies immer wieder mit 1.

    Soweit ich das verstehe muss (bei einer dvb) PimaryDevice auf 2 stehen.
    Kann man auch ganz gut in der /etc/vdr/setup.config (oder so) einstellen.
    Alternativ kann man natürlich vdr auch mit -D2 starten. Hat bei mir aber auch nicht gefunzt.


    Ich lese es mit interesse.
    Finde ich gut das Du dich da so reinhängst. Viele hätten schon aufgegeben ;D

    @Mr. Lugosi:


    Für mich sieht das alles in Ordnung aus... Was für DVB Karten hast du denn im System? Ist da eine FF-Karte dabei, dann kann das mit dem Primary device schon eine Rolle spielen.


    Funktioniert das Anlernen der Tasten richtig? Was passiert den genau nach dem Anlernen der Tasten?


    Du hast nicht die CVS-Version vom Softdevice, oder? Dann kannst du nämlich mal noch etwas debugging output im Softdevice einschalten, das Hilft vielleicht das Problem weiter einzukreisen. Editier einfach im Sourceverzeichniss des Softdevices die Datei mpeg2decoder.c und mach die beiden Slashes "//" vor der Zeile


    //#define CMDDEB(out...) ....


    weg. Dann neu kompilieren, nochmal starten. Jetzt solltest du neue Meldungen auf der Konsole bekommen, poste die bitte mal hier. Wenn nicht, dann wird das Softdevice nicht richtig vom Vdr angesprochen, sprich das Softdevice wird nicht als primary Device angesprochen.
    Poste doch auch mal die kompletten Logs des Starts vom Vdr, fällt jemandem hier ja noch was auf.


    Ansonsten, nicht aufgeben! Das sieht echt schon gut aus!
    Martin

    Vielen Dank schonmal für Eure Hilfe. Ich mache direkt heute abend weiter, aber muß jetzt mal eben zum Fußballgucken :)


    Das einzige was ich eben noch auf die schnell testen konnte, war daß es scheinbar keinen Unterschied macht, ob eine DVB Karte eingebaut ist oder nicht. Er hängt an der gleichen Stelle wie zuvor. Denke noch, daß es irgendwas mit LIRC zu tun hat. DirectFB kann man auch mit LIRC Support kompilieren, kann es damit evtl. Probleme geben? Jetzt muß ich aber weg, werde aber nacher nochmal die genaueren Infos nachschauen.

    So ganz viel Sinn kann ich aus einigen Dingen immernoch nicht machen. Es gab zwar ein Problem mit Lirc, was wohl mit dem neu gebauten Kernel zusammenhing, aber an Lirc hängt er jetzt nicht mehr. Auch das DVB Device scheint nicht das Problem zu sein, da das Verhalten - egal ob mit oder ohne DVB Karte oder welche ID das Primary Device hatte, im wesentlichen immer das Gleiche ist. Wenn ich mit softdevice starte hängt er an der oben genannten Stelle, wenn nicht läuft er durch und man kann alles benutzen.


    Ich vermute, daß noch immer etwas mit dem db nicht stimmt. Wenn ich fbset -i eingebe, kommt nur fbset: fbset(open): No such file or directory. Ich muß mit fbset -i -fb /dev/fb0 das konkrete device angeben - das ist nicht üblich, oder (war zumindest in bisher keinem Beispiel so)? Als Ausgabe bekomme ich dann:

    Code
    mode "800x600-60"
        # D: 41.601 MHz, H: 38.519 kHz, V: 59.999 Hz
        geometry 800 600 800 10483 16
        timings 24038 144 24 28 8 112 6
        accel true
        rgba 5/11,6/5,5/0,0/0

    Was ja prinzipiell schonmal ganz gut aussieht. Wenn ich dann VDR mit dem Plugin starte, verändert sich der Mode dazu:

    Code
    mode "640x480-75"
        # D: 31.499 MHz, H: 37.499 kHz, V: 74.998 Hz
        geometry 640 480 640 960 32
        timings 31747 120 16 16 1 64 3
        accel false
        rgba 8/16,8/8,8/0,8/24
endmode

    Hier noch die Ausgaben vom Starten des VDR

    Eine Veränderung, die ich zumindest so nicht nachvollziehen kann ist (!) DirectFB/FBDev/vt: FBIOPUT_CON2FBMAP failed! --> No such device An DirectFB habe ich aber nichts verändert, ebenso am softdevice - und diese Meldung tritt sowohl bei debug wie normaler Variante auf. Dies nochmal das log beim starten:

    Und ich habe jetzt mal sowohl die CVS, wie die normale Version probiert. Mit Debug und Ohne - ich konnte keinen Unterschied feststellen. Habe beide Zeile für Zeile verglichen - komisch. Ich glaube, daß es noch irgendwas mit dem Framebuffer zu tun hat. Zwischenzeitlich wurde der Bildschirm, wo ich die Ausgabe erwarte :), einmal komplett blau, aber das war es dann auch. Etwas was auf jeden Fall neu ist: der VDR hängt sich energischer auf - man muß über SSH rein um ihn zu killen und belegt den "ganzen Framebuffer" über alle Konsolen hinweg. Bevor diese "no such device" Meldung kam, war der komplett schwarze Framebuffer auf die Konsolen F5-F8 beschränkt. Jetzt ist alles schwarz und man kommt nur per SSH rein. Gleichzeitig ist die CPU Last aber bei nahe Null - er macht nichts, sondern wartet nur.


    Ich werde nochmal genauer nach dem Framebuffer schauen und evtl. mal versuchen mplayer mit DirectFB Support zu kompilieren - vielleicht bringt das ja neue Infos.


    Falls noch jemand eine Idee hat?

    Wenn vdr schon lirc support hat dann sollte directfb darauf verzichten. In /etc/directfbrc sollte dann die Zeile disable-module=lirc stehen. Wenn ich das richtig verstanden habe, dann hast du eine FF Karte. Da muß dann das Primary-Device umgesetzt werden. So war es zumindest früher mal, ansonsten war via softdevice nur ein OSD zu sehen.


    Stefan Lucke

    Ich probiere jetzt nochmal mit der FF Card herum, obwohl ich dachte das ich in der Richtung alles ausprobiert hatte (was Device Nummern, Parameter und überhaupt vorhandensein angeht). Der Tip mit dem Ausschalten des LIRC Moduls in DirectFB war in der Hinsicht schonmal sehr hilfreich, daß diese "no such device" Meldung wieder weg ist und er sich jetzt wieder normal mit strg+c killen läßt - keine SSH Verbindung nötig.


    Das positiveste war, daß sich MPlayer in wenigen Minuten zur Arbeit mit DirectFB überreden lies. Bild und Ton waren kein Problem und ein kurz getestetes Xvid mit voller NTSC Auflösung lief problemlos über DirectFB mit gerade mal 11% CPU Last (lt. top) auf meinem Athlon XP1800+. Werde auch gleich mal HDTV testen, aber dafür muß ich eben einen anderen Monitor einige Treppen hochtragen. Der kleine Diagnose Schirm schafft das nicht :)

    Also wenn MPlayer läuft, dann sollte das Softdevice auch zum laufen bewegt werden können. Ich frage mich nun wirklich wo Vdr stehen bleibt... Kannst du Vdr nochmal anwerfen und wenn er dann stehen bleibt gdb auftufen und dann mit "attach pid" mit dem vdr verbinden? Dann solltest du angezeigt bekommen was Vdr gerade macht, mit "backtrace" bekommst du auch noch angezeigt welche Funktionen er vorher aufgerufen hat.


    Alternativ kannst du auch vdr.c mit printfs vollpflastern und sehen welches printf als letztes angezeigt wird, das ist eigentlich ziemlich leicht, kannst du C? Wenn du noch immer experimentierfreudig bist kann ich dir auch mal eine Version vom softdevice schicken die jeden Aufruf protokolliert, so das man hoffentlich erkennen kann wo es hängt...


    Martin

    Also das mit dem Primary Device ist es nicht, da er nur eins findet und es dann wieder auf 1 zurücksetzt. Komischerweise.


    Den debugger werde ich mal dranhängen und schauen was bei rauskommt.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden