[0.3] Schnee in dunklen Flächen

Zitat

Original von wwoody

Es ist einfach nicht DIE Lösung. Eigentlich ist es nur ein sehr, sehr "dirty" Workarround. Ich verwende es weil es bei MIR zum gewünschtem Ergebnis führt, sonst würde ich wieder auf die v. 256.53 umsteigen, sobald nur die geringsten Probleme wieder auftauchen.

Heute habe ich aus versehen den Treiber 270.18 installiert. Bisher ist kein Schnee aufgetaucht.

Zitat

Original von Tuxi70
Heute habe ich aus versehen den Treiber 270.18 installiert. Bisher ist kein Schnee aufgetaucht.

diese version hat trotzdem den bug und tritt auch auf.

Zitat

Original von gda
[UPDATE1]Okay, das geht wohl auch, über apps files.
Dann also noch mal explizit die Frage: Was wäre der Benefit beim Wechseln von Openbox auf Fluxbox?[/UPDATE1]

Gerald

Öhem, keiner. Für mich eher ein Verlußt, "fluxbox != 30bit". Torsten73 unterstellte mir keck, ich würde kein Openbox nutzen und habe deshalb mit 260.19.06 aus dem Maverick Repo kein "Schnee" gesehen ...

Daher war mein Vorschlag an Ihn, doch mal zu probieren, ob sich die Situation ändert, ..., evtl. gibt es ja einen bisher unbekannten Zusammenhang zu Gnome basierten WMs ...

Gruß
Frank

Zitat

Original von traxanos

diese version hat trotzdem den bug und tritt auch auf.

Bei mir bisher noch nicht. Oder tritt dieses Schneegestöber bei HD-Sender auf? Denn ich habe ich nur SD-Sender via Kabel.

Zitat

Original von fnu

Öhem, keiner. Für mich eher ein Verlußt, "fluxbox != 30bit". Torsten73 unterstellte mir keck, ich würde kein Openbox nutzen und habe deshalb mit 260.19.06 aus dem Maverick Repo kein "Schnee" gesehen ...

Daher war mein Vorschlag an Ihn, doch mal zu probieren, ob sich die Situation ändert, ..., evtl. gibt es ja einen bisher unbekannten Zusammenhang zu Gnome basierten WMs ...

Gruß
Frank

Alles anzeigen

Da Du eine eigene Installation lt. Fußnote einsetzt, war das nicht zu ersehen aber schön dass sich dadurch vielleicht wirklich die Ursache ein wenig eingrenzen läßt. Ich wüste auch nicht von anderen Installationen, wo dieses Problem auftritt, z.B. freevdr mit xfce. Nur könnte es auch sein, dass es mir bei der aktuellen Version noch nicht aufgefallen ist, da noch nicht im Produktiveinsatz.

Der Wechsel zu einem anderen Fenstermanager stelle ich mir aber als aufwändig vor, kann es gut verstehen, dass das yavdr Team dem nicht so ohne weiteres nachkommt und auch umsetzten kann. Das ist doch bestimmt ein recht deutlicher Eingriff ins Konzept.

Warum sollten wir auch. Ich glaube generell nicht an Voodoo was Computer angeht. Ausserdem wurde die Ursache für den Schnee ja weitestgehend eingegrenzt. Es ist nicht yavdr spezifisch, es wird in der Art und weise wie wir die Programme starten anscheinend einfacher getriggert. Die letzten Posts hören sich für mich so an als würde die Welt untergehen und das yavdr Team sollte dringend etwas dagegen unternehmen. Lieg ich falsch, wenn ich denke das es hier um Ursachenforschung geht und das Problem mit älteren Treibern gut einzudämmen ist ?

Bitte nicht persönlich nehmen: Aber der Teil mit dem WM ist für mich komplett unverständlich. Frei nach dem Motto: Ich habe mir eine Primel auf den TV gestellt, seitdem habe ich das Problem nicht mehr gehabt, vielleicht solltet ihr alle eine Primel auf den TV stellen.

Die Xine frontends räumen bei SIGTERM nicht vernünftig hinter sich auf, dabei ist das ganze sehr sensibel auf Timings beim aufräumen. Dementsprechend ist manche Hardware stärker betroffen als andere. Weiterhin sind die nvidia Treiber ab 260.xx sehr zickig und schalten bei jeder möglichen und unmöglichen Gelegenheit in den Blit Mode wo sie das Tearing mit der Xserver version und Kernel version nicht in den Griff bekommen.

Zurück zum Thema:

In Anlehnung an woody's Post:
/etc/yavdr/templates_custom/usr/bin/start-xine/80_xine

terminate () {
echo "halt" | netcat localhost 6789
}


trap 'terminate' 1 2 3 15


if [ -n "$ASPECT_RATIO" ]; then
  XINEOPTS="$XINEOPTS --aspect-ratio=$ASPECT_RATIO"
fi 


if [ "$USE_AUTOCROP" = "1" ]; then
  XINEOPTS="$XINEOPTS --post autocrop:enable_autodetect=1,enable_subs_detect=1,soft_start=0,stabilize=1"
fi 


while [ ! -e /tmp/vdr-xine/stream ] ; do sleep 0.1 ; done
/usr/bin/xine -n $XINEOPTS vdr:/tmp/vdr-xine/stream#demux:mpeg_pes

Müsste dann ja auch gehen.

Zitat

Original von steffen_b
Bitte nicht persönlich nehmen: Aber der Teil mit dem WM ist für mich komplett unverständlich. Frei nach dem Motto: Ich habe mir eine Primel auf den TV gestellt, seitdem habe ich das Problem nicht mehr gehabt, vielleicht solltet ihr alle eine Primel auf den TV stellen.

Meister nimm Du es bitte nicht persönlich, aber Du hast Dir offensichtlich noch nicht mal die Mühe gemacht die entsprechenden Posts dazu zu lesen, sonst würdest Du so etwas wohl nicht schreiben.

Weder Torsten73 noch ich haben hier irgendeinen Vorschlag für einen Wechsel des WMs gemacht noch behauptet, das würde das Problem verbessern. Das war ein Zwischen-Kommunikation der viel zu viel Aufmerksamkeit zuteil wurde und eigentlich nicht kommentiert werden müßte ...

Regards
fnu

Hallo zusammen,

wenn ihr klären wollt, ob es einen Zusammenhang mit Gnome basierten WMs gibt dann habe ich folgende Idee für euch:

Jemand, der ein Ubuntu+VDR+VDPAU System betreibt und Schnee reproduzieren kann, bräuchte im Paketmanager nur von gnome auf fluxbox umstellen.

Ich würde den Test gerne ausführen, allerdings ist meine GT210 z.Z. defekt...

Gruß
Wicky

Wicky

Lass dich bitte nicht von dem Gerede über den WM in die Irre führen, dass ist alles Voodoo. Traxanos konnte das Problem jederzeit und mit jeder Treiberversion auch komplett ohne WM, also mit nacktem X-Server produzieren. Es gibt definitiv aktuell keine Lösung für das Problem.

Gerald

Ihr habt gar keine Ahnung was das yaVDR-Team alles unternommen hat um diesen Fehler zu beheben, der wirklich gar nichts mit yaVDR zu tun hat.
Da ich zum Teil selbst daran beteiligt war, weiss ich was da alles im Hintergrund abgelaufen ist. Wieviele 100% verständliche Aussagen sind notwendig um endlich zu begreifen dass es ein Zusammenspiel ist zw. dem Nvidia-Treiber und dem Frontend. Das Frontend kann sogar der mplayer sein, den Nvidia selbst als Referenz zum Testen benutzt. Ich konnte es selbst sogar mit mplayer reproduzieren.
Und überhaupt ... Wer mit yaVDR nicht zufrieden ist, soll mal selbst sehen wie er einen HD fähigen "VDR" auf die Beine stellt. Anleitungen zu diesem Thema gibt es echt zu Hauf im Web.

//edit

Zitat

Original von gda
Traxanos konnte das Problem jederzeit und mit jeder Treiberversion auch komplett ohne WM, also mit nacktem X-Server produzieren. Es gibt definitiv aktuell keine Lösung für das Problem.

Gerald

Genau so ist es ...

Zitat

Original von gda
... dass ist alles Voodoo.

Nichtmal das, ..., es wurde nur vergessen, die Emoticons an der richtigen Stelle zu setzen, ...

Regards
fnu

Zitat

Original von gda
Wicky

Lass dich bitte nicht von dem Gerede über den WM in die Irre führen, dass ist alles Voodoo. Traxanos konnte das Problem jederzeit und mit jeder Treiberversion auch komplett ohne WM, also mit nacktem X-Server produzieren. Es gibt definitiv aktuell keine Lösung für das Problem.

Gerald

fast korrekt. tearing und schnee sind 2 verschiedene bugs was ich am anfang noch als 1 angesehen habe. daher meine damalige aussage. der overlay bug (schnee) tritt in der alten version soweit nicht auf, aber der bug des blitmode.

beide bugs sind nvidia bekannt und ist ihnen wohl auch schon mal aufgefallen. leider gibt es aber keine weiteren meldungen, ob sie an dem problem aktiv arbeiten

@all
ich mag es nicht wenn leute sagen das es geht nach dem sie 3-4 optionen aktiviert haben, denn die haben nicht alles durch getestet und haben meist nicht verstanden was im detail passiert um den fehler effektive zu testen. also der fehler ist da und bei nvidia bekannt - also bitte lasst es und machen wie Asta es gesagt hat.

Zitat

Original von steffen_bIn Anlehnung an woody's Post:
/etc/yavdr/templates_custom/usr/bin/start-xine/80_xine

Code

terminate () {
echo "halt" | netcat localhost 6789
}


trap 'terminate' 1 2 3 15


if [ -n "$ASPECT_RATIO" ]; then
  XINEOPTS="$XINEOPTS --aspect-ratio=$ASPECT_RATIO"
fi 


if [ "$USE_AUTOCROP" = "1" ]; then
  XINEOPTS="$XINEOPTS --post autocrop:enable_autodetect=1,enable_subs_detect=1,soft_start=0,stabilize=1"
fi 


while [ ! -e /tmp/vdr-xine/stream ] ; do sleep 0.1 ; done
/usr/bin/xine -n $XINEOPTS vdr:/tmp/vdr-xine/stream#demux:mpeg_pes

Alles anzeigen

Müsste dann ja auch gehen.

Steffen: funz nicht, gerade probiert ...

Zitat

Originally posted by wwoody
Steffen: funzt nicht, gerade probiert ...

danke ! Schade

Um das klar zu stellen, nicht das ich hier missverstanden wurde:

1. ich betrachte den Fehler nicht (mehr) als gravierend aber als störend. Mittlerweile gelöst ist da Tearing im oberen Drittel, das hatte ich schon lange nicht mehr.
2. falls das unter gegangen ist, der Fehler tritt bei mir nun wesentlich seltener auf, insbesondere seitdem der Treiber von der Tevii S480 gut funktioniert und dadurch auch xine (möglicherweise auch durch andere änderungen an xine) wesentlich seltener abstürzt. Es ist diese Woche bei produktiver Nutzung, d.h. mit dem VDR wurden min. 4h täglich TV geschaut, nur einmal aufgetreten. Anfangs war das täglich mehrfach.
3. Ich wollte nur helfen mögliche Rahmenbedingungen, unter deren der Fehler auftritt besser zu definieren.
4. Ich persönlich mag es auch nicht den Fehler nur zu umgehen, ich löse lieber Probleme, darum finde ich es gut, wenn man nicht deswegen von Openbox weggeht. Und ich bin mir sicher, dass das irgendwann lösen lässt.
Der Rest wurde schon gesagt und es gibt keinen Grund hier irgendjemandem Böse zu sein. Meiner Ansicht nach...

fnu,
provozieren kann man den Fehler wohl auch, indem man schnell xine killed und je nach Hardware tritt das Phänomen mehr oder weniger schnell zu tage.

Die Arbeitshypothese im yaVDR-Team für die Ursache des "Schnee"-Problems ist ja, dass die Anwendungen das Overlay nicht hinter sich aufräumen wenn sie unsanft beendet werden und der Treiber dies auch nicht für sie erledigt.
Als ein Test habe ich jetzt mal ein neues Paket für das Xineliboutput-Plugin nach unstable-vdr geladen, welches verhindert, dass VDR-SXFE unter bestimmten Bedingungen sich einfach mit einem exit verabschiedet, sondern immer erst versucht sauber zu machen. Erste kurze Tests waren viel versprechend, aber wir sind uns noch nicht sicher. Theoretisch könnte es jetzt auch zu Hängern kommen.

Um es nochmal deutlich zu machen, dies ist keine Lösung! Allenfalls ein Workaround. Das kann man schon daran merken, dass ein SIGKILL mit hoher Wahrscheinlichkeit wieder Schnee erzeugen wird.

Gerald

Was ist denn jetzt? Kriege ich vielleicht mal eine Rückmeldung?

Gerald

wen meinst Du? Ich hoffe mal nicht mich, weil ich habe auch noch ein Privatleben und bin nicht immer online

Ich würde es gerne testen, kann aber nicht weil testing und der yavdr bei meiner Schwiegerma mittlerweile produktiv läuft. Sorry ich falle also aus.

Und ich falle auch raus, da der Atom525 nur mit xine vernünftig läuft.

Aber ich bin ja nicht der einzige hier, oder

Zitat

Original von traxanos

Der X-Server muss neugestartet werden. Dieser ist direkt im openbox-Startscript integriert:

restart openbox

Das Grieseln ist dann bei mir weg, aber leider auch der Ton!

Was mache ich falsch?