Kein xine/vdpau nach emerge world

Gute Idee mit dem neuen Thread... Nachdem herrlado (siehe anderer Thread) ebenfalls Probleme mit vdpau und xine nach einem Systemupdate hat...

Bei mir startet der VDR inkl. xine-plugin und xine-ui ganz normal, jedoch friert das Bild sofort ein, sobald ich umschalte. Der Sender spielt dabei keine Rolle. Mein System: siehe Signatur. Habe mehrere nvidia-Treiber und xine-lib-Kombis ausprobiert. Nichts... Leider keine Fehler im Log. Werde mal eine alte glibc ausprobieren...

Grüße, caps!

Moin,

glibc könnte sein, habe ich die Tage nämlich NICHT gemacht, bei mir läuft alles wie gehabt. Ansonsten habe ich bis auf die glib und glibc alle Updates mitgenommen.

VDR ist aus portage, xine-lib/xine-ui/vdr-xine aber selbst kompiliert, evtl. würde mich so das Problem auch gar nicht treffen ...

Soweit, Matthias

Hmmm...

* Messages for package sys-libs/glibc-2.10.1-r1:
 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.10.1-r1 failed:
 *   aborting to save your system

Schon wieder was gelernt...

Zitat

Originally posted by caps!
Gute Idee mit dem neuen Thread... Nachdem herrlado (siehe anderer Thread) ebenfalls Probleme mit vdpau und xine nach einem Systemupdate hat...

Bei mir startet der VDR inkl. xine-plugin und xine-ui ganz normal, jedoch friert das Bild sofort ein, sobald ich umschalte. Der Sender spielt dabei keine Rolle. Mein System: siehe Signatur. Habe mehrere nvidia-Treiber und xine-lib-Kombis ausprobiert. Nichts... Leider keine Fehler im Log. Werde mal eine alte glibc ausprobieren...

Grüße, caps!

+1

Zusätzlich: Ich hatte zunächst xine-lib aktualisiert. Damit lief noch alles ok. Damit will ich sagen, es liegt nicht an xine-lib

Was ich spannend finde, ich hatte dropped frames Problem. Aus diesem Grund habe ich letztendlich die beste Driver(aus meiner Signatur) gewählt. Nun ist es auf dem Portage verschwunden. Ich will nun es von dem HomePage ziehen und ausprobieren.

OK, mit dem Alten Treiber das selbe -> Umschalten, einfrieren, abstürzen

Moin,

hast Du mal mit revdep-rebuild rückwärts neu gebaut? Es gibt da spezielle Schalter für solche lib-Änderungen welche genau das sind weiß ich aber aus dem Kopf nicht. Kann ich heute Abend nachreichen.

Matthias

Hi,

bin auch ein Gentoo-User, habe auf meinem HTPC global das Keyword ~amd64 an, installiere immer nur ebuilds, wenn auch so manche aus lokalem overlay. Mein Problem ist nicht so schlimm dass nichts mehr geht, sondern nur dass ich bei 1080i-Sendern kein temporal-Deinterlacing unter VDPAU mit meiner Onboard GeForce8300 mehr hinbekomme, was früher definitiv ging. Ich vermute mal auch, dass glibc daran schuld hat, da auch XBMC das Problem hat (egal ob 9.11, pvr-testing2 oder trunk kompiliert mit externem ffmpeg-0.6 oder internem ffmpeg). Wahrscheinlich werde ich mich mal demnächst ranmachen ein glibc-ebuild so zu faken, dass dennoch ein "downgrade" möglich ist auf die zuletzt verwendete Version während der WM als alles noch ging).

Cheers,
Lucian

Ich kann hier nichts negatives über das letzte update (incl glibc-2.11.2) sagen, läuft wie gewohnt.
Isn x86 system nur der VDR-Krempel is teilweise ~x86.

Kernel:2.6.34
VDR: 1.7.12
Xine-lib/xineliboutput: 9999.ebuilds ca 14 tage alt

Hallo,

ich bin durch Downgrade von glibc-2.11.2 auf glibc-2.11 das zerfranste Deinterlacing bei 1080i-Sendern los. Ich habe lediglich in meinem lokalen Overlay ein Ebuild der 2.11-er Version nach 2.11.2-r1 kopiert und intern ein bisschen die Versionen auf exakt 2.11 angepasst, da hat sich Portage nicht mehr gegen ein Downgrade wehren können. Habe allerdings auch die Durchflieger-Patches der xine-lib/vdr-xine minimal von v13 auf v13.2 geupgradet, aber die sind es definitiv nicht, denn v11 ging schon ganz gut mit der älteren glibc (die ich vor paar Wochen geupgradet hatte).
Das gibt definitiv einen Bugeintrag von mir bei Gentoo.
Wenn Ihr für Euer Problem das auch probieren wollt, anbei mein gepimptes Ebuild.

Schönen Gruß,
Lucian

Also ich habe jetzt das ebuild Zoolook genommen. Leider nichts gebracht. xine schmiert immer ab, wenn ich umschalte Auch den Kernel 2.6.34 habe ich ausprobiert. Nichts...

Nun läuft xinelibout erst einmal. Meine Frau fragt schon, warum sie den Fernseher nicht gucken kann, wenn sie bügelt Ich habe keine Antwort

Hi,

vielleicht liegt es an irgendwelchen Unterschieden an den tatsächlich verwendetetn ebuilds oder patches? Ich poste da mal meine ebuilds und patches. Diejenigen unter _patches/vdr werden dank hd_brummy's und zzam's eclass den jeweiligen vdr- oder vdr-plugin Versionen ohne Änderungen der Ebuilds verpasst, sofern die Umgebungsvariable VDR_LOCAL_PATCHES_DIR auf eben dieses Oberverzeichnis zeigt (muß nicht zwangsläufig innerhalb des Overlays liegen, bei mir ist es aber tatsächlich so). Ich habe etwa in make.conf:

VDR_LOCAL_PATCHES_DIR="/usr/portage_overlays/local/my_overlay+patches/_patches/vdr"

stehen.

Cheers,
Lucian

Servus,

habe auch das ebuild von Zoolook emerged. Leider auch bei mir keine Änderungen. Habe alle Pakete nochmals mit der "neuen alten" glibc kompiliert. Selbes Problem. Habe meine gcc-Version von 4.3.irgendwas auf 4.4.3 upgedated, nochmal alles kompiliert. Selbes Problem... Da muß ich leider aufgeben. Sehr schade. Würde das xine-plugin sehr gerne weiterbenutzen. Werd mir vielleicht nochmal das xineliboutput-plugin anschauen...

Grüße, caps!

Danke für den Denkanstoss, Razorblade! Habe mal alles was mit xine-lib und xine-ui zu tun hatte entfernt (in /usr/lib/ usw.) und mir dann das vdr-xine Overlay eingebunden. Da gibt es ja die xine-lib aus dem hg-Repo als ebuild. Und siehe da, funktioniert wieder. Bisher hab ich mir xine-lib, xine-ui und das komplette VDR-Zeugs selbst kompiliert.

Habe dann das ebuild angepasst und zum Test mal den Patch von durchflieger (mal mit, mal ohne stream-start-Patch) eingebunden. Dann hatte ich wieder die Hänger beim Umschalten. Bei mir liegt es definitiv an dem Patch. Wobei ich eher den Verdacht habe, daß da was mit dem Patch für das vdr-xine-Plugin nicht stimmt. Aber da schreibe ich was im durchflieger-Thread dazu...

Endlich wieder einen funktionierenden VDR... puh... Danke Euch!

Grüße, caps!

So, jetzt hat es mich auch erwischt:

- Gentoo, selbst compilierte Xine-Lib, Xine-UI, VDR mit xine-plugin.

Kein Bild mehr nach einem emerge -vu --deep world. Nach dem davor ausgeführten emerge -vu world lief er noch. Im Log wie hier beschrieben ein volllaufender Puffer und dann der watchdog. Das System wurde relativ regelmässig so alle 6 bis 8 Wochen aktualisiert.

Alle Reparaturversuche, auch die hier im thread beschriebenen Lösungsansätze (mit Ausnahme des Ausweichens auf das vdr-overlay, das wollte ich nicht ...) schlugen fehl. revdep-rebuild, emerge -e world (neu bauen des Gesamtsystems) und des Kernels hatten ebenfalls keinen Effekt.

Musste letztendlich ein Komplettbackup einspielen. Glücklicherweise hatte ich durch einen kürzlich erfolgten Plattentausch noch ein funktionsfähiges System in Reserve.

Und jetzt? Trau mich irgenwie nicht mehr, ein beherztes "emerge -vu world" abzusetzen, bis klar ist wo es her kommt.

Schätze, ich muss jetzt erst mal etwas an meiner backup-Strategie feilen, damit ich im Bedarfsfall das Gesamtsystem auf Knopfdruck restoren kann :-((

Grüße, Peter

Ich bin halt auf xineliboutput Plugin umgestiegen und bereue es auch nicht,
dennoch werde ich demnächst ausprobieren ob vdr-xine wieder läuft.

Ich nutze nach dem restore weiterhin xine / xine-plugin, hab mir allerdings die glibc "gepinnt". Seitdem keine Probleme mehr. Wobei das auch keine Lösung "für immer" ist.

xineliboutput läuft bei mir irgendwie nicht vernünftig.

Razorblade: Die Probleme sind zwar unschön, aber das Prinzip "gentoo" solltest Du deswegen nicht gleich in Frage stellen. Meine Gentoo-Installation ist jetzt fast 6 Jahre alt und schon über diverse hd's umgezogen, und sie läuft noch immer. Wegen der xine-probleme das war mein erster restore ...

Grüße, Peter

Hallo,

habe nun auch Probleme, die es früher nicht gab:

xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
[xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
[xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
[xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
[xine..put] cXinelibServer::Play Write/Queue error (TCP/PIPE)
[xine..put] Closing connection 0
[xine..put] Client 0 connected:

Habt Ihr schon Lösungen?

G. Roland