Gedanken zum Thema vdpau - Nvidia-260er-Treiber - Schwarze Flächen grieseln

Ich habe die Colorspace Option eingetragen und unter den meisten Dingen die mir yaVDR so anzeigen kann kein Grieseln mehr im Schwarz gehabt.
Damit meine ich z.B. das schwarze Bild mit "yaVDR" oder das Menü.
Bei "No Signal" war meiner Erinnerung nach Grieslen im schwarz.
Wenn ich jedoch zu XBMC umgeschaltet habe, hatte ich dort immer den grünen Schnee
Ein Downgrade des Treibers brachte Abhilfe.
Wenn yaVDR mit dem alten Treiber hochfuhr, kam es dazu das manchmal schwarz OK und manchmal griesig war.
Ich könnte mir daher fast vorstellen das die Colorspace Geschichte eine falsche Fährte ist, ansonsten hätte diese doch auch bei mir das Problem in XBMC beseitigt, ist ja schließlich die gleiche xorg.conf welche genutzt wird,oder?

Hier noch meine Rückmeldung, habe erst am WE testen können:

Habe, nach der Colorspace Option, nun auch die hier angesprochenen Änderungen ebenfalls eingebaut.

Fazit:

1.) nach ColorSpace war das "grüne Geglitzere" so gut wie weg.
2.) mit den anderen Optionen habe ich jetzt kein Glitzern mehr feststellen können, Tearing ist noch da, habe aber den Eindruck, es sei weniger geworden.

Treiber ist noch der 260, ich denke aber, daß ich testweise auf den 256 zurückgehe und schaue, wie es damit ist.

Hi,

habe

VDPAU_NVIDIA_NO_OVERLAY=1

gesetzt. Seitdem kein Schnee mehr in schwarzen Flächen mit 260.19.12.

Wo muss ich VDPAU_NVIDIA_NO_OVERLAY=1 setzen? - Ist das Problem mit den weißen Punkten im schwarz bei dir immer noch behoben?

Hallo,
in der xorg.conf

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Option "VDPAU_NVIDIA_NO_OVERLAY=1"
EndSection

Gruß Rainer

Danke, aber leider bringt das nichts, nach wie vor weiße Punkte im Schwarz und jetzt mit der Option noch grüne dabei. Ich verfolge das hier weiter: [0.3] Schnee in dunklen Flächen

Lt. Signatur verwendest Du bestimmt die Onboard-Grafik? Woanders (finde den Thread hier nicht mehr) soll das Problem schlicht und einfach durch Austauschen des RAMs behoben worden sein.

BJ1

Treiberdowngrade wie hier [0.3] Schnee in dunklen Flächen beschrieben gemacht, Problem weg.

Hab jetzt mal mein xine Frontend Toggle Skript so umgebaut, dass xine per q runtergefahren wird. Statt kill xine jetzt xdotool key q ins Skript reingepackt, damit sieht das Bild auch nach Restart noch gut aus mit dem 260.19.26. Geht bestimmt noch sauberer (Window bestimmen und mitgeben) fürs erste tuts, und ist doch eigentlich sogar sauberer

steiniplatte

Danke für den Tip, habe mich auch schon lange an dem von mir verwendeten "killall" gestört. Eine Änderung stand auch schon eine Weile auf der ToDo Liste in Ablage F ...

Bei dem Keystroke per "xdotool" kann man lt. manpage keine Window-ID mitgeben ... aber man kann sie rausfinden ("xdotool search --onlyvisible --title xine" oder "xdotool getactivewindow")

Regards
fnu

Zitat

Original von fnu:
Bei dem Keystroke per "xdotool" kann man lt. manpage keine Window-ID mitgeben ... aber man kann sie rausfinden ("xdotool search --onlyvisible --title xine" oder "xdotool getactivewindow")

Vielleicht kam diese Möglichkeit erst in neuren Versionen hinzu?

Jedenfalls, scheint ein interessanter Tipp zu sein das mit xdotool, ich habe auch oft weiße Flecken auf sehr dunklen Bildbereichen, und was mich am meisten stört, sehr oft ein schwarzes Klötzchen um den Mauszeiger genau in der Mitte über xine (auch wenn ich vorher nicht XBMC oder vdr-sxfe laufen hatte). Werde mich mal mit xdotool ein wenig befassen, vielleicht lässt sich das alles hinbiegen...

Regards,
Lucian

Was mir noch aufgefallen ist, dass ich die Tearingfehler beim 260er nur unter xineliboutput habe, unter xine sind die mir bisher nicht aufgefallen.

