Stimmt der Patch fehlt, aber der ist nur fuers grabben zustaendig, und dabei flackert dann das TV Bild.
Das Kriseln ist nun aber weg, dank dem alter-vdpau patch fuer die xine-lib. Ohne diesen siehts schlecht aus.
[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support
-
-
@ Helau und R2D2
wenn Ihr solche Hardwareprobleme habt, habt Ihr schonmal den Nvidia-290.03 versucht?
Vielleicht bringt der ja etwas Besserung.
Gruss, Ralf
-
Den hab ich doch bereits und dank alter vdpau patch ists jetzt auch ok ...
-
Hallo,
Hat jemand von Euch auch dieses Problem:
Irgendwann bleibt das Bild + Ton kurz stehen um dann nach eins zwei Sekunden im "Schnelldurchlauf" wieder normal weiter zu laufen.
Es tritt selten, aber regelmäßig auf. Manchmal Stundenlang nicht ein Frame verloren und dann kommt es kurz zu diesem Aussetzer.
Ich habe schon an allen möglichen Parametern geschraubt, weg ist es aber nicht.
Eventuell könnte sich mal jemand von den Experten dazu äußern, wo das Problem liegt (nvidia, xine)Peter
-
Siehe auch VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand?
und
[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support
nvidia Treiber 195.30 hilft. -
pixelpeter: Das ist der nvidia Treiber.
-
nvidia Treiber 190.35 hilft.
Und wie installiert man diesen mit kernel 3.x und xorg-server 1.9.x ? -
Der neue Kernel ist kein Problem, siehe auch
[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support
aber neuere xorg server möglicherweise schon.
Ich hab noch Suse 11.3, da ist glaub ich xorg server 1.8.
Welches der letzte xorg server ist, mit dem es noch geht, weiß ich nicht.
Edit: Auf Suse 11.4 ist xorg 1.9, da war bei meinen Versuchen der 256.53 der älteste mögliche. -
Ich hab noch Suse 11.3, da ist glaub ich xorg server 1.8.
Ich habe auch eine Suse 11.3, es es die 1.8
CodeX.Org X Server 1.8.0 Release Date: 2010-04-02 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX
Seltsam - bei Nvidia wurde verschlimmbessert, auf meinem Testsystem habe ich den 290.03 und ich meine auch, das die verlorenen Frames dort öfters zu sehen, als an meinem produktiven System mit älterem Treiber -
@ Helau und R2D2
wenn Ihr solche Hardwareprobleme habt, habt Ihr schonmal den Nvidia-290.03 versucht?
Vielleicht bringt der ja etwas Besserung.
Gruss, Ralf
Ich habe das Problem nun duch andere, nicht Zotac gf9300(!), Hardware gelöst.BTW: Ich verwende Nvidia-290.06
-
Die GrabImage-Funktion vom VDR führt bei allen neueren Nvidia-Treibern in Verbindung mit xine-lib/xineliboutput zum Bildflackern. Es sieht so aus, als würde das gegrabbte Bild als schwarze Frame auf dem TV ausgegeben. Der letzte funktionierende Nvidia-Treiber war 275.09.07. Der Effekt tritt z.B. beim Live-Plugin auf.
Ist für das Problem eine Lösung in Sicht?
Gruß
e9hack
Ich bekomme das Problem mit dem 285.05.09 auch nachvollzogen. Ist offenbar ein Problem des nvidia Treiber.
Jemand müsste sich mal die Mühe machen zu testen welches denn die erste Version des Treiber ist ab der das
Problem auftritt. Dann könnte man vieleicht mal bei nvidia einen Problemreport auslösen.Gruss
durchflieger -
Alle Treiber größer als
190.35195.30 haben das Problem. rnissl hatte da mal was auf dem NVidia-Board gepostet, nur konnten die Jungs von der NV-Truppe das nicht nachvollziehen. Irgendwie ist das dann im Sand verlaufen.Gruß
iNOB -
Alle Treiber größer als 190.35 haben das Problem. rnissl hatte da mal was auf dem NVidia-Board gepostet, nur konnten die Jungs von der NV-Truppe das nicht nachvollziehen. Irgendwie ist das dann im Sand verlaufen.
Gruß
iNOB
Weiter oben war vom 195.30 als letzten "guten" Treiber die Rede, was ist da nun richtig ? -
Ups stimmt! Grad nochmal nachgeschaut. Ich korrigiere: Alle Treiber größer als 195.30 haben das Problem.
Gruß
iNOB -
Ups stimmt! Grad nochmal nachgeschaut. Ich korrigiere: Alle Treiber größer als 195.30 haben das Problem.
Gruß
iNOBIhr verwechselt da was. In meinem Posting meinte ich das Problem mit dem flackern des Bild während die grab image Funktion im Hintergrund aktiv ist.
-
Hallo
Mit aktueller xine-lib und xine-ui hab ich mit bei SD das Problem dass er sich beim Springen 5-10 Sekunden Zeit laesst.
Im Syslog tauch dann immer ein "clear" Eintrag auf.
Das war z.B. svdrpsend hitk yellow , es daeuerte 21 Sekunden bis der Befehl ausgefuehrt wurde.CodeNov 07 22:55:45 [vdr] [26612] connect from 127.0.0.1, port 60517 - accepted Nov 07 22:55:45 [vdr] [26612] closing SVDRP connection Nov 07 22:56:06 [root] Clear(40)! Nov 07 22:56:06 [vdr] [32603] cVideoRepacker: switching to MPEG1/2 mode Nov 07 22:56:06 [vdr] [32603] cVideoRepacker: operating in MPEG1/2 mode
Mit xineliboutput besteht das Problem nicht, dafuer hat das andere Macken -
Ihr verwechselt da was. In meinem Posting meinte ich das Problem mit dem flackern des Bild während die grab image Funktion im Hintergrund aktiv ist.
Der letzte funktionierende Treiber ist 275.09.07. Alles drüber flackert. Da ich mit meinem Aurora-Plugin auf ein funktionierendes Grabbing angewiesen bin, hätte ich da gern schnellstmöglich eine Lösung.
Gruß
e9hack -
Hallo,
Mit aktueller xine-lib und xine-ui hab ich mit bei SD das Problem dass er sich beim Springen 5-10 Sekunden Zeit laesst.
Im Syslog tauch dann immer ein "clear" Eintrag auf.
Das war z.B. svdrpsend hitk yellow , es daeuerte 21 Sekunden bis der Befehl ausgefuehrt wurde.
naja, hier wird schneller gesprungen (vdr-xine) als ich die Tasten (über ssh) drücken kann...Code
Display MoreNov 7 23:25:08 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [2914] connect from 127.0.0.1, port 58906 - accepted Nov 7 23:25:08 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [2914] connect from 127.0.0.1, port 58907 - accepted Nov 7 23:25:08 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode Nov 7 23:25:08 hdvdr vdr: [2914] connect from 127.0.0.1, port 58908 - accepted Nov 7 23:25:08 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode Nov 7 23:25:09 hdvdr vdr: [2914] connect from 127.0.0.1, port 58909 - accepted Nov 7 23:25:09 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode Nov 7 23:25:09 hdvdr vdr: [2914] connect from 127.0.0.1, port 58910 - accepted Nov 7 23:25:09 hdvdr vdr: [2914] closing SVDRP connection Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: switching to MPEG1/2 mode Nov 7 23:25:09 hdvdr vdr: [3015] cVideoRepacker: operating in MPEG1/2 mode
Gruß
Tomas -
naja, hier wird schneller gesprungen (vdr-xine) als ich die Tasten (über ssh) drücken kann...
Das ist schoen fuer Dich, nuetzt mir aber wenigMit xineliboutput springts auch schnell, und unter HD auch, aber nicht mit xine und SD.
Da bei xineliboutput oefters mal der Ton fehlt ist dies aber keine Alternative.
Es liegt wohl an der Kombination Chipsatz Treiber xine-lib xine plugin.
Leider gibts fuer den 9300er ne Menge Bugreports, aber an Treiber und Chip alleine kann es nicht liegen.
In der vorletzten Version von gen2vdr war ebenso der 275.09.07 drinne und damit gab es die Probleme nicht, da hat sich wohl was in der xine-lib verschlimmbessert.Es waere gut zu wissen woher dieser log Eintrag stammt:
-
Das ist schoen fuer Dich, nuetzt mir aber wenig
Ich weiß, war schon etwas provokativ, sorry ;)... ich wollte aber eigentlich nur zeigen, dass es auch anders geht....Es liegt wohl an der Kombination Chipsatz Treiber xine-lib xine plugin.
Bei mir läuft das übrigens auf nem Asus P5N7A-VM, auf dem ja auch ein GeForce 9300 verbaut ist. xine-lib, xine, vdr-xine, VDR alles aktuell, allerdings seit fast zwei Jahren mit dem NVIDIA-195.30, Kernel ist auch schon etwas betagtund die Basis wurde vor zweienhalb Jahren installiert. Aber ich sehe das absolut pragmatisch...warum soll ich mich mit neuen Treibern etc rumärgern, wenn diese Kombination absolut rockstable läuft...
das xine-log meldet nichts in der Zeit zwischen dem Triggern des Sprungs und dem Sprung selbst?Gruß
Tomas -
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!