Beiträge von GPu

    Hi zeus-cu



    Ich denke, wenn bei aplay -l nur das Gerät 3 angezeigt wird, müsste in der asound auch "device 3" stehen?!


    Ich habe irgendwo gelesen, dass bei der GT210/GT220 eventuell auch "type plughw" in der asound.conf hilft.

    Ich konnte mein Problem mittlerweile lösen (ich hoffe dauerhaft).
    Hier eine etwas ausführlichere Info - vielleicht hilft es dem Einen oder Anderen.


    aplay -l lieferte bei mir mehrere Geräte (ids 3, 7. 8, 9) (s. mein Beitrag weiter oben)
    Von den devices produzieren (bei mir) aber nur die 3 und 7 eine Soundausgabe. Im Endeffekt lag hier das Problem.


    Wenn man über das Webinterface die Soundeinstellungen ändert, wurde bei mir (fast) immer das höchste device (9) in die config files geschrieben.
    Mit dem alten Kernel wurde device 7 genutzt und ich hatte keine Soundprobleme. - Keine Ahnung weshalb sich nun die 9 eingeschummelt hat.


    Mein Ziel war es jetzt, die devices 3, 8 und 9 loszuwerden.
    Dazu habe ich versucht in /etc/modprobe.d/sound eine passende probe_mask zu finden, die nur noch device 7 übrig läßt. Leider erfolglos.
    Was geklappt hat war, die Auswahl auf devices 3 und 7 zu reduzieren:
    Vorher: options snd-hda-intel enable_msi=0
    ---> devices 3, 7, 8, 9
    Nachher: options snd-hda-intel enable_msi=0 probe_mask=3
    ---> devices 3, 7


    Dann habe ich /etc/modprobe.conf nach /etc/modprobe (ohne .conf) kopiert. Weiss nicht ob das nötig ist, die Anregung dazu gab http://www.vdrportal.de/board/…?postid=914467#post914467.


    Da ich im Inet gelesen hatte, dass sowohl device 3 als auch device 7 für Stereo Sound funktionieren, habe ich es bei devices 3 und 7 belassen.


    reboot


    Im Webinterface den Sound auf "Analog" gestellt -> "Fehler"
    Im Webinterface den Sound auf "HDMI Stereo" gestellt -> "Fehler"
    Sound hatte ich bis hierhin immer noch keinen.
    Merkwürdig.....


    Habe mir daraufhin die Scripte unter /user/share/yavdr/events/change-sound angeschaut und die damit zusammen hängenden Config Files untersucht. Hier war überall das device 7 eingetragen wie es auch sein sollte.


    In /etc/xine/config und /etc/vdr-sxfe/config_xineliboutput wird "plughw:0,7" benutzt wohingegen in /etc/asound.conf typ hw gesetzt ist:

    Code
    pcm.!default {
            type hw
            card 0
            device 7
    }

    Ich erwähne das, weil in anderen Posts geschrieben wurde, dass es mit "hw" in der asound.conf nicht funktioniert, man "plughw" nutzen soll.


    Nochmal ein rebbot... und der Ton war da ... :)


    Ich habe danach allerdings nicht nochmal im Webinterface mit den Soundeinstellungen rumgespielt. Die Gefahr war mir zu groß wieder stundenlang nach dem Sound suchen zu müssen :)


    In den vergangenen Tagen ist mir bei der Fehlersuche irgendwann mal aufgefallen, dass die Konfiguration in /etc/xine/config und /etc/vdr-sxfe/config_xineliboutput unterschiedlich waren. In der xine Config war device 7, in der vdr-sxfe config war device 9 eingetragen. Wie / weshalb das passierte ... keine Ahnung.


    Das Ganze passierte auf einem Asus P5GC mit einer ZOTAC GeForce GT 240 ZONE Edition HDMI 1GB DDR3 128bit Heatsink.


    Und jetzt schalte ich den Fernseher aus und hole mir ein kühles Bierchen ... und hoffe, auch morgen noch Ton beim Fernsehen zu haben....

    Hi, habe auch keinen Sound mehr (GT240)
    Die oben beschriebenen Schritte habe ich alle durch, hat nicht geholfen.


    Das Sound Device an sich ist wohl ok, denn es gibt eine Soundausgabe bei
    # speaker-test -c2 -twav -Dplughw:0,7


    Ich weiss nun nicht mehr weiter.


    In Var/log/messages finde ich dieses hier, weiss aber nicht, ob es wichtig ist:


    Hier noch einige Configs und Infos die vielleicht helfen:

    Code
    root@noname:/home/benutzer# dkms status
    nvidia-current, 195.36.24, 2.6.32-22-generic, i686: installed
    nct677x, 1.0.1, 2.6.32-18-generic, i686: built
    nct677x, 1.0.1, 2.6.32-22-generic, i686: installed
    alsa, 1.0.23, 2.6.32-22-generic, i686: installed




    Wenn ich die Soundeinstellungen über das Webinterface ändere, schummelt sich in die asound.conf immer das device 9 rein, obwohl es doch eigentlich device 7 sein müsste???


    /etc/asound.conf

    Hi,


    nach dem BIOS Reset wacht das Board zumindest nach dem manuellen Setzen des Timers im Bios wieder auf.


    Jetzt muß ich nur noch klären, wie ich ihn Schlafen-lege.
    Unter Suse 9 mußte ich "einfach" in den Runlevel 0 booten, mit einer "0" als Kernel Parameter.


    In Suse 10 wird die "0" aber ignoriert (Runlevel 1-5 gehen ?!).
    Jetzt experimentiere ich mit dem Poweroff Kernel, habe aber in Erinnerung, daß es da mit diesem Board Probleme gab -- auch ein Grund weshalb ich mir Gedanken über einen Board-Tausch mache.


    Werde mich aber est im neuen Jahr damit beschäftigen können.


    Guido

    Hi


    nach der Umstellung von Suse 9 auf Suse 10 will mein Asrock K7VT4APro mal wieder nicht so wie ich will:
    Der NVRAM Wakeup funktioniert nicht (mehr) - seltsamerweise klappt auch der manuelle Wakeup übers BIOS nicht mehr... nein, im BIOS habe ich nix geändert.


    Jedenfalls bin ich mittlerweile ziemlich genervt von dem Teil und mache mir - parallel zur Fehlersuche - über einen Austauch des Boards Gedanken.


    Gibt es eine preisgünstige und problemlose Alternative zu dem K7VT4APro?


    Das Board sollte natürlich ohne Reboot mit NVRAM Wakeup neu starten.
    Außerdem sollten meine "alten" Komponenten einbaubar / vorhanden sein:
    - AMD Sempron 2200+ (Sockel A)
    - 128 MB DDR RAM (1 Streifen)
    - 2 P-IDE Kanäle für 1-2 HDD und 1 DVD
    - 1 AGP 3.3 V für Nvidia Grafikkarte oder Grafik on Board (es wird nur der Textmodus genutzt)
    - >= 3 PCI Slots f. DVB-S FF, DVB-S Budget, DVB-T Budget
    - Netzwerk on Board


    Grüße


    Guido

    Hi,


    habe das gleiche Problem mit meiner Hauppauge.
    Gugst Du hier


    Ich vermute es liegt am Treiber und/oder an der VDR Version (habe eine recht betagte 1.3.3).
    Du kannst ja mal hier suchen: Es gibt verschiedene Beiträge zu DVB-T und Treiberversion.
    Anscheinend funktionieren einige Treiberversionen nicht (richtig).


    Wenn ich etwas mehr Zeit habe, werde ich meinen VDR wohl mal auf eine neue Version bringen, bis dahin bleibt bei mir DVB-T wohl dunkel...


    GPu

    So, es scheint jetzt zu klappen....
    Hatte noch eine Idee...


    Da mein Kernel ja problemlos runterfährt ist der Power-Off Kernel (der irgendwie den Wakeup bei mir verhindert) ja eigentlich nicht nötig.
    Man kann dem Kernel auch einen Runlevel mitgeben - z.B. den Runlevel 0 so daß er automatisch runterfährt.... da


    Also die boot/grub/menu.lst onm diese Power-Off Variante erweitert:


    Die \boot\grub\menu.lst:


    Test 5: Wakeup mit reboot und boot in runlevel 0
    Um 16:15
    Grub "mitteilen", daß beim nächsten Boot bitte in Runlevel 0 booten
    Mit nvram-wakeup eine Aufwachzeit setzen, Rechner runterfahren
    # echo savedefault --default=3 --once | sudo /usr/sbin/grub --batch --verbose
    # nvram-wakeup --configfile=/etc/vdr/nvram-wakeup.conf -s `date +%s -d "Oct 24 16:45"`
    # shutdown -r now

    Rechner fährt runter, bootet, schaltet sich ab.
    Sollte um 16:40 aufwachen. - tut er auch :):):):):)


    Zur Sicherheit habe ich noch ein paar Timer abgewartet, ob das auch wirklich öfters klappt - tut es.
    Der Schutdown dauert so zwar länger weil das System erstmal bootet un in den Runlevel 0 fahren muß... aber das stört mich nicht. Hauptsache es klappt jetzt.


    Interessant ist vielleicht noch die nvram-wakeup.conf


    Weshalb das geht, obwohl addr_stat und add_day auf die gleiche Speicherstelle zeigen weiß ich nicht.....

    Nee, is klar.


    War auch nicht als Vorwurf gedacht.... es hat auch schon mit dem "nicht ins BIOS schreiben" nicht 100%ig funktioniert.


    Aber da die Aufwachzeit immer richtig eingetragen war habe ich halt mal ausprobiert, was passiert....


    Bleibt aber immer noch die Frage, was davon zu halten ist, daß addr_stat und addr_day auf die gleich Speicherstelle zeigen:


    addr_stat = 0x56 # but differs somewhere else
    addr_day = 0x56 # but differs somewhere else


    GPu

    Habe es ausprobiert.... sehr interessanter Effekt....


    Es scheint die Aufwachzeit zwar ins BIOS zu schreiben, aber der Timer ist nicht enabled.
    Außerdem macht der Rechner gelegentlich beim anschließenden Reboot ein Floppy-Seek (was ursprünglich abgeschaltet war) .
    Dazu gesellen sich gelegentlich auch noch Checksum Fehler....


    Würde also sagen, das dein Vorschlag so nicht funktioniert....

    Hi Leutzs,


    habe mit emeinem Board ein Aufwach Problem (s. http://www.vdrportal.de/board/thread.php?threadid=23912).


    Ich bin mir nicht sicher, ob die nvram-wakeup.conf so richtig ist. Vielleicht hat irgendjemand ja eine Erklärung:


    Über den guess-helper habe ich eine conf datei erhalten:


    Ich habe die "addr_stat = 0c6F" auskommentiert.


    Mich wundert, daß addr_stat und addr_day auf die gleiche Speicherstelle zeigen. Macht das Sinn?
    Lohnt es sich, mit dieser conf weiter zu experimentieren?


    GPu

    Hi Leutz,


    nachdem mein gutes altes Asus P3BF Board incl der CPU von mir gegangen ist mußte schnell Ersatz her.
    Um im preislichen Rahmen zu bleiben habe ich mir ein Asrock K7VT4A+ mit einem Sempron 2200+ und 128MB geholt.
    Der VDR lief (fast) auf Anhieb, leider habe ich jetzt Probleme mit dem Wakeup...


    Die Kiste wacht nicht auf.


    Durch die Suche im Board bin ich auf ein ähnliches Problem gestoßen:
    http://www.vdrportal.de/board/thread.php?threadid=3908&sid=&hilight=touch+AND+nvram
    ... verstehe aber nicht, was da genau die lösung war und wie ich das evtl. auch bei mir implementieren kann.


    Ich muß dazu sagen, daß mit dem P3BF und dem celeron da drauf alles prima funktionierte. Allerdings wurde dort mnicht mit "apm=off" sondern mit "acpi=off" gebootet. "acpi=off" führt aber beim neuen Board dazu, daß der Rechner sich nicht abschaltet sondern nur stehen bleibt.


    Habe mit dem guess-helper eine nvram-wakeup.conf erstellt, die zunächst nicht so ganz schlüssig war - es wurden auch Fehler im log aufgelistet.
    Habe die guess-nvram-module\nvram-wakeup.conf dann etwas verändert und in /etc/vdr/ abgelegt (s.u)
    Dann ging die Testerei los.....


    Test1: Wakeup ohne Reboot
    Um 13:49
    Mit nvram-wakeup eine Aufwachzeit setzen, dann Rechner runterfahren
    # nvram-wakeup --configfile=/etc/vdr/nvram-wakeup.conf -s `date +%s -d "Oct 23 13:54"`
    # shutdown -h now

    Der Rechner müßte also um 13:49 wieder aufwachen - tut er aber nicht...


    Test2: Wakeup mit Reboot (manuell)
    Um 13:55
    Mit nvram-wakeup eine Aufwachzeit setzen, dann Rechner ausschalten, Rechner manuell
    wieder einschalten (reboot) und noch während der HDD Erkennung wieder manuell ausschalten.
    # nvram-wakeup --configfile=/etc/vdr/nvram-wakeup.conf -s `date +%s -d "Oct 23 14:07"`
    # shutdown -r now

    Der Rechner müßte also um 14:02 wieder aufwachen - Tut er auch :)


    Test 3: Wakeup mit reboot Kernel
    Um 14:11
    Grub "mitteilen", daß beim nächsten Boot ein anderer - nämlich der Power-Off Kernel (Nr.1) zu benutzen ist.
    Mit nvram-wakeup eine Aufwachzeit setzen, Rechner runterfahren
    # echo savedefault --default=1 --once | sudo /usr/sbin/grub --batch --verbose
    # nvram-wakeup --configfile=/etc/vdr/nvram-wakeup.conf -s `date +%s -d "Oct 23 14:22"`
    # shutdown -r now

    Rechner fährt runter, bootet den Shutdown-Kernel und schaltet sich aus.
    Er müßte um 14:17 wieder anfahren. - tut er aber nicht :motz4



    Test 4: Wakeup mit reboot und HALT
    Um 15:45
    Grub "mitteilen", daß beim nächsten Boot ein HALT ausgeführt werden soll.
    Mit nvram-wakeup eine Aufwachzeit setzen, Rechner runterfahren
    # echo savedefault --default=2 --once | sudo /usr/sbin/grub --batch --verbose
    # nvram-wakeup --configfile=/etc/vdr/nvram-wakeup.conf -s `date +%s -d "Oct 23 15:57"`
    # shutdown -r now

    Rechner fährt runter, bootet in den HALT, schaltet sich sich aber nicht aus.



    Die Ausgaben der jeweiligen Programme waren unauffällig, keine Fehler.
    Speziell bei der Ausgabe der nvram Werte durch nvram-wakeup sah alles prima aus (die Zahlen stimmten)


    Was mache ich falsch bzw. wo ist mein Denkfehler....


    Hier noch ein paar Infos:
    - Suse 8.2
    - nvram-wakeup version 0.97 (beta) 2004/07/21


    Die nvram-wakeup.conf die ich benutze:


    Die \boot\grub\menu.lst:


    Hier die \root\guess-directisa\nvram-wakeup.conf:

    Im guess-error.log findet sich aber folgende Zeile:
    Couldn't guess checksum addresses (out of 5).


    Hier die \root\guess-nvram-module\nvram-wakeup.conf:

    Zitat

    Original von Dr. Seltsam
    mit was für eine Antenne empfängst Du?


    Ich habe zwei Antennen.
    Eines ist eine aktive "Stabantenne" von Technisat, das andere ist eine etwas anspruchvollere Antenne von Schwaiger "ZA 8730"
    (Wobei ich nicht weiß, wofür bei der Schwaiger die Stabantenne ist. Habe keinen Unterschied zwischen ein- und ausgefahren feststellen können ...)


    Gugst Du hier


    Die Daten der Schwaiger Antenne:
    Frequenzbereich: 47-862 MHz
    Verstärung: max. 30db (regelbar)
    Kabel: 2m


    Alternativ habe ich auch noch ein 1,25m langes Kupferkabel, 1.5mm² welches zumindest mit der Settop-Box ein Bild bringt .... daher darf ich behaupten, daß wir hier ein durchaus brauchbares Signal haben :)


    Nein, bei der Nova-T gibt es mit dem Kabel kein Bild....


    GPu

    Zitat

    krieg mal raus, wo die jeweiligen Senderstandorte sind, mit welcher Leistung sie ausstrahlen und in welchem Band.


    Kommt bei mir beides vom Feldberg - eventuell "schwappt" auch noch was von Wiesbaden / HoheWurzel rüber. Die Antenne ist aber Richtung Feldberg ausgerichtet.


    ARD kommt über Kanal 57, 762 MHz,
    Gr. Feldberg: 50kW (Rundstrahlung)
    Hohe Wurzel: 100kW (Richtsrahlung)


    ZDF kommt über Kanal 22, 482 MHz
    Gr. Feldberg: 50kW (Rundstrahlung)
    Hohe Wurzel: 100kW (Richtsrahlung)


    Mehr infos gibt es hier:
    http://www.lpr-online.de/dateien/technische%20Parameter.pdf


    Luftlinie zum Feldberg ca. 15 km (freie Sicht)
    Luftlinie zur Hohen Wurzel ca. 17 km (keine freie Sicht)

    Sooo, wieder ein paar neue Erkenntnisse.....


    Nachdem ich nicht weitergekommen bin was die Empfangsqualität angeht, habe ich den femon (v. 0.0.3a) installiert um mir die Signalqualität mal genauer ansehen zu können.


    ÜBERRASCHUNG !!!!!


    Jetzt habe ich sogar ein stabiles Bild beim ZDF, die ARD sender sind nicht stabil.... und das nur durch nur durch die Installation des femon ????!!!


    Beim ZDF ist STR=78% SNR=98%
    Bei ARD ist STR=78 aber SNR schwankt zwischen 0% und 90%


    Das macht irgendwie keinen Sinn.
    Ein Störsender wäre eine Möglichkeit, dann müßte die Settop-Box aber auch Probleme bei den ARD Sendern haben - hat sie aber nicht.


    Ich vermute
    daß es an dem Treiber oder sonst irgendwas im VDR liegt. Immergin ist die 1.3.3. schon betagt und vielleicht ist der Treiber einfach schlecht.


    Ich denke, ich werde mir eine neue Version installieren und schauen, was dann passiert....


    Nachtrag:
    Habe jetzt nochmal eine kleinere Antenne angeschlossen.
    Jetzt zeigen die ZDF Sender auch eine schwankende SNR (0%-90%) bei konstanter STR=76%.... kein Bild mehr.
    Dann habe ich die "gute" Antenne wieder angeschlossen, und was man erwarten würde - nämlich daß das Bild kommt - trat nicht ein.
    Vielmehr war weiterhin eine schwankende SNR auf allen Sendern zu beobachten - und natürlihch kein Bild.
    Die Schwankungen sind ziemlich stark. Innerhalb von 2s von 0 auf 100 und in weiteren 2s zurück auf 0.... wenn das mein Auto könnte ....



    GPu

    Nee, schon klar.


    Ich habe nur diese Fehlermeldung vorher nicht gesehen bzw. einfach übersehen.... ich bin noch Anfänger mit Linux und VDR, da kann sowas doch mal passieren.....


    Immerhin hat dein Tipp mich ja auch auf die richtige Spur gebracht. Als ich die Fehlermeldung gesehen habe, war mir klar, daß da noch was zu tun ist.


    Stand der Dinge ist nun:
    Ich bekomme jetzt schon Phoenix rein, aber mit einem extrem zerbröseltem Bild. Daher kann man die Karte wohl als funktionierend betrachten.


    Der Empfang ist aber deutlich schlechter als bei der Settop-Bo - die Nova-T benötigt also wohl ein besseres Signal als die Box.
    Bleibt also zu klären, ob eine Zimmerantenne bei mir für die Nova-T überhaupt ausreichend ist. Das were ich wohl die nächten Stunden rausbekommen.


    Danke jedenfalls für die Hilfe.


    GPu

    > Wenn du mal (jaaaaaa, ich weiß) die Boardsuche verwendet hättest..


    <kleinlaut>
    hab ich ja, aber wohl die falschen Suchbegriffe benutzt.
    </kleinlaut>


    das scan tool habe ich schon einmal von der Kommandozeile probiert, bin aber auf Fehlermeldungen gestoßen, die mir nix sagten. Dann bin ich bei anderen Beiträgen zum Thema DVB-T steckengeblieben.
    Werde das script aber mal ausprobieren und berichten.


    Habe eben aber noch eine Fehlermeldung in der var/log/messages gefunden, der ich erst noch nachgehen möchte:

    Code
    Oct 16 11:09:22 vdrgp vdr[3734]: Section handler thread started (pid=3734, tid=32771)
    Oct 16 11:09:22 vdrgp vdr[3730]: probing /dev/dvb/adapter1/frontend0
    Oct 16 11:09:22 vdrgp kernel: tda1004x_init: Unable to open firmware /etc/dvb/tda1004x.mc
    Oct 16 11:09:22 vdrgp vdr[3736]: tuner on device 2 thread started (pid=3736, tid=49156)
    Oct 16 11:09:22 vdrgp vdr[3737]: Section handler thread started (pid=3737, tid=65541)
    Oct 16 11:09:22 vdrgp vdr[3730]: probing /dev/dvb/adapter2/frontend0
    Oct 16 11:09:22 vdrgp vdr[3739]: tuner on device 3 thread started (pid=3739, tid=81926)
    Oct 16 11:09:22 vdrgp vdr[3740]: Section handler thread started (pid=3740, tid=98311)
    Oct 16 11:09:22 vdrgp vdr[3730]: probing /dev/dvb/adapter3/frontend0
    Oct 16 11:09:22 vdrgp vdr[3730]: found 3 video devices

    So, habe nochmal verschiedenes ausprobiert:



    1. Karte in meinen Windows PC reigesteckt, Software installiert, Antenne angeschlossen, Sendersuchluf.... tadaaaa ... Bild Karte funktioniert also.


    2. Karte wieder in den VDR rein ... nix ... ok, war auch nicht zu erwarten.


    3. Andere Antenne (mit bis 30db Gewinn/Verstärkung, regelbar) an die Settop Box angeschlossen, ausgerichtet und Pegel eingestellt.


    4. Antenne so an den VDR angeschlossen - nix .... auch durch Verstellen des Pegels keine Verbesserung. Absolut tote Hose, noch nicht einmal irgendwelche kurzzeitigen Klötzchen.
    ;( ;( ;( ;( ;(
    Könnte es an der VDR oder der Treiberversion liegen?
    Wie kann man das ggf. herausfinden (ohne ne komplett neue Installation zu machen)?


    GPu

    Hi Leutz,


    ich bin ratlos.....
    Jetzt gibt es bei mir DVB-T und ich kann es mit einer Settop-Box prima empfangen (aktive Tischantenne, Stabantenne).
    Leider empfängt der VDR nix (Version 1.3.3).


    Der VDR läuft auf einem P-III-700 mit 128 MB RAM, Ausus P3Bf. Eingebaut sind:
    Karte 1: Siemens FF DVB-S
    Karte 2: Hauppauge Nova-T (die alte Version mit dem Philips Tuner)
    Karte 3: Hauppauge Nova-S und
    Ich bekomme das DVB-T Signal vom Feldberg/Ts, der ca 15km Luftlinie entfernt liegt.


    Die DVB-T Karte wird wohl gefunden und initialisiert.
    Jedenfalls kann ich sie prima ansprechen.Man kann auf die Sender schalten, der OSD sieht gut aus nur das Bild fehlt.


    Gibt es irgendwelche Erkenntnisse ob diese Karte Probleme mir schwachen Antennensignalen hat oder gibt es irgendwas was ich übersehen habe?
    Im Notfall werde ich die Karte mal under Windows ausprobieren müssen,,, :(
    Hier ein Auszug aus der Senderliste:

    Code
    > Das Erste:762000:I0C23D12M16B8T8G4Y0:T:27500:101:102:104:0:1:8468:10242:0
    > Phoenix:762000:I0C23D12M16B8T8G4Y0:T:27500:301:302:304:0:3:8468:10242:0
    > ZDF:482000:I0C23D23M16B8T8G4Y0:T:27500:545:546,547;559:551:0:514:8468:514:0


    Die Frequenzen sind identisch mit den Werten, die mir die Settop-Box liefert
    Das Erste: Ch57, 762000, 8k, 16Quam, 1/4
    ZDF: Ch22, 482000, 8k, 16Quam, 1/4
    Für beide Sender bekomme ich eine
    Signal Strength >70 und eine Signal Quality >70 (von je 100 möglichens) angezeigt.


    Hier ein Auszug aus der var/log/messages:
    Erst auf ARD geschaltet (#41 DVB-T) , dann weiter nach Phoenix (#42, DVB-T)


    Hier ein Auszug aus der var/log/messages vom Hochfahren des Systems


    gpu