[tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

  • Zitat

    Original von ThomasF
    Bei mir hat zumindest gestern das Ändern der Latency mit setpci und einem reload der DVB Treiber keinen Erfolg gebracht ...


    Schon mal versucht, die Latency _nach_ dem Laden der Treiber zu ändern?
    Iirc kann man dies auch im laufenden Betrieb machen...


    CU
    Oliver

  • Ja, das hab ich auch schon versucht ... keine Besserung ...


    Ich habe jetzt für mich diesem Problem ein Ende bereitet indem ich mir ein neues Mainboard zugelegt habe ;) ... Und siehe da VDR liefert ein gestochen scharfes Bild mit Tvtime ...
    Ich weiß allerdings immer noch nicht ob es an der Latency Einstellung oder an dem SATA Kontroller bzw. Treiber liegt.


    Aber damit kann ich leben :)


    So long


    Thomas

  • Ich hab mal mit setpci experimentiert, alle Devices auf hohe ( 128 ) oder niedrige ( 8 ) Werte gesetzt, mal die Grafikkarte (nVidia Geforce 2MX) auf niedrig ( 8 ) und die Nexus-S 2.3 auf hoch ( 128 ).


    Ergebnis: Überhaupt keine Veränderung.


    Laut lspci -v wurden die Werte auch übernommen (außer PCI-, ISA-Bridge und IDE-Interface, die bleiben immer auf 0!). Und wenn ich testweise bei der Nexus auf 1 runtergehe, dann werden immer grüne Punkte eingestreut, die zum rechten Bildrand immer zahlreicher werden. Das beweist: Die Werte werden tatsächlich übernommen und gültig.


    Wie in einem früheren Beitrag gesagt: Bei mir stört anscheinend vor allem die Grafikkarte, ganz besonders, wenn Firefox werkelt, in Verbindung mit dem (hochoptimierten?) "nvidia" X11-Treiber, der den Bus vermutlich deutlich stärker stresst als "nv". Wenn die Platten schuften, was das Zeug hält, stört das dagegeben überhaupt nicht.


    Früher war der Effekt nicht so schlimm. Außerdem hab ich festgestellt, das inzwischen beim Musikabspielen (WAV-Daten an den onboard Soundchip) gleichzeitig zu den Streifen auch noch ein Kratzen und Verzögerungen/Stottern auftreten. Das war früher auch nicht der Fall. Kann entweder an der Weiterentwicklung der Grafik-Treiber liegen, oder daran, dass inzwischen ein zusätzlicher USB2-Controller am PCI-Bus hängt (obwohl da grad nichts angeschlossen ist).


    Das Audio-Gekratze erinnert mich an frühere Windows-Zeiten. Ein Update der Chipsatz-Treiber brachte damals Abhilfe. Ich werde es wohl aufgeben und irgendwann meine HW-Antiquität in Pension schicken...


    Ach ja, die Antiquität besteht u. a. aus:
    - Gigabyte GA 7ZX (VIA KT133 Chipsatz) mit Athlon Thunderbird 900MHz
    - nVidia Geforce 2MX (AGP, 32MB)
    - Nexus-S rev. 2.3


    Darauf läuft derzeit u. a.:
    - gentoo Linux 2006.0
    - Kernel: gentoo-sources-2.6.15-r5
    - xorg-x11-6.8.2-r6
    - Grafiktreiber: nvidia-kernel-1.0.8756, nvidia-glx-1.0.8756
    - VDR 1.3.45-r1 + div. Plugins, vdrconvert 0.2.1


    P.S.: Bei mir treten die Streifen nur beim Ausgeben auf dem Bildschirm auf, die Aufnahmen waren noch nie verstümmelt. Würde mich auch wundern, denn da wird ja einfach der DVB-Strom ein eine Datei geschrieben. Bei Fehlern würde er sich gar nicht mehr decodieren lassen oder zumindest andere Artefakte verursachen.


    dad401: Bist du sicher, dass die Störungen schon in der Aufnahme drin sind?

  • Hallo zusammen,


    da ich gestern meinen alten VDR mal wieder aktualisiert habe, habe ich mal wieder mit tvtime rumgespielt. Da sind mir wieder die grünen Streifen aufgefallen. Da ich auch einen Grafikkartenwechsel vorgenommen habe, hat sich folgendes gezeigt.


    Mit der ATI 9200SE tritt der Fehler überhaupt nicht auf. Das Bild ist absolut super.


    Ich habe dann wegen Compiz mal eine NVIDIA 6200 eingebaut und sie da, die Streifen sind wieder vereinzelt zu sehen.


    Das Problem scheint also definitiv NVIDIA-spezifisch zu sein. Gab es in der Zwischenzeit (sind jas fast 2 Jahre :-)) von irgendjemand in der Sache neue Erkenntnisse?


    Viele Grüße


    Soave

  • Hi,


    ich habe das "grüne Streifen" Problem jetzt auch. Damit ist kein schauen mehr möglich.
    Und zwar seit ich eine 1 TB sata-platte, betrieben an einem PCI-SATA-Controler (Conrad, ca. 23,-) , hinzugenommen habe. Die grünen Streifen treten nur bei sata-Datentransfers auf. Je mehr transfer (Datei umkopieren), je heftiger.


    Vor der sata-Platte hatte ich das Problem auch, aber ganz anders: Ab und an war das *ganze* tvtime-Bild für einen "frame" Grün. Ich konnte das nie zuordnen. Die Platten sind normale IDE, Samsung 160 GB + Samsung 300 GB.


    Experimente mit div. PCI-Slots (Abstand), und getrennte Interrupts für sata und Technotrend 1.3 (Irq-sharing vermeiden) brachten leider nichts.


    Das Problem tritt bei der Ausgabe mit tvtime auf, nicht bei der Ausgabe auf RGB.
    (Eine andere SW die /dev/video abgreift habe ich nicht.)


    Imo kann die Technotrend Karte die Daten nicht zeitgerecht über den PCI-Bus nach /dev/video "abliefern".


    Das VDR-system habe ich vor 2-3 Jahren aufgebaut (vdr 1.3.36 ?) benutzt jemand aktuelle dvb-treiber von 2007 und hat das Problem leider trotzdem ?


    P.S.: Sorry für den nächsten Post, sollte eigentlich nur ein edit werden...


    Grüße
    Ralf

    VDR - Die 'Killerapplikation' die mich zu Linux gebacht hat ;)

    Neues yaVDR HD-System ging am 20.12.2013 in Betrieb :)
    yaVDR 0.7-ansible im Aufbau ab Jan. 2024.

    Einmal editiert, zuletzt von RalfDietz ()

  • Nasowas, der Thread ist ja doch noch nicht tot!


    Also ich hab die grünen Streifen immer noch, aber wenn ich neben dem Fernsehen keine weitere Last auf die Maschine bringe, ist's nicht schlimm. Hab mich damit abgefunden und hoffe auf Besserung, wenn ich meine Hardware-Antiquität ersetze.


    Der Vollständigkeit halber: HW + Streifen sind gleich geblieben, SW ist neuer:


    - gentoo Linux 2007.0
    - Kernel: gentoo-sources-2.6.23-r6
    - xorg-x11 7.2
    - Grafiktreiber: nvidia-drivers 96.43.01
    - VDR 1.4.7-r10 + div. Plugins, vdrconvert 0.2.1-r1



    @RalfDietz: Hast du mal mit setpci experimentiert? Vielleicht hilft's bei dir doch was.


    Zusammenfassend kann man wohl sagen: Viel Last auf dem PCI-Bus führt bei mancher Hardware (vorwiegend NVidia Grafik und (S)ATA) zu den Streifen.


    Hängt vielleicht damit zusammen, wie gut oder schlecht die Treiber den PCI-Bus durchwalken. Aber das sind alles Mutmaßungen, so gut kenne ich mich da nicht aus.


    Bei neuerer Hardware bestünde wohl die Hoffnung, dass es keine Streifen gibt, wenn SATA und Grafik über PCIe separat angebunden sind.


    Grüße
    Bernd

  • Zitat

    Original von womble
    HW: 900 MHz AMD Thunderbird, 768 MB RAM (SDRAM), Nexus-S rev. 2.3, nVidia GeForce 2 MX

    Was ist das für ein Mainboard?
    Ich wette eins mit KT133 oder KT133A Chipsatz ;D.


    Wenn ja, dann poste bitte mal was "lspci -vxxx" ausgibt.

    Gruss
    SHF


  • Hi,


    Hier schon mal mein lspci -v :D
    Komponenten/Mainboard siehe Signatur.



    Ich habe nun eine *Zwischenlösung* entdeckt: Die störende sata-Platte kommt an einen USB-(S)ATA konverter.


    Abgeshen von der mageren Geschwindigkeit, mußte ich feststellen, daß auf USB-Devices kein LVM funktioniert......(Getested auf Suse 10.0) :wand


    Was bustiming angeht, bin ich überzeugt daß die TT-FF und der sata-Controller die entscheidenen Komponenten sind...


    Edit: Genauer gesagt das BusMASTER timing bzw. die Priorität.
    Beide Karten TT-FF und sata sind busmaster. Imho muß man es hinbekommen, daß die busmaster-priorität der TT-FF höher ist als die aller anderen Karten.


    Bin gerade auf folgenden Artikel gestoßen, der das Problem erklärt - aber nicht löst :(
    http://linux.derkeiler.com/Mai…/Kernel/2003-09/7761.html



    Frage: Wie kann man Busmaster-Prioritäten in Linux anzeigen und ändern ?


    Grüße
    Ralf


    VDR - Die 'Killerapplikation' die mich zu Linux gebacht hat ;)

    Neues yaVDR HD-System ging am 20.12.2013 in Betrieb :)
    yaVDR 0.7-ansible im Aufbau ab Jan. 2024.

    3 Mal editiert, zuletzt von RalfDietz ()

  • Hallo zusammen,


    hatte einen ähnlichen Effekt auf meinem ME6000 (-> VIA Chipsatz). Habe zunächst alle unnötigen irq's (Soundkarte, zweiter IDE controller, ...) deaktiviert und viel mit setpci experimentiert. Irgendwann habe ich dann aus Verzweiflung die Latency bei allen devices auf 0 gesetzt ("setpci -v -s *:* latency_timer=0" !? - muß ich nochmal zuhause genauer nachschauen). Seither sind bei mir die ekelhaften grünen Klötzchen Vergangenheit...

    Debian VDR ("jessie") nach e-Tobi's Anleitung, ASUS AT3IONT-I Deluxe, TeVii S470 an einem Sony KDL-32EX705

  • Zitat

    Original von nipf
    Hallo zusammen,


    hatte einen ähnlichen Effekt auf meinem ME6000 (-> VIA Chipsatz). Habe zunächst alle unnötigen irq's (Soundkarte, zweiter IDE controller, ...) deaktiviert und viel mit setpci experimentiert. Irgendwann habe ich dann aus Verzweiflung die Latency bei allen devices auf 0 gesetzt ("setpci -v -s *:* latency_timer=0" !? - muß ich nochmal zuhause genauer nachschauen). Seither sind bei mir die ekelhaften grünen Klötzchen Vergangenheit...


    Hi,


    Gratulation, daß Du es geschafft hast! Es gibt also auch Hoffnung ;)


    Das Kommando funktioniert, so wie von Dir angegeben.
    Bei mir bewirkt Latency = 0 "grünen Schnee" auch ohne I/O auf der sata-Platte. Normalerweise habe ich "Grüne Streifen" (Bei latency = 32).


    Wenn Busmaster-Prioritäten und Auswirkung von Lateny verstanden werden, halte ich ein Lösung für denkbar. Trail & Error halte ich für wenig aussichtsreich, das könnten hunderte Kombinationen sein :-\


    Daher hast Du echt Glück gehabt - Gratulation!


    Latency erklärt:
    http://www.mythtv.org/wiki/index.php/PCI_Latency
    http://www-128.ibm.com/developerworks/library/l-hw2.html


    Sammlung von threads, die das problem behandeln:
    http://osdir.com/ml/drivers.dvb/2003-07/msg00604.html


    Grüße
    Ralf

    VDR - Die 'Killerapplikation' die mich zu Linux gebacht hat ;)

    Neues yaVDR HD-System ging am 20.12.2013 in Betrieb :)
    yaVDR 0.7-ansible im Aufbau ab Jan. 2024.

    7 Mal editiert, zuletzt von RalfDietz ()

  • Hi,


    schade, hätte ja klappen können... ich dachte, daß ich diesbezüglich auf Entwicklungsstufe 4 (=es geht und ich weiß warum) wäre... bin aber dann doch wohl nur auf 3 (es geht, aber ich weiß nicht warum) :( .Von daher hast Du hast natürlich absolut recht, man sollte hinter die Geheimnisse des PCI - Mysteriums kommen (PCI Latency, IRQ Prioritäten, ...), damit wäre dann wohl vielen geholfen.


    Ich hatte mir die Latenz für meine Technotrend damals genau ausgerechnet (max Latency ist da angegeben mit 3750ns, da kam ich dann auf einen Wert von latency_timer=128). Leider hatte das eben nicht den erwünschten Effekt.

    Debian VDR ("jessie") nach e-Tobi's Anleitung, ASUS AT3IONT-I Deluxe, TeVii S470 an einem Sony KDL-32EX705

  • @RalfDietz
    Bei deinem Nforce-Board kenne ich mich leider nicht so aus.


    lspci -vxxx nützt mir nur bei einem KT133(A) Board was, die sind da besonders anfällig und ich musste mich (gezwungener Massen) schon mal damit beschäftigen.
    (VIA-Chipsätze bremsen PCI-Steckkarten aus)


    Generell würde ich aber mal versuchen die PCI-Latency der FF zu erhöhen.

    Gruss
    SHF


  • Zitat

    Original von SHF

    Was ist das für ein Mainboard?
    Ich wette eins mit KT133 oder KT133A Chipsatz ;D.


    Wenn ja, dann poste bitte mal was "lspci -vxxx" ausgibt.


    SHF: Die Wette hast du gewonnen: Gigabyte GA-7ZX mit VIA KT133 Chipsatz.


    Und hier lspci -vxxx (s. Anhang)


    nipf 7 RalfDietz:

    Code
    setpci -v -s 00:0d.0 latency_timer=0

    gibt bei mir auch nur noch grünen Schnee, ab Werten von >= 4 sind's dann "nur" noch die grünen Streifen bei hoher Last auf dem PCI-Bus. Wobei die Streifen bei hellen Bildbereichen ja übrigens magenta sind.

  • Ich hänge mal meine /etc/rc.local an (das script wird beim Systemstart ausgeführt).


    #!/bin/sh -e
    #
    # rc.local
    #
    # This script is executed at the end of each multiuser runlevel.
    # Make sure that the script will "exit 0" on success or any other
    # value on error.
    #
    # In order to enable or disable this script just change the execution
    # bits.
    #
    # By default this script does nothing.


    rmmod uhci_hcd
    echo 1 > /proc/sys/vm/laptop_mode
    setpci -s *:* latency_timer=0
    #setpci -v -s 00:14.0 latency_timer=80
    #setpci -v -s 00:0d.0 latency_timer=0
    #setpci -v -s 00:11.1 latency_timer=80
    exit 0


    ich entlade den USB - Treiber uhci_hcd (um shared interrupts zu vermeiden), setze den laptop_mode und setze eben alle pci-devices auf latency_timer=0 (die auskommentierten setpci's waren meine vorigen Versuche). Meine Interrupt-Verteilung sieht folgendermaßen aus:


    ctvdr:/# cat /proc/interrupts
    CPU0
    0: 103774 XT-PIC-XT timer
    1: 2 XT-PIC-XT i8042
    2: 0 XT-PIC-XT cascade
    3: 300 XT-PIC-XT lirc_serial
    8: 0 XT-PIC-XT rtc
    9: 0 XT-PIC-XT acpi
    10: 0 XT-PIC-XT ehci_hcd:usb4
    11: 590401 XT-PIC-XT saa7146 (0)
    14: 5982 XT-PIC-XT ide0
    15: 2120 XT-PIC-XT eth1
    NMI: 0 Non-maskable interrupts
    LOC: 0 Local timer interrupts
    TRM: 0 Thermal event interrupts
    SPU: 0 Spurious interrupts
    ERR: 0
    MIS: 0


    Im Anhang dann noch meine lspci -vxxx Ausgabe.

  • Hab's auch mal versucht:


    Vorher:


    Dann:

    Code
    bender ~ # rmmod uhci_hcd
    bender ~ # rmmod ehci_hcd


    Ergibt:


    Nach

    Code
    bender ~ # echo 1 > /proc/sys/vm/laptop_mode
    bender ~ # setpci -s *:* latency_timer=0

    sieht's dann bei mir aus wie in latency-0.jpg (Ausschnitt).


    Nicht grade eine Verbesserung. Was soll der laptop_mode eigentlich bewirken?

  • Zitat

    Original von womble
    Nach

    Code
    bender ~ # echo 1 > /proc/sys/vm/laptop_mode
    bender ~ # setpci -s *:* latency_timer=0


    sieht's dann bei mir aus wie in latency-0.jpg (Ausschnitt).

    Ich würde die PCI-latency eher erhöhen, bis die Karten ihren Puffer komplett leer schreiben können und das auch nur bei den Video-Karten.


    Für eine SAA7146-Karte sollte das so klappen (auf eigene Gefahr, wie immer):

    Code
    setpci -d 1131:7146 latency_timer=FF

    Eventuell ist es sinnvoll die Latency in Schritten zu erhöhen, zB.: 40, 80, FF (dezimal: 64, 128, 256)
    Es sollte übrigens nach dem laden der Module gemacht werden, da sie die Einstellungen eventuell auch ändern.


    womble:
    Dein lspci sehe ich mir noch an, hoffe ich kommen am WE dazu.

    Gruss
    SHF


  • Zitat

    Original von SHF
    Ich würde die PCI-latency eher erhöhen, bis die Karten ihren Puffer komplett leer schreiben können und das auch nur bei den Video-Karten.


    Für eine SAA7146-Karte sollte das so klappen (auf eigene Gefahr, wie immer):

    Code
    setpci -d 1131:7146 latency_timer=FF

    Eventuell ist es sinnvoll die Latency in Schritten zu erhöhen, zB.: 40, 80, FF (dezimal: 64, 128, 256)


    Hab schon alle möglichen Werte probiert. Von 0 bis 7 hat's generell Schneetreiben, darüber die besagten gründen Streifen, wenn viel auf dem PCI-Bus los ist.


    Zitat

    Original von SHF
    womble:
    Dein lspci sehe ich mir noch an, hoffe ich kommen am WE dazu.


    Gerne, aber nur, wenn's Dir Spaß macht. Ich für meinen Teil kann mit den gelegentlichen Störungen leben, außerdem konnte mein Rechner letzte Woche seinen 7. Geburtstag feiern (wieviel ist das eigentlich in Menschenjahren? ;) und geht dem Ruhestand entgegen. Ich dachte bloß, vielleicht kann ich nipf und RalfDietz noch ein bisschen helfen.


    Gruß, Bernd

  • womble:
    Wenn du willst kannst du es mal mit den beiden folgenden setpci-Befehlen versuchen:

    Code
    setpci -v -d 1106:0305 0x75=0x08 #oder: 0x88
    setpci -v -d 1106:0305 0x76=0x72 #oder: 0x62

    Die Befehle gehen nur auf KT133 und KT133A. Anwendung, wie immer, auf eigenes Risiko.


    Die alternativen Werte sind für den Fall, dass es zu Problemen kommt.

    Gruss
    SHF


Jetzt mitmachen!

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