Die Grieselflächen sind mit den letzten Updates vom yavdr 0.3 mir nicht mehr aufgefallen. Zuletzt wurde wohl öfters am xineliboutput und xinelib gearbeitet.

Beim HP 24" DVI hatte ich diese keine Grieselprobleme, jetzt neu an einem Loewe Connect Chassis L2715 waren die schwarz/weiß Klötzchen (Grieselfläche) aber teilweise massiv zu sehen. Mit ein paar mal zappen und auch wechseln zu xbmc waren die dann aber auch zwischendurch mal gar nicht zu sehen.

Zitat

Original von fnu
steiniplatte

Danke für den Tip, habe mich auch schon lange an dem von mir verwendeten "killall" gestört. Eine Änderung stand auch schon eine Weile auf der ToDo Liste in Ablage F ...

Bei dem Keystroke per "xdotool" kann man lt. manpage keine Window-ID mitgeben ... aber man kann sie rausfinden ("xdotool search --onlyvisible --title xine" oder "xdotool getactivewindow")

Regards
fnu

Alles anzeigen

Es gibt noch eine Möglichkeit bei xine:
mit "xine -n" reagiert xine auf Kommandos über das Netzwerk. (siehe man xine)
mit "echo "halt" | netcat localhost 6789" beendet man z.b. xine ganz ordnungsgemäß

Den vdr-sxfe player beim xineliboutput kann man überigens getrost mit kill SIGTERM beenden da er sich so ordnungsgemäß beendet.

Gruss
durchflieger

Zitat

Original von durchflieger
Den vdr-sxfe player beim xineliboutput kann man überigens getrost mit kill SIGTERM beenden da er sich so ordnungsgemäß beendet.

Das Problem ist, dass genau das von Upstart an vdr-sxfe gesendet wird, wenn wir auf xbmc umschalten und danach haben einige dann eben den Schnee.

Gerald

Zitat

Original von durchflieger
Es gibt noch eine Möglichkeit bei xine:
mit "xine -n" reagiert xine auf Kommandos über das Netzwerk. (siehe man xine)
mit "echo "halt" | netcat localhost 6789" beendet man z.b. xine ganz ordnungsgemäß

Ja, auch eine schöne Lösung, ein bisschen von hinten durch die Brust, aber egal, alles ist erlaubt, solange das Ziel ohne weiteres Fehlverhalten erreicht wird

Gruß
Frank

Zitat

Original von durchflieger
Es gibt noch eine Möglichkeit bei xine:
mit "xine -n" reagiert xine auf Kommandos über das Netzwerk. (siehe man xine)
mit "echo "halt" | netcat localhost 6789" beendet man z.b. xine ganz ordnungsgemäß

Den vdr-sxfe player beim xineliboutput kann man überigens getrost mit kill SIGTERM beenden da er sich so ordnungsgemäß beendet.

Gruss
durchflieger

Alles anzeigen

Das funktioniert sogar ganz gut. Habe es gerade so eingerichtet.
Bisweilen, nach ca. 20 Switches zw. xine-frontend und xbmc ist alles sauber. Kein Schnee, kein Tearing!
xine-remote lässt sich auch benutzen ...

Hallo durchflieger, Hallo wwoody

der Workaround mit Xine -n hört sich gut an...

In welchen Dateien muss ich was bitte ändere!

Eine Erklärung für einen YaVDR Newbie wäre nett!

humaxmk1
warte doch noch etwas bitte !
traxanos investiert gerade massiv zeit um rauszufinden woran es liegt.

einen "workaround" einzubauen lindert das symptom, bekämpft die ursache aber nicht.
und wer weiss .... evtl. würde die beseitigung des bugs ... sofern er einer von nvidia ist
auch andere ungeahnte vorteile bringen.

hotzenplotz5

Ich möchte niemandem auf die Füsse treten, da steckt bestimmt ein Haufen arbeit drin. Aber die Ursache ist doch offensichtlich nicht 100%ig klar und selbst wenn Nvidia reagiert wird das ein "paar Tage" dauern. Daher wäre eine Linderung, wenn sie so einfach umgesetzt werden kann, ein Weg denn man gehen sollte, da man sie ebenso einfach rückgängig machen kann.

Das Problem besteht doch jetzt und die Ansage "warte noch etwas bitte!" führt eher zu Frust, vor allem da ein wirklich kleine Anpassung bis zur Lösung eben das Problem lindern würde. Es liegt IMHO an Euch, ich wüsste gar nicht in welchen Templates man bei yaVDR die Änderung einpflegen müsste ...

Just my 2 cents.

Regards
fnu