Beiträge von SH0DAN

Hallo Copperhead,

was sagt denn das Kommando vmstat (oder besser vmstat 1 für sekündliches Update) wenn dein Rechner das Stottern anfängt. Ich hatte das mal bei einem Serversystem. Ist anscheinend ein Problem des 2.6er Kernels das ab und an auftritt (https://bugzilla.kernel.org/show_bug.cgi?id=13347). Wenn IOWait (spalte WA) hoch geht, dann kann sich das so weit aufschaukeln, bis das ganze System stehen bleibt. Die Prozessorlast ist dabei gering (teilweise <1%), er wartet eben dauernd auf I/O. Evtl. hilft der Deadline-Scheduler weiter.

Nur so eine Idee. Warum das jetzt mit der Version 0.3.4 auftritt und mit 0.3.3 nicht? Keine Ahnung...

Hallo Zusammen,

ich hoffe ich darf kurz mit einer Frage dazwischen grätschen:
Das saa716x_ff-Modul schreibt bei mir in unregelmäßigen Abständien den folgenden Fehler ins Kernel-Log:

[252605.224607] demux_worker: called but nothing to do
[252668.241777] demux_worker: called but nothing to do
[253045.469771] demux_worker: called but nothing to do
[253088.773765] demux_worker: called but nothing to do
[253109.767772] demux_worker: called but nothing to do
[253319.821818] demux_worker: called but nothing to do
[253487.871957] demux_worker: called but nothing to do

Ansonsten keine Probleme. Keine Timeoutmeldungen (wie von einigen vorher schon bemerkt), keine Crashes und keine kaputten Festplatten Der Interrupttyp ist völlig egal (ob INT oder MSI spielt keine Rolle). Ich nutze das aktuellste Modul von Powarman + Powarman dvbhddevice und die aktuellste Firmware:

SAA716x FF FPGA version 1.09
SAA716x FF loader version 1.03
SAA716x FF firmware version 0.3.3

Da bisher alles einwandfrei funktioniert, wollte ich fragen, ob diese Meldungen evtl. auf ein Problem hinweisen, welches ich bisher einfach nicht bemerkt habe.
So wie ich den Source des Moduls beim Überfliegen verstanden habe, wird die Meldung ausgegeben, wenn der Demux-Worker aufgerufen wird, der FiFo für den TS aber keine neuen Daten enthält. Der Worker wird immer dann ausgeführt, wenn ein DMA-Interrupt ausgelöst wurde. D.h. es wird ein DMA-IRQ ausgelöst ohne dass neue Daten in den Speicher geschrieben wurden (dies wird dadurch erkannt, dass die Karte die Ringpufferposition (wird aus dem MM-Speicherblock der Karte ausgelesen) nicht geändert hat und damit der Lesezeiger = dem Schreibzeiger ist). Habe ich das so richtig verstanden?

Leider kenne ich mich mit der Karte zu wenig aus um herauszufinden ob das normal (die Interrupts bedeuten etwas anderes) oder problematisch (irgend etwas ist schief gelaufen und deswegen ist der Puffer leer) ist. Es kann natürlich auch sein, dass ich beim Querlesen des Codes einfach etwas falsch verstanden habe. Evtl. kann mir das jemand mit mehr Sachverstand beantworten...

Sollten noch weitere Infos nötig sein, bitte einfach fragen.

Hallo zusammen,

jetzt beantworte ich mal meine eigene Frage. Vor allem für alle, die evtl. auch auf die TT S2-6400 wechseln möchten:

Ich hatte am Mittwoch (21.09.2011) die Gelegenheit auf die S2-6400 zu wechseln. Das Board ist, wie Eingangs schon beschrieben, ein M4A785TD-V EVO mit einem AMD-Sempron 140.
Die DVB-Karte hab' ich in den ersten 1Lane PCI-Express Slot gesetzt und sie hat einen eigenen Interrupt ganz für sich alleine

Die Treiber hab ich aus Powarmans Repository ausgechecked und compiliert (http://powarman.dyndns.org/hgwebdir.cgi/v4l-dvb-saa716x/). Das dvbhddevice des VDR 1.7.21 habe ich auch gegen das von Powarman ausgetauscht (http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice/). Das war's eigentlich schon.

Nun zum Fazit
Die Karte läuft einwandfrei. Allerdings lade ich das Kernelmodul aktuell beim VDR-Start (in runvdr) und nicht bei booten. So ist die Karte bisher jedes mal sauber hoch gekommen. Da mein Server aber eh immer läuft, reicht es, wenn sie einmal korrekt startet. Einige der im Thread von Copperhead gesammelten (danke dafür) Fehler kann ich zwar nachvollziehen, sie stören aber nicht wirklich:

• Aussetzer beim wechseln der Tonspur (ist aber nach wenigen Sekunden vorbei)

Was noch auffällt sind ca. 30-40 "demux_worker: called but nothing to do"-Meldungen pro tag im Kernel Log. Leider konnte ich bisher noch nicht herausfinden wann diese Auftreten. Sie scheinen aber auf kein ernsthaftes Problem hinzuweisen, da so weit alles einwandfrei funktioniert

Einige Punkte aus dem Thread treten bei mir nicht auf:

• Das "träge OSD" kann ich aber nicht bestätigen: Gefühlt dauert es weniger als eine viertel Sekunde, bis das OSD sich öffnet. Es geht definitiv genauso schnell wie bei der alten FF-Karte.
• Knackser/Aussetzer im Live Tv treten überhaupt nicht auf. Nach dem Umschalten könnte man sich manchmal einen kurzer Tonhänger einbilden.

Also nochmal Danke und großen Respekt an Powarman für die gute Arbeit mit den Treibern. Diese sind aktuell schon sehr stabil. Ich musste sie noch kein einzigen mal neu laden. Jetzt bin ich nur noch auf das nächste Gewitter gespannt - das wird dann der Härtestest.

Somit also für alle, die sich evtl. auch so eine Karte zulegen wollen, ein positiver Erfahrungsbericht.

PS.: Die Karte funktioniert perfekt mit den oben erwähnten HDMI-Extendern

Hallo Copperhead,

erst einmal Danke für die Info. Aus meiner Sicht ist es mit einem make, make install nicht unbedingt getan. Ich knöre nur ungern an der Paketverwaltung vorbei irgendwelche Dateien in das System. Wenn man für alles noch Debian-Pakete über den "module assistant" bauen will, wird's schon etwas aufwändiger...

Aber darum ging's mir eigentlich nicht und ich wollte mich bestimmt nicht beschweren.

Die Frage war eher aus neugierde gestellt. Allerdings hatte ich schon im Hinterkopf ob es hier eine Synchronisation zwischen dem offiziellen Repo und dem Zweig für die S2-6400 Treiber gibt. Nicht dass bei zukünftigen Kernelversionen irgendwann Probleme auftauchen. War - wenn ich mich richtig erinnere - am Anfang bei der SD FF auch mal so. Da waren dann irgendwann verschiedene Patches nötig, um die Treiber unter neueren Kernelversionen überhaupt noch bauen zu können.

Hallo Zusammen,

ich bin gerade dabei meinen VDR S2-6400-Fit zu machen. Treiber lassen sich compilieren, vdr-1.7.21 sieht auch gut aus. Wenn jetzt die Karte noch schnell geliefert wird und mein Board sich mit ihr verträgt ist alles Super

Beim Lesen der ganzen S2-6400 Threads hier im Forum drängt sich mir jedoch eine Frage auf, für die ich keine Antwort gefunden habe:
Powarman kümmert sich ja liebevoll um die Verbesserung der Treiber für die S2-6400. Hierfür gibt es ein eigenes Repo unter powarman.dyndns.org. Doch wie kommen die Fixes und Verbesserungen in den offiziellen Kernel? Unter linuxtv werden ja - meines Wissens nach - die Sources für die im Kernel integrierten DVB-Treiber gepflegt. Irgendwie ist mir noch nicht ganz klar, ob und wie der Support für die S2-6400 in den offiziellen Kernel integriert wird und somit Compilierorgien für den Treiber der Vergangenheit angehören.

Es kann durchaus sein, dass ich vor lauter S2-6400-Threads, Patches, Firmware und dvbhddevice-Versionen den Überblick verloren habe und die Antwort ganz offensichtlich ist. Trotzdem wäre es toll, wenn mich hierzu jemand aufschlauen könnte...

Hallo zusammen,

zuerst einmal danke für die vielen Antworten. Jetzt ist mir einiges klarer.

Von der Extender-Front gibt es positives zu berichten. Nachdem ich mit Big Buck Bunny die Übertragung unverschlüsselt testen konnte, habe ich die Line-Compensation der Extender-Boxen richtig eingestellt. Außerdem habe ich die von mir für den ersten Test genutzten Cat4 Patchkabel gegen Cat5e ausgetauscht. Jetzt klappt alles Einwandfrei. Unverschlüsselt ohne Bildfehler, verschlüsselt ohne Aussetzer :D. Hier war der Tip bzgl. HDCP von "Keine Ahnung" Gold wert.

Für die S2-6400 nehme ich mit, dass der Stand ungefähr der gleiche ist, wie am Anfang mit den Nexus FF-Karten. Ich hoffe die Treiber reifen ebenso schnell wie bei diesen. Denn einen Watchdog-Reset hatte ich bei den SD-FF-Karten in den letzten drei Jahren keinen mehr (auch bei miesestem Wetter).

Hoffentlich verkauft sich die S2-6400 gut und die Entwickler (allen voran powarman :respekt) sind motiviert die Qualität von Treiber und Firmware auf den gleichen Stand zu bringen wie bei der Nexus.

In ein paar Wochen hab' ich Urlaub und dann werde ich das Projekt "VDR HD" mal angehen. S2-6400 rein, extender dran und Daumen drücken

Hallo lola,

welcher Art ist die Zuwendung denn? Reicht ein VDR-Neustart oder muss der Treiber (des Kernelmodul) oder gar das ganze System neu gestartet werden?

Meine aktuelle SD-FF kommt bei starkem Gewitter zwar auch aus dem Tritt, fängt sich aber relativ schnell wieder, sobald der Empfang besser wird. Das war aber nicht mit jeder Firmwareversion so...

Hallo "Keine Ahnung",

danke, das mit dem HDCP hab ich total vergessen :wand. Das kommt davon, wenn man HDMI sonst nur als ITler (z.B. für große Displays) verwendet, da kommt HDCP eher nicht vor und zu lange, geknickte (passiert häufiger vor als man denkt) oder schlechte Kabel fallen durch Bildfehler (Pixelfehler, Flackern, etc.) auf. So etwas hatte ich auch bei den Extender-Boxen erwartet. (Daher die Aussage mit der Top-Bildqualität. So viel, dass das nichts mit einer analogen Übertragung gemein hat, ist von der Nachrichtentechnik noch hängen geblieben :D). Das daraus natürlich durch die HDCP-Verschlüsselung eine "alles oder nichts"-Aktion wird, ist mir echt nicht in den Sinn gekommen.

Hm, jetzt muss ich mal sehen, wo ich ein unverschlüsseltes 1080p-Signal zum Testen her bekomme. Ich denke, dann lässt sich leichter feststellen woran es hapert, da die Bildfehler ja - vor dem totalen Signalverlust - zunehmen. Ich denke das macht eine qualitative Abschätzung leichter...

Hallo zusammen,

danke für die bisherigen Kommentare. Wenn noch jemand gute Erfahrungen gemacht hat, so wäre ich für noch ein paar Ermutigungen dankbar.

Gestern sind die HDMI über CAT5/6/7 extender von Cablesson eingetroffen. Ich habe sie heute mit dem BlueRay-Player und 1080p Videomaterial (mit DD 5.1 Audio) gestresst. Echt beeindruckend die Dinger . Über ein CAT6-Kabel von 15 Metern Länge (Keller <-> Wohnzimmer) war das Bild optimal. Kein Unterschied zum 2m HDMI-Kabel über das der BD-Player sonst angeschlossen ist. Sogar die Fernbedienung wird mit durch gereicht. Einziges Problem waren ein paar sporadische Bildaussetzer. Ob das jetzt an den lumpigen HDMI-Kabeln oder an meinem fliegenden Aubau lag, weiß ich noch nicht. Ich hab Cablesson deswegen mal angeschrieben, mal sehen, ob die noch einen Tip haben... Wobei: 1080p wird's mit der S2-6400 wohl eh nicht geben.

So wie's aussieht wird also im nächsten Urlaub (Ende September) mein Videoserver mit einer neuen S2-6400 bestückt und dann geht das mit den Extendern hoffentlich genauso problemlos wie heute.

Hallo,

was mich noch interessieren würde: Läuft das MP3-Plugin (mit 48kHz Output)? Sonst habe ich nur FeMon, Mail und EPGSearch im Einsatz. D.h. ziemlich minimalistisch. Diese Plugins sollten - wenn ich keinen Thread übersehen habe - eigentlich laufen, oder?

Copperhead: Danke für den Input. D.h. die Stabilität ist kein Problem. Wie sieht's mit vermurksten Aufnahmen aus? Das wäre wichtig für den FAF (Family Acceptance Factor ;D)
FireFly: Das war wohl ein Missverständnnis. Aktuell ist die SD-FF per FBAS angeschlossen. Für die neue S2-6400 kommt dann ein HDMI-Extender (ist wohl heute in der Post - ich bin gespannt) zum Einsatz.

Kann sonst noch jemand von seinen Erfahrungen berichten?

Hallo zusammen,

nachdem mein alter SD-Fernseher seinen Geist aufgegeben hat, musste etwas neues her: Schick, HD tauglich mit LED-Backlight, etc. Und wie das häufig so ist, ziehen Anschaffungen weitere Anschaffungen nach sich. Doch von Anfang an:

Aktuell steht bei mir ein Server mit folgender Hardware im Keller:
* Mainboard ASUS M4A785TD-V EVO
* 2 Festplatten Hitachi Deskstar 1TB
* 1 WinTV Nexus
* 1 WinTV Nova
* 1 HFC ISDN Karte

Aktuell speist die FF-Karte ihr Videosignal in einen Videomodulator von Axing ein, welcher dann wieder über den Multiswitch den Fernseher speist. Wie man sich schon denken kann, sieht das (über Composite in den AV-Modulator eingespeiste) Bild auf dem neuen TV nicht mehr so gut aus. Wer die Details der Lösung (z.B. wie das Fernbedienungssignal in den Keller kommt) wissen möchte kann gerne unter http://www.flashsystems.de/hardware/vdr-remote-adapter nachlesen.

Da ich ein CAT6-Kabel vom Keller (mit dem Server) bis zum VDR liegen habe und die Distanz weniger als 15 Meter sind, habe ich mir jetzt erst einmal einen HDMI-über-CAT5-Extender bestellt (http://ukhdmi.com/cablesson-hd…i-directional-ir_QQ103012). Das dieser auch gleich das IR-Signal der Fernbedienung zurück zum Server überträgt ist perfekt. Nach der langen Vorrede nun meine eigentliche Frage:

Wie stabil ist die TT S2-6400 im Moment. Der aktuelle VDR-Setup läuft seit Mitte 2009 ohne Unterbrechnung und ohne Probleme. Keine Störungen, keine Aussetzer, keine Crashes. Nachdem auf dem Server die Firewall, die Telefonanlage und viele andere Dinge untergebracht sind, wäre ein instabiles System wirklich schlecht. Nachdem ich die letzten Tage die Threads bzgl. der TT S2-6400 gelesen habe, hat sich leider kein klares Bild herauskristallisiert. Natürlich schreiben nur die, bei denen es nicht klappt. Ob das die Mehrheit ist und ich mir lieber VDPAU (was zumindest mit der On-Board-Grafik nicht geht) antue, ist mir im Moment völlig unklar.

Daher würde ich gerne einmal euere Meinung hören: Ist die TT S2-6400 schon so weit oder sollte man noch warten und mit dem vermatschten Bild vorlieb nehmen? Ich weiß dass viele fähige Leute ihre Zeit in die Weiterentwicklung der Karte investieren (Danke dafür!). Was ich nicht weiß ist, ob sie auf verlorenem Posten kämpfen (z.B. weil die Hardware nichts taugt, etc.) oder ob es irgendwann so hervorragend klappt wie bei den SD FF-Karten...

PS: Wenn es jemanden interessiert, kann ich gerne von meinen Erfahrungen mit den HDMI-Extendern berichten, sobald ich diese getestet habe...
PPS: Danke an alle, die ihre Freizeit opfern, damit andere und ich besser Fernsehen können

Hallo Dr. Seltsam,

nein, bisher hab ich einfach einen Vanilla 1.6.0 laufen. Dieser hat auf meinem alten System schon mehrere Monate problemlos funktioniert. Sobald ich mal Zeit habe, ziehe ich die Patches nach. Ich bin jedenfalls froh, dass es erst einmal wieder läuft und schlage mich jetzt mit dem IMAP-Server herum *grumpf*

Auch wenn das jetzt ein bisschen nach Selbstgesprächen klingt. Zur Info für alle die über diesen Thread stolpern:

Ich bin wieder auf VDR 1.6.0 zurück. Dieser lässt sich (wenn man die const char -> char Konvertierungen manuell nachrüstet - gcc wird auch immer pingeliger) problemmos übersetzen und installierne. Jetzt funzt alles und ich warte einfach ab, bis Fedora auf Kernel 2.6.31 oder neuer aktualisert.

Danke an alle, die mir geholfen haben.

Da ich nicht den Kernel-Source installieren und den ganzen Kernel neu übersetzen will hier meine Idee:

• Ich packe mir das Fedora 11 in eine VM.
• Installiere den Kernel-Source in der VM.
• Ich lade mir den v4l-dvb Treiber herunter und kompiliere ihn.
• Ich tausche die Kernelmodule meines Videoservers mit Kernel 2.6.30 gegen die Kompilate aus der VM aus.
• Nun sollte es ja gehen.
• Sobald 2.6.31 für Feodra 11 verfügbar ist tausche ich den Kernel aus und kan den alten (inkl. der geänderten Module) deinstallieren.

Nur eine Frage: Die Header wären dann die des 2.6.30 Kernel. Kann jemand einschätzen wie groß die Änderungen an der Schnittstelle waren? Könnte das Funktionieren?

Und nochmal vielen Dank für die Tips. Das hat mir echt weitergeholfen

Hallo zusammen,

vielen Dank für die Tips.

UFO: Nein, timeshift geht auch nicht. Alles was mit de Abspielen von .ts Streams zu tun hat, geht in die Hose. Also Transfer von Budget -> FF, Timeshift, abspielen von neuen Aufnahmen. Nur die alten Aufnahmen und direktes Fernsehen FF intern gehen.

e9hack: Dann werd ich mal sehen, ob Fedora 11 den 2.6.31 bald über das standard Repo anbietet. Wenn's nicht klappt, kompilier ich einfach die Module und tausche sie aus.

Danke für die Tips. Ich melde mich, sobald es was neues gibt. Wenn zwischenzeitlich noch jemand einen geistesblitz hat, immer her damit

Jetzt beantworte ich mal meine eigene Frage:

Die neue Firmwareversion ist http://www.escape-edv.de/endri…re/dvb-ttpci-01.fw-fc2624 und die gibt es unter http://www.escape-edv.de/endriss/firmware. Also habe ich diese nun installiert.

Leider funktioniert es noch immer nicht die Bohne. Der vdr gibt auf der Konsole jetzt einen haufen "---" aus, sobald ich auf einen Transponder umschalte bei dem der Transfer von Budget -> FF läuft.

Ich habe gerade mal mit VLC die .tc-Datei abgespielt. Das klappt problemlos. Also scheint es wirklich ein Firmwareproblem zu sein.

Genügt der 2.6.30 Kernel evtl. nicht und ich muss auch noch die Kernel-Module kompilieren? Eigentlch wollte ich das vermeiden...

Hm,

könnte sein. Da ja der Transfer von der Budget zur FF wie das Abspielen einer Aufnahme ist. Welche Firmwareversion brauche ich denn. Aktuell ist die dvb-ttpci-01.fw-2622 drauf.

Danke, Daniel.

So,

die Karten habe ich nun in allen Permutationen eingesteckt:
FF-_-B
FF-B-_
B-FF-_
_-FF-B
B-_-FF
_-B-FF

Leider auser einem blutigen Finger keine Veränderung.

Noch eine Info: Die Aufnahmen welche Funktionieren stammen noch aus dem alten System (VDR 1.6.0).

Hallo zusammen,

ich habe gerade die Hardware meines Videoservers getauscht und jetzt habe ich ein Problem mit dem VDR. Ich kann aufnahmen ansehen und solange die FF-Karte verwendet wird, kann ich fernsehen. Jedoch klappt es nicht von der Budget auf die FF-Karte fernzusehen und alle Aufnahmen (egal von welcher Karte) sind im Eimer. Das Bleibt stehen und der Ton quietscht und pfeift. Im Kernel- und VDR-Log tauchen keine Fehlermeldungen auf.

Es scheint, als ob die Daten von den Karten nicht korrekt abgeholt werden können.

Nachfolgend meine Konfiguration:
lspci -v

00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge Alternate
        Subsystem: ASUSTeK Computer Inc. Device 83a2
        Flags: bus master, 66MHz, medium devsel, latency 0
        Capabilities: [c4] HyperTransport: Slave or Primary Interface
        Capabilities: [54] HyperTransport: UnitID Clumping
        Capabilities: [40] HyperTransport: Retry Mode
        Capabilities: [9c] HyperTransport: #1a
        Capabilities: [f8] HyperTransport: #1c


00:01.0 PCI bridge: ASUSTeK Computer Inc. Device 9602 (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: fe800000-fe9fffff
        Prefetchable memory behind bridge: 00000000fa000000-00000000fbffffff
        Capabilities: [44] HyperTransport: MSI Mapping Enable+ Fixed+
        Capabilities: [b0] Subsystem: ASUSTeK Computer Inc. Device 83a2


00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 5) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: fea00000-feafffff
        Prefetchable memory behind bridge: 00000000fdf00000-00000000fdffffff
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Root Port (Slot+), MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [b0] Subsystem: ASUSTeK Computer Inc. Device 83a2
        Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
        Capabilities: [100] Vendor Specific Information <?>
        Capabilities: [110] Virtual Channel <?>
        Kernel driver in use: pcieport-driver


00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] (prog-if 01 [AHCI 1.0])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 26
        I/O ports at b000 [size=8]
        I/O ports at a000 [size=4]
        I/O ports at 9000 [size=8]
        I/O ports at 8000 [size=4]
        I/O ports at 7000 [size=16]
        Memory at fe7ffc00 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [60] Power Management version 2
        Capabilities: [50] MSI: Enable+ Count=1/8 Maskable- 64bit+
        Capabilities: [70] SATA HBA <?>
        Kernel driver in use: ahci


00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        Memory at fe7fe000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: ohci_hcd


00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        Memory at fe7fd000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: ohci_hcd


00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
        Memory at fe7ff800 (32-bit, non-prefetchable) [size=256]
        Capabilities: [c0] Power Management version 2
        Capabilities: [e4] Debug port: BAR=1 offset=00e0
        Kernel driver in use: ehci_hcd


00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
        Memory at fe7fc000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: ohci_hcd


00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
        Memory at fe7fb000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: ohci_hcd


00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller (prog-if 20 [EHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
        Memory at fe7ff400 (32-bit, non-prefetchable) [size=256]
        Capabilities: [c0] Power Management version 2
        Capabilities: [e4] Debug port: BAR=1 offset=00e0
        Kernel driver in use: ehci_hcd


00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3c)
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: 66MHz, medium devsel
        Capabilities: [b0] HyperTransport: MSI Mapping Enable- Fixed+
        Kernel driver in use: piix4_smbus
        Kernel modules: i2c-piix4


00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller (prog-if 8a [Master SecP PriP])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
        I/O ports at 01f0 [size=8]
        I/O ports at 03f4 [size=1]
        I/O ports at 0170 [size=8]
        I/O ports at 0374 [size=1]
        I/O ports at ff00 [size=16]
        Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit-
        Kernel driver in use: pata_atiixp
        Kernel modules: pata_atiixp


00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 0


00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
        I/O behind bridge: 0000e000-0000efff
        Memory behind bridge: feb00000-febfffff


00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. Device 8389
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
        Memory at fe7fa000 (32-bit, non-prefetchable) [size=4K]
        Kernel driver in use: ohci_hcd


00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration
        Flags: fast devsel
        Capabilities: [80] HyperTransport: Host or Secondary Interface


00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map
        Flags: fast devsel


00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller
        Flags: fast devsel


00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control
        Flags: fast devsel
        Capabilities: [f0] Secure device <?>


00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control
        Flags: fast devsel


01:05.0 VGA compatible controller: ATI Technologies Inc Device 9710 (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 83a2
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at fa000000 (32-bit, prefetchable) [size=32M]
        I/O ports at c000 [size=256]
        Memory at fe9f0000 (32-bit, non-prefetchable) [size=64K]
        Memory at fe800000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [50] Power Management version 3
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+


02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
        Subsystem: ASUSTeK Computer Inc. Device 83a3
        Flags: bus master, fast devsel, latency 0, IRQ 27
        I/O ports at d800 [size=256]
        Memory at fdfff000 (64-bit, prefetchable) [size=4K]
        Memory at fdff8000 (64-bit, prefetchable) [size=16K]
        Expansion ROM at feaf0000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
        Capabilities: [cc] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel <?>
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Kernel driver in use: r8169
        Kernel modules: r8169


03:05.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board
        Flags: medium devsel, IRQ 20
        I/O ports at ec00 [disabled] [size=8]
        Memory at febffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
        Kernel driver in use: hfcpci
        Kernel modules: hisax, hfcpci


03:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge WinTV-NOVA-CI DVB card
        Flags: bus master, medium devsel, latency 64, IRQ 21
        Memory at febff800 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: budget_ci dvb
        Kernel modules: budget-ci


03:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1
        Flags: bus master, medium devsel, latency 64, IRQ 22
        Memory at febff400 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: dvb
        Kernel modules: dvb-ttpci

dmesg (nur relevanter Teil)

saa7146: register extension 'budget_ci dvb'.
budget_ci dvb 0000:03:06.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
IRQ 21/: IRQF_DISABLED is not guaranteed on shared IRQs
saa7146: found saa7146 @ mem f82a4800 (revision 1, irq 21) (0x13c2,0x100f).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (TT-Budget/WinTV-NOVA-CI PCI)
saa7146: register extension 'dvb'.
adapter has MAC addr = 00:d0:5c:23:dd:ee
input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci0000:00/0000:00:14.4/0000:03:06.0/input/input5
DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)...
dvb 0000:03:07.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
IRQ 22/: IRQF_DISABLED is not guaranteed on shared IRQs
saa7146: found saa7146 @ mem f8414400 (revision 1, irq 22) (0x13c2,0x0003).
dvb 0000:03:07.0: firmware: requesting dvb-ttpci-01.fw
DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X)
adapter has MAC addr = 00:d0:5c:23:6b:d5
dvb 0000:03:07.0: firmware: requesting av7110/bootcode.bin
dvb-ttpci: gpioirq unknown type=0 len=0
dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622
dvb-ttpci: firmware @ card 1 supports CI link layer interface
dvb-ttpci: Crystal audio DAC @ card 1 detected
saa7146_vv: saa7146 (1): registered device video0 [v4l2]
saa7146_vv: saa7146 (1): registered device vbi0 [v4l2]
DVB: registering adapter 1 frontend 0 (ST STV0299 DVB-S)...
input: DVB on-card IR receiver as /devices/pci0000:00/0000:00:14.4/0000:03:07.0/input/input6
dvb-ttpci: found av7110-0.

Kernel- und VDR-Version:
Fedora 11
Linux 2.6.30.5-43.fc11.i686.PAE #1 SMP Thu Aug 27 21:34:36 EDT 2009 i686 athlon i386 GNU/Linux
VDR 1.7.9

Das Board ist ein ASUS M4A785TD-V-EVO mit einem 1 GByte RAM und zwei SATA Festplatten.

So langsam bin ich am Verzweifeln und natürlich für jeden Tipp dankbar.

Gruß
Daniel

Hallo zusammen,

schön das dieses Thema noch immer von Interesse ist. Bzgl. der LEDs hätte ich eine Idee (wie Aufwändig das wird, ist mir noch nicht klar):

Die LED dimmen, solange sich nichts ändern. Wenn eine Änderung im Status eintritt, die LEDs kurz aufdimmen um die Änderung anzuzeigen und nach ca. 5 Sekunden wieder abdunkeln. Das sollte im "Kinobetrieb" dann deutlich weniger stören.

Wie man das Schaltungstechnisch macht ohne gleich einen µC zu nutzen, muss ich mir noch überlegen.

Gruß
SH0DAN