Posts by shh

    Hallo,
    ich habe ein Verständnisproblem. Wenn ich mir diese Grafik ansehe, gibt's zig Wege IR-codes irgendwie "erkennen" zu können:
    http://www.yavdr.org/documentation/0.5/de/ch02s03.html


    Nun kann man udev-rules erstellen, damit beim Anstecken des USBasp-IR-Geräts der irmplircd geladen wird. Eigentlich ist das jedoch umständlich, da man extra nen extra dämon kompilieren und laden muss. Evtl. auch noch cross-compile und fürs OpenELEC-image sowieso total umständlich. :(


    Der USBasp erstellt mir ja schon ein hidraw-device. Kann man da nicht irgendwo ne .map erstellen, dass das System LIRC-events zu hören bekommt?
    Warum hört mein System keine LIRC-events vom hidraw-dev? Tastatur-hid-events kommen ja auch durch!?
    "Irgendwie" scheinen da ja schon etliche Protokolle und IR-Empfänger implementiert zu sein, ich verstehe aber nicht wie das System die Codes letztlich "bekommt", bzw ausführt.
    Blickt da jemand durch?


    Eine weitere Frage ist, warum der USBasp+IR-Empfänger sich nicht gleich als event-dev anmeldet. Wäre da ein extra kernel-modul nötig?

    Hallo,
    habe auch einen Empfänger auf USBasp-Basis aufgebaut.
    - nur USBasp mit Atmega8A aus Hong Kong von hier: http://www.ebay.de/itm/310506909410?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
    - TSOP direkt verbunden (Spannungsstabi über RC-Glied dürfte bei USB-Power überflüssig sein) an SCK/Pin7 der 10-Port Buchse.
    - main.hex mit arduino und auch einem anderen USBasp geflasht. verify war ok.
    - FUSES auf 0xC9 und 0xEF


    Damit wir unter Linux ein hidraw0 erstellt und lsusb zeigt mir das Gerät auch an.
    Wenn ich auf verschiedene Fernbedienungen drücke flackert die grüne LED, die rote ist dauerhaft an.
    ABER:
    cat /dev/hidraw0 bringt NICHTS!


    Daher kann irmplircd, irw etc. auch nichts mehr anzeigen.
    Was stimmt denn hier nicht?


    NACHTRAG:
    Mmm, Kommando zurück. Auf einem "richtigen" Rechner mit Debian 7.0.5 live-CD ging's jetzt.
    Kann es sein, dass ein Laptop am USB-Port zuwenig Strom liefert?!


    NACHTRAG2:
    OK, ich bin doof. :(
    hidraw0 war das device der Maus, nicht vom USBasp. Ergo: geht auch am Laptop, wenn man das richtige hidrawX erwischt.


    Gibts eigentlich schon ein plugin für OpenELEC?

    Klar, geht die unter OpenELEC, hab ich doch in dem Thread bei den OpenELECs drüben beschrieben.
    Ich hab allerdings keine Lust, das nochmal groß auszuführen - meine Probleme mit dem Empfänger haben auch keinen interessiert.
    Nur soviel: Patchen + Kompilieren ist nötig, außerdem muss der patch an den aktuellen OpenELEC angepasst werden. Am besten mit meinem patch anfangen, ich musste etliches anpassen. Build-System anpassen ist nicht mehr nötig.
    Siehe: http://openelec.tv/forum/103-i…or-yausbir?start=15#79426


    Hier mal mein aktuelle howto:
    0. Dev-System einrichten: http://openelec.tv/forum/12-gu…nelec-distro?limitstart=0
    1. lirc-0.9.0-030-ya_usbirv3.patch nach
    ~/OpenELEC.tv/packages/sysutils/remote/lirc/patches/ kopieren
    2. ir-toy patch löschen!
    3. bauen:
    PROJECT=ION ARCH=x86_64 make release
    4. SYSTEM + KERNEL nach \Update auf dem OpenELEC und updaten lassen


    ANPASSUNGEN am OpenELEC:
    1.
    2. Lircmap.xml nach \Userdata
    3. autostart.sh nach Configfiles
    4. lircd.conf nach Configfiles
    5. remote.conf nach Configfiles


    das denke ich nicht, die Seite 5 (siehe unten) ist bei allen Modellen identisch.


    Hast Recht. Das Datenblatt zum TSOP17xx liest sich dazu etwas ausführlicher. Die Funktionsweise ist anscheinend gleich. Beide haben einen Bandpass filter und eine auto gain control, wenn Störungen erkannt werden.
    Leider habe ich aber keinen TSOP34838 um prüfen, ob nun wirklich keine Unterschiede beim Empfang festzustellen sind.


    Quote

    IR-Filter bauen


    Quote

    wiki:...Wir kaufen uns also einen Diafilm und geben diesen unbelichtet(!) zur Entwicklung


    Öhm... Ja. ?(
    Ist sicher einen *Versuch* wert, dafür aber eigentlich zu umständlich und zu teuer: Stattdessen könnte man sich die ganze Palette an TSOPs bestellen und damit etliche Versuche starten. ZB mit dem TSOP34438, der nen stärkeren Filter hat.
    Das Problem ist ja eigentlich, dass der TV anscheinend tatsächlich IR-Rauschen produziert, das trotz Bandpassfilter und AGC durchkommt. Wahrscheinlich durch die Hintergrundbeleuchtung des TVs, weil's ja auch bei schwarzem Bild so ist. Ich verstehe jetzt nicht, was da ein IR-Filter helfen soll.


    NACHTRAG1:
    Hab den TSOP jetzt in eine alte FB gesteckt mit tiefdunktem Kuststoff vorne an der IR-Sendediode. Müsste auch ein IR-Filter sein, oder?
    Jedenfalls: Keine Änderung, gleiches Geblinker.


    Quote

    Erstaunlich ist aber, das andere Empfänger bei diesem Pegel nicht zugestopft werden.


    Ja, allerdings. Irgendwas müssen die besser machen. :] Denn qualitativ hochwertigere Empfänger bauen die bestimmt nicht ein. Und zwei meiner Billiggeräte haben exzellentes Empfangsverhalten: Da kann ich auch mal "irgendwo an die Wand schießen" - kommt trotzdem an.
    Ich gehe davon aus, dass die Empfänger da schon gezieht nach Protokoll filtern. Also das µC-Programm selbst, das nach NEC, oder RC5 filtert. Einfach *alles* anzunehmen, was der TSOP ausspuckt, kann nicht gut sein, wie man sieht.
    Störungen könnten zwar auf Software-Ebene von LIRC gefiltert werden, LIRC macht das ja eigentlich via lircd.conf, fatal ist aber, dass da irgendwas zu lange dauert. Der µC blockiert anscheinend, weil beim grünen Blinkern einfach keine anderen gültigen Signale meiner Fernbedienung mehr angenommen werden.
    Irgendwas dauert also zu lange. Entweder die µC-Verarbeitung der TSOP-Pulse, oder die USB-Kommunikation (mit LIRC). Komisch dass dabei auch der tolle USB2.0 C8051F387 nix hilft. :(


    NACHTRAG2:

    Sowas zB ist sporadischer "IR-Müll" wenn ich den Empfänger verstecke (sodass ich ihn mit meiner IR-Bedienung nicht mehr erwische).
    Das grüne Geblinker ist übrigens unregelmäßig gewesen, im Gegensatz zu den const anmutenden space 425971. Die Anzahl der space/pulse-Erkennungen von mode2 dürfte der Zahl der grünen Geblinker entsprechen (ich kann das nicht genau sagen, weil ich zwischen den Zimmern hin- und herflitzen muss).
    Komisch ist, dass mode2 nach einem erneutem Start 5min(!) später total voll ist, d.h. alle gesammelten space/pulse ausgibt. Hmm... Das Puffern von Signalen 5min lang kann eigentlich nicht gut sein - machen das alle Lirc-Module so?
    Bei Drücken der FB-Knöpfe hab ich übrigens kurze space-Werte und "beliebige" pulse-Werte (ich war jetzt zu faul nachzuschauen, was die Werte bedeuten).

    Der USB-Port dient doch beim RasberryPi zur Spannungsversorgung.
    Der yaUsbIR benötigt "laufend" 5V irgendwoher.
    Beim Einschalten (= wenn yaUsbIr einen bestimmten IR-Code erkennt) schließt er zwei Pins kurz, was am PC so funktioniert, wie wenn man den Power-Knopf drückt.
    Also NEIN: Der yaUsbIr schaltet nicht den USB-Port oder die 5V-Leitung zur Spannungsversorgung, er gibt nur einen Impuls. Willste schalten bäuchtest du n Relais.

    Danke hepi. Die Beiträge bestätigen aber leider nur meine Beobachtung. Ich muss also meinen TV verschrotten, oder den IR-Empfänger so verstecken, dass ich ihn selbst nicht mehr erreiche? Ist leider keine Lösung.
    Dieses Problem hat _kein_ anderer Empfänger _irgendeines_ meiner Geräte: VCR, SAT-Box, TV, Media-Player, Receiver, ... usw. Die alle schaffen das, dass der IR-Empfänger bei dem IR-Rauschen - in irgendeinem Band - trotzdem noch funktioniert und dabei gültige RC-Signale nicht blockiert.


    Wenn das denn kein mechanisches Problem ist (TSOP34838 ist der Nachfolger vom TSOP1738 soweit ich das verstanden habe, vielleicht hat der nen besseren Filter), so ist das ein Softwareproblem. Denn einerseits blockiert yaUsbIr Gerät anscheinend bei "IR-Müll", andererseits werden anscheinend auch "unmögliche" RC-Signale weitergeleitet.
    Ich weiß ja nicht, wie die firmware aufgebaut ist, aber vielleicht könnte man solche Störungen auch softwaremäßig ausmerzen.
    zB:
    - Standardfilter, der meine Peaks rausfiltert/ignoriert. Die Störungen sind aber je nach TV-Helligkeit, Umgebungslicht, Lampenverwendung wahrscheinlich schwer zu identifizieren...
    - Puffer implementieren (ist wahrsch. eh schon drin, um die USB-frames zu füllen) und die Empfangsdaten auf _gültige_ Protokolle filtern. Ich bin eigentlich davon ausgegangen, das sowas schon drin wäre. :(
    Es müsste relativ einfach sein, auf gültige Start-Codes der bekannten Protokolle zu prüfen (RC5,RC6, Denon, NEC, Sony, ...).
    Siehe: http://www.mikrocontroller.net…otokolle_Diplomarbeit.pdf
    Protokolle exotischer Trägerfrequenzen werden wg. 38kHz Vorgabe eh nicht benötigt. Bzw. hat man eigentlich immer eine programmierbare Fernbedienung, die RC5 oder NEC kann, die man entsprechend für den yaUsbIr anlernen kann. Ich sehe keinen Anwendungsfall, wo der yaUSBIr unbedingt auf irgendein exotisches Privatprotokoll hören müsste.

    Hallo,
    hab jetzt mal Zeit gehabt, die yaUSBIrV2-Platine einzurichten.
    Ich habe eine mit großem IR-Empfänger bekommen, der TSOP1738 müsste das sein. Kabel waren auch fix und fertig dabei.


    Schalte ich den TV, fängt yaUsbIr ununterbrochen "schnell grün" zu blinken an. Dabei werden dann keine IR-kodes meiner Fernbedienung mehr erkannt:


    Wir haben hier einen "normalen" 52" Samsung TFT TV ohne LED Hintergrundbeleuchtung.
    Dieses IR-Rauschen empfängt der TSOP fast überall im Zimmer. Kommt mir fast unmöglich vor, anscheinend reagiert der auch auf die ganzen Reflektionen der Wand. Reagiert übrigens auch, wenn der TV "total schwarz" ist.
    Jedenfalls muss ich den Empfänger total verstecken, damit das Blinken aufhört. Dann ist aber - natürlich - das Teil mit der normalen Fernbiedienung nicht mehr zu erreichen.


    Tja, was tun?
    Ist der 1µF C3 zu klein, oder auf den TSOP34838 ausgelegt, sodass das hier nicht ordentlich läuft?

    Files

    • IR-Rauschen.txt

      (20.06 kB, downloaded 147 times, last: )

    Also...
    Lösung1 (mit LIRC):
    Eine Datei in /usr/share/X11/xorg.conf.d erstellen, zB eine 11-evdev-tevii-s480.conf mit folgendem Inhalt:

    Code
    1. Section "InputClass"
    2. Identifier "Ignore the two IR devices"
    3. MatchProduct "IR-receiver inside an USB DVB receiver"
    4. Option "Ignore" "true"
    5. EndSection


    Damit werden beide devices unter X ignoriert.
    Dann via dpkg-reconfigure lirc LIRC auf die Linux input layer setzen, dann ein Gerät via by-path auswählen.


    Es gibt auch eine Option MatchDevice, die man oben einsetzen könnte, um bestimmte Geräte zu identifizieren. Z.B.:

    Code
    1. MatchDevice "/dev/input/event5"


    ginge also, allerdings ist das unsinnig, da sich die event-device-Nummern ja je nach angesteckten Geräten verändern.
    Die by-path-devices, wie hier zB /dev/input/by-path/pci-0000:02:00.3-usb-0:1-event-ir gehen leider nicht, wegen einem bug in X (zB-> http://lists.debian.org/debian-x/2011/11/msg00197.html ). X erkennt da nämlich keine Symlinks, obwohl die bei udev mittlerweile verpflichtend sind. :(


    Lösung2:
    Ein event-device ignorieren. Hier hat man allerdings das Problem, dass beide devices bis auf den PCI-Pfad exakt gleich aussehen (siehe cat /proc/bus/input/devices)
    Man muss den devices erstmal einen eindeutigen Namen geben, damit X dann ein bestimmtes device sperren kann.
    Ich habe hier event4 und event5, von denen ich event5 sperren möchte. Meine Karte steckt im PCIe-Port eines ASRock A330ION. Bei euch müssen die PCI-Adressen evtl. angepasst werden.


    1. Erstmal den Adresspfad nachschaun und die Adresse von ATTRS{phys} notieren:
    udevadm info -a -n /dev/input/event5


    2. Eine Datei erstellen: /etc/udev/rules.d/66-xorg-tevii-ir-quirks.rules
    Es wird den physischen PCI-devices ein bestimmter tag zugewiesen

    Code
    1. ACTION!="add|change", GOTO="xorg_tevii_ir_quirks_end"
    2. KERNEL!="event*", GOTO="xorg_tevii_ir_quirks_end"
    3. # Set some ID_INPUT.tags for the IR-devices
    4. ATTRS{phys}=="usb-0000:02:00.1-1/ir0", ENV{ID_INPUT.tags}="tevii_ir0"
    5. ATTRS{phys}=="usb-0000:02:00.3-1/ir0", ENV{ID_INPUT.tags}="tevii_ir1"
    6. LABEL="xorg_tevii_ir_quirks_end"


    3. udev aktualisieren via:
    udevadm test --action=change /devices/pci0000:00/0000:00:0c.0/0000:02:00.1/usb2/2-1/input/input4/event4
    und
    udevadm test --action=change /devices/pci0000:00/0000:00:0c.0/0000:02:00.3/usb3/3-1/input/input5/event5
    Dann sieht man ganz unten schon den neuen tag:

    Code
    1. ...
    2. ID_INPUT.tags=tevii_ir1


    4. Eine Datei erstellen: /usr/share/X11/xorg.conf.d/11-evdev-tevii-s480.conf
    (das MatchProduct ist eigentlich nicht nötig)


    So wird dann event5 von X zwar noch erkannt, aber nicht mehr als keyboard-device via xinput hinzugefügt.
    Es ist also nur noch ein event-device für den IR-port der Karte aktiv. :)

    Guten Morgen Albert,


    > Stellst Du immer die falsche Fragen? Wie jung sollte es heißen.


    Wie, die falsche Fragen? Entschuldige! Meins war grammatikalisch korrekt; man fragt nach dem Alter, nicht nach der Jungheit.


    Nö, Albert, das Problem mit der DVB-Karte (nicht FB, wenn du den Beitrag gelesen hättest), habe ich noch nicht gelöst.
    Aber du darfst diesen thread gerne ignorieren, wenn du keine Ahnung hast - gerade vor solchen Leuten ist man ja nie gefeit.

    [Schmunzel]
    > Du IT!? Dann spiele ich mal den IT-Babysitter


    DU aber auf jeden Fall, oder? Wie alt bist du eigentlich? :)
    Aber, kein Problem, ich kann gerade auch nicht schlafen, und die Kinder sind im Bett - OPTIMAL um Sachen neu einzurichten...
    - und du weißt GENAU was man von solch passenden Kommentaren gebrauchen kann...


    p.s.
    BOAH: posts nachträglich bearbeiten is fies!

    Hi Kurt, danke für die Antwort!


    Oje das ist ja sehr ernüchternd! :(
    Die doppelte Ausgabe an die zwei event-devices ist ja im Grunde ein firmware-Fehler. Es ist sowieso lächerlich, dass bei einem IR-Port zwei event-devices angemeldet werden. Die letzte Firmware ist aber so alt, dass man aber nicht auf Bereinigungen hoffen kann...


    Wie man best. X-hotplugging-Regeln abzuschalten kann, ist mir völlig unbekannt - deshalb die Frage.
    Allerdings ginge es natürlich auch mit best. udev-Regeln, das event5 zum Schweigen zu bringen. Die Karte hängt ja immer an demselben PCIe-xyz-00123-Bus und müsste sich (teilweise) sperren lassen.


    Hast du einen Link zu den udev-threads, wo udev-Regeln bzgl S480 diskutiert wurden? Ich habe mittlerweile soviel Irrelevantes gelesen, ich habe keine Ahnung, wonach ich suchen soll...


    p.s.
    Ich hab jetzt erst gesehen, dass du auch eine S480 hast. Ich habe eine v2.1, mir ist aber nicht klar, was da "neuer" ist. Hattest bzw hast du mit der mitgelieferten FB dasselbe Problem wie ich?

    Ubuntu 11.10, Kernel 3.0, xorg-server 2:1.10.4-1ubuntu4.2


    Karte: TeVii S480, doppel DVB-S2, ein IR-Stecker hinten, aber 2(!) event-devices dafür


    Hallo,
    bin mir nicht sicher ob dies schon gelöst wurde - für mich jedenfalls noch nicht. Alles was ich diesbzgl über "doppelte" codes gelesen habe hatte immer etwas mit "zuviel" codes der Fernbedienung (FB) zutun, also nur eine zu hohe repeat- bzw die Aufnahme-Rate.
    Das Problem hier:
    Die TeVii S480 hat einen IR-port hinten, wo ich den mitgelieferten Empfänger eingesteckt habe. Die mitgelieferte FB funktioniert damit wunderbar. Das kann man zB testen, wenn man LIRC auf das kernel-event-dev konfiguriert und dann mit irw testet.
    LIRC habe ich aber wieder abgeschaltet, sonst hätte ich unter X 3(!) Eingaben derselben Fernbedienung.

    Code
    1. evtest:
    2. No device specified, trying to scan all of /dev/input/event*
    3. Available devices:
    4. /dev/input/event0: Power Button
    5. /dev/input/event1: Power Button
    6. /dev/input/event2: AT Translated Set 2 keyboard
    7. /dev/input/event3: Logitech Logitech USB Optical Mouse
    8. /dev/input/event4: IR-receiver inside an USB DVB receiver
    9. /dev/input/event5: IR-receiver inside an USB DVB receiver


    Jetzt ist's so, dass beim Drücken auf die FB die IR-codes einfach an beide(!) event-devices (event4 und event5) gesendet werden.
    X erkennt wegen udev und hotplugging diese 2 Eingabegeräte und nimmt somit immer doppelte Eingaben an. :(
    Wie kann man X dazu bringen, dass zB /dev/input/event5 einfach ignoriert wird?


    dmesg-Auszug:


    Xorg.0.log:


    xorg.conf:

    Vielen Dank für eure Einschätzungen!


    Kompilier- und Bastelprobleme gibt's hier nicht. Ich hab hier ewig schon alles mögliche Linux-Zeugs laufen (ab SuSE 4.2 1996, später dann Debian und Konsorten, ab potato). Ich hab' nur nicht viel LUST mir alle möglichen patches zusammensuchen zu müssen, und damit dann quasi das ganze System nochmal zu übersetzen (Kernel, xorg, vdr + plugins). Hab ich zwar auch schon alles gemacht, ist aber NICHT LUSTIG, und eigentlich hab ich auch keine Zeit mehr dafür.


    Hmm, wenn alles andere irgendwie nix ist, dann halt doch NVidia.


    Ich habe jetzt mal was gewagtes zusammengewürfelt.
    - ohne die PCI-Slots zu erhalten. Da ich eh ein neues Netzteil brauche, ist es nicht unbedingt sinnvoll mein altes Riesengehäuse zu erhalten.


    - ASRock A330ION (das hat nur featureset B), kostet aber nur 100,-
    - Digital Devices Cine S2 - Duale DVB-S2 HDTV (Rev. V5.5): 150,-
    - 1-2GB (normales) DDR3 RAM
    - Lüfter
    - 3,5" WD EARS
    ...und Achtung, jetzt kommts... hier reinbauen:
    ITX LC-Power LC-1300mi, 75W, Mini-ITX: 36,-


    Kritische Punkte:
    - Einbauhöhe der DVB-Karte (Löcher bohren müsste ich sowieso)
    - 75W Netzteil :D


    Fragen:
    1. gibt's außer dem featureset B grundsätzlich am Board (bzw A330, ION1) etwas auszusetzen?
    2. gibt's irgendwo Maße zu der DVB-Karte?
    3. Wie knapp sind 75W für's Netzteil? :D
    4. gibt's irgendwo Infos darüber, wie lange die DVB-Karte zum laden/entladen der Module braucht? Oder ist obige Karte vielleicht sowieso Mist?

    Tja, die Lotterie...
    Die kenne ich doch! Ich hatte ja gehofft, dass Ihr mir die Wahrscheinlichkeiten etwas drücken könnt... ;)


    Wobei Platte+CPU eher sekundär sein dürfte. Wenn das BIOS 10sek für [irgendwas] prüfen braucht, kann wohl kaum ein Linux-System den Zeitverbrauch irgendwie wieder nivellieren.
    ...soll heißen, dass ich immer noch Erfahrungswerte benötige.

    Oje, das ist eigentlich das, was ich befüchtet habe (und VIELEN DANK für diesen wichtigen Hinweis!)
    Genau solche Probleme gibt's ja schon seit Ewigkeiten. Ich meine, es dürfte jedem klar sein, dass 10x funktionierendes S3 nicht reicht, wenn er sich dann beim 11ten Mal aufhängt. So etwas treibt einen zur Weißglut.


    Yepp, ich habe schon etliche threads zur GT210/220 und auch aktuellen Boards gelesen. Natürlich ist das temporal_spatial was Feines, allerdings ist das nicht wichtig, wenn viel andere Baustellen dann doch nicht ordentlich funktionieren.


    Deshalb spechte ich (vielleicht etwas zu stark) auf eine Intel-Lösung, da da der Kernel-support außerordentlich ist (siehe KMP und 3D-hardware-support) => AMD und Nvidia brauchen immer ewig für Anpassungen, bei bei neuen Kerneln ist der Intel-support immer schon "so mit drin". Ich würde mir hier zumindest konstanten S3-support und aktuell unterstützte features erhoffen.


    Mit den Bootzeiten hast du Recht. Ich hab noch nen extra Ubuntu 10.04-Server laufen, der ist mit den ASRock 330ION schon super schnell beim booten - sowas kennt man unter Debian gar nicht. ;)
    Allerdings startet der natürlich kein X, VDR und DVB-modules.
    Aber vielleicht wäre neu booten mittlerweile tatsächlich verschmerzbar; da müsste man wieder konkrete Boot-Zeiten vergleichen.
    Das mit DVB-Module laden/entladen kenne ich schon, das dauert _einige_ Zeit. Ich hatte nur gehofft, dass man die nach 7 Jahren vielleicht doch einfach so einfrieren kann. :(
    Wie schnell sind da Windows-Systeme eigentlich ? Für Win7 gibt's ja vorgegebene (mindest-)Aufwachzeiten. Dauert das da das Aufwachen auch so lang?

    > Normal geht der VDR in den Wakeup und ist dann ganz aus.


    Was meinst du damit? Ich verwende zZ NVRAM-wakeup auf nem ASUS-Board. Der VDR kann die Zeiten programmieren und schaltet dann direkt aus (das BIOS muss hier nichtmal rebooten, damit der wakeup-timer läuft). Funktionierende wakeup-timer und funktionierendes S3 sind aber zwei paar Stiefel.


    Aha, Stromverbrauch auf i3-Plattform niedriger.
    Wie ich gerade gelesen habe, soll XBMC seit Dezember VAAPI unterstützen. Ist natürlich noch nicht in einer Distri drin(Debian unstable vielleicht), allerdings wären damit auch die Intel-Chipsätze bald out-of-the-box unterstützt, ohne, dass mit "hacker-patches" rumhantiert werden muss.


    Ich weiß, dass es noch tausend andere Fallstricke gibt, die beachtet werden müssen - hab ja schon nen VDR seit Ewigkeiten. Ich würde aber gerne die Hauptmankos diesmal ausmerzen.
    Fallstricke, die ich später noch abchecken wollte:
    - Gesamtlautstärke
    - BIOS-bootzeit
    - Umschaltzeiten
    - ...
    Stromverbrauch ist mir eigentlich nur wichtig wg Verlustleistung -> mehr Lüftungsbedarf -> lauter
    Der VDR steht bei mir im Schlafzimmer und muss daher seeeehr leise sein.


    Seit langem stört mich die Bootzeit meiner Kiste, und S3 - mit dem yaVDR wirbt - wäre doch super!
    Zusätzliches Problem ist, dass ich gerade auch festgestellt habe, dass ich noch ein neues Netzteil brauche (das alte hat leider nur 20pins). Also muss ich schon überlegen, ob nicht gleich ein kleines Gehäuse (ITX) mit Passivnetzteil besser/leiser wäre.


    Wenn ich gleich eine IGP-Lösung verwende mit einer PCIe-TwinDVB, könnte man das Ganze sehr klein und effektiv gestalten - wenn denn alles funktioniert.
    Leider sind die VDR-Wikis recht alt und man braucht für jede Info einen Erfahrungsbericht mit "Ja, das geht!".
    Und gerade bei Linux sind solche Meldungen wichtig, weil alle nicht vorhandenen Berichte so viel heißen, wie "GEHT NICHT!" ;)


    Grüße...

    Danke für die Infos!


    Bei VP4 (Featureset C) sind anscheinend DivX-Decodierung etc. dazu gekommen. Naja, würde ich nicht wirklich als wichtig bezeichnen, weil diese Kodierung kaum Rechenleistung beim decoden zieht (bzw nicht in den üblichen Auflösungen). Interessanter ist da schon die Aufhebung der Auflösungsbeschränkungen von H.264.


    Spricht eigentlich etwas gegen einen Intel-IGP (z.B.: i3-530) in Verbindung mit VAAPI?
    Abgesehen von
    - fehlendem Deinterlacer (der temporal_spatial wird ja direkt in der Gforce ausgeführt, oder?)
    - mehr Stromverbrauch der Intel-Plattform
    ...oder ist VAAPI einfach noch nicht fertig (zuviel Gebastel)?
    Intel war die letzten Jahre super bzgl. Kernelunterstützung und Suspendverhalten.

    > Featureset C: mehr codecs


    Uups, ich dachte die können sowieso "alles": MPEG2/4, H.264, VC1 etc. pp.
    Wo kann man darüber etwas nachlesen?
    Ich habe hier ein PDF: pure_video_hd_support.pdf von Nvidia, und da ist kein Unterschied bei den decoding-Fähigkeiten von nforce-Chipsätzen und normalen Grakas zu sehen. Auf einer anderen Wiki(?)-Seite habe ich auch nachgelesen, dass VDPAU-Fähigkeit mit PureVideoHD gleichzusetzen ist.
    Mit besserem Deinterlacer meinte ich den "temporal_spatial". Da weiß ich aber noch nicht genau, welche Karten den unterstützen und ob das vielleicht einfach nur wegen der fehlenden Leistungsfähigkeit der IGPs nicht geht.


    Eure (anscheinend S3-funktionierenden) Mainboards muss ich mir später noch mal genauer anschaun.
    Bei S3 ist die Grafikkarte nicht mehr das Problem? Interessant. :schiel
    Damit bin ich ein geschlagenes Kind und hatte mir irgendwann mal geschworen nie wieder nen proprietären Treiber anzufassen.


    Den PCIe wollte ich eigentlich freihalten, um evtl. später ne TwinDVB-Karte reinzustecken.

    Hallo Stephan_84, danke für den Überblick.


    Zunächstmal möchte ich noch anmerken, dass "Basteln" für mich grundsätzlich kein Problem ist. Allerdings möchte ich nicht mehr im Stile von VGA2SCART basteln (= patches für CVS-versionen, wobei letztere ständig ändern und man nach Wochen Gebastel merkt, dass es selbst mit einer "normalen" Distri nicht richtig läuft). Entwicklerpatches sollten also in absehbarer Zeit also auch standardmäßig integriert sein, sodass es keine Patches mehr braucht.
    Wenn die Intel-Lösung nicht _jetzt_schon_ vollständig in allen subsystemen (kernel, xorg, xine) drin ist, besteht wenig Hoffnung, dass das in 6-9 Monaten "einfach läuft". Und ob S3 damit läuft, ist ohnehin unklar.


    Ich wollte eigentlich nicht auf die PCI-Slots verzichten. Ansonsten müsste ich meine jetzigen Karten verschrotten und nen extra Twin-Tuner >120,- kaufen. Das wollte ich vermeiden, bzw in die Zukunft verschieben.


    > Zotac Board aus der GeForce 9300er


    Ist das ein ION-Board?
    => Sehr heiß (also Lüftung _doch_ nötig -> wo sind dann die Vorteile?), Wenig CPU-Leistung, keine/kaum Erweiterbarkeit. Hat das nen COM-Port?
    (Wie bereits im Eingangspost beschrieben, wollte ich eben lieber kein ION-Board - außer es kann S3. Ich habe bereits ein genügend großes Gehäuse. Ich brauche keine bestimmte Boardgröße, nur 100%ige Funktionalität)


    > Alternative ist dann ein aktuelles µATX Board mit einer GeForce GT210, wie schon häufig hier im Forum diskutiert.


    Ich würde gerne eins mit im Chipsatz integrierter GPU haben, ohne extra Grafikkarte. Sonst ist der PCIe wieder zu, ebenso die Erweiterungsmöglichkeiten. Ich sehe auch bei allem Lesen noch nicht die echten Vorteile einer GT210.



    Mein Hauptpunkt ist hier aber anscheinend übersehen worden: Ich möchte, dass Suspend-To-RAM läuft!
    Ich habe mir die meisten empfohlenen Systeme hier schon angesehen mit allen ihren Vor- und Nachteilen.
    Wo VDPAU anscheinend von der hardware-Unterstützung am weitesten ist, ist mir noch nicht klar, ob damit auch S3 läuft (Stichwort(e): closed-source-Treiber contra Kernelwechsel)
    Erwähnt wird in den Listen, die ich gesehen habe, nur ACPI-wakeup, womit aber etwas anderes gemeint ist (timergesteuerte Aufnahmen).
    Die standalone GeForce GT210 ist anscheinend recht leistungsfähig und kann einige deinterlace-Modi, die IGP-GeForces nicht können(?) - laut NVidia-Datenblatt allerdings schon......tja. Brauche ich denn den besseren deinterlacer?