260.19.04 (beta) for Linux x86/x86_64 released

  • Zitat

    Original von jrie


    Aber wenn ich eine 1 GB große swap Datei anlege und einbinde, geht es trotzdem.


    Gut zu wissen, dass ich nicht der einzigste bin mit dem Problem (bei 2 unterschiedlichen Systemen). Kompilierprobleme mit Libs/Headers schliesse ich inzw. definitiv aus.


    Auf System 2 funktioniert die Ausgabe per xineliboutput und vdr-sxfe. xine mit xine-ui dagegen geht mit diesem Fehler nicht. Habt Ihr dabei denselben Fehler bei xine?


    Tests mit manuellen Start von xine-ui zeigten auf, dass es in wenigen Fällen zu einer Anzeige kommt und der Fehler nicht auftritt - sehr merkwürdig. Ich habe hierzu z.B. die xine config in ~/xine gelöscht, xine mal mit xv-Anzeige (die natürlich immer klappte) gestartet und danach mit vdpau. Manchmal ging es dann, aber danach sofort wieder nicht.


    Marcus

    My VDRs:

  • Ich teste mit vdpauinfo und qvdpautest, das geht schneller, und schließt die Frage ob xine richtig kompiliert wurde aus. Es hat auch gar nichts mit xine zu tun, sondern scheitert schon beim Start von vdpau.
    Der Fehler wird in einer kommenden Version behoben sein.

  • Zitat

    Original von jrie
    Ich teste mit vdpauinfo und qvdpautest


    Die funktionieren wiederum bei mir, soweit ich mich erinnere :-/

    My VDRs:

  • Hat eigentlich niemand hier die in:
    http://www.nvnews.net/vbulletin/showthread.php?t=155276
    beschriebenen Probleme mit der 260.xx ?
    Mich wundert es echt, dass es nicht schon 'zig Threads dazu gibt, aber das Problem scheint nur in bestimmten Konstellationen aufzutreten.
    Mit yavdr 0.3 und den dort enthaltenen 260.xx Treibern habe ich keine Probleme, aber sobald ich mit meinem eigentlichen Gentoo-System boote geht gar nichts mehr, xine crashed sobald OSD angezeigt werden sollte.
    Getestet mit aktuellem xine-lib aus dem HG mit und ohne dfpatches (xine-ui und vdr-xine bzw xineliboutput danach jeweils neu kompiliert), sowohl mit vdr-xine-plugin und xine-ui also auch xineliboutput und vdr-sxfe...


    Erschwerend kommt hinzu, dass ab Kernel 2.6.36 die älteren nvidia-Treiber gar nicht mehr funktionieren, sondern nur noch >=260...

  • Hi,


    hm, ja, Gentoo ... das ist eine längere Geschichte.


    Bei mir lief Xine auch nicht mit den 260er Treibern - xbmc allerdings funktionierte. Dann ging die Sucherei los. Was mich schon immer gewundert hatte, war, dass die Durchflieger-Patches auf meinem System nicht zum Laufen zu bringen waren - Xine blieb damit beim Start sofort hängen.


    Dieses Problem konnte ich eingrenzen, das liegt daran dass der Patch den "define LOCKDISPLAY" auskommentiert.


    "if you have a buggy libX11/xcb*" steht da zu lesen. Aber was genau ist der Bug? Anderswo ist zu lesen, dass dieser Fehler ab einer bestimmten Version im Ubuntu gefixed ist. Hm, dann müsste es doch eigentlich einen Patch dafür geben ... Dazu habe ich nix gefunden.


    Möglicherweise ist das nur ein übler Würgaround:
    USE="-xcb" emerge libX11
    Danach alle verdächtigen Kandidaten neu generiert: xorg-server, xine-lib, xine-ui, libvdpau ...
    Und siehe da: Xine läuft mit Durchflieger-Patch und 260er Treibern.


    Aber Obacht geben: Ich sage "läuft", ich sage nicht "läuft rund".


    Die ganze Zeit habe ich mit "xinit -e xine", "kill", "xinit -e xbmc.bin" hin und her geschaltet. Der xorg-server wurde also jedesmal runter und rauf gefahren. Das scheint sich aber gelegentlich mit UVESAFB-splashutils-fbcondecor zu beissen. Jedenfalls blieb ab und zu der xorg-server hängen und v86d war auf 100% CPU.


    Also habe ich mich für nodm als Displaymanger entschieden - dabei bleibt der xorg-server immer oben und xine und xbmc werden abwechselnd gestartet.


    Das läuft so weit, ABER jetzt habe ich noch das Problem mit den sporadisch auftretenden "Schnee-Artefakten in schwarzen Bildbereichen".


    Von einem, der auszog, um mit Gentoo das Gruseln zu lernen ...

  • Also ein einfaches auskommentieren der LOCKDISPLAY-Änderung im DF-Patch hat für mich keine Änderung gebracht (anschließend natürlich xine-lib, xine-ui und vdr-xine-plugin neu kompiliert), hätte mich aber auch gewundert, da ich mit vanilla-xine-lib auch Probleme habe und da war das ja auch so.
    Ich habe gerade mal ein "-xcb" in meiner make.conf gesetzt und lasse jetzt ein "emerge -DauvN world" durchlaufen, ich werde berichten ob es damit klappt.
    Aber auch das würde mich wundern... ganz am Anfang (vor nem Jahr oder so?) gab es schonmal xcb Probleme, die waren aber definitiv zwischendurch weg: bis zu meinem letzten "großen" Update (xine-lib-9999 von vor ca. 2 Monaten, nvidia 256.44, damals aktuelle df-patches) lief alles mit xcb durch


    Edit: Das scheint geklappt zu haben, sogar mit dem aktuellem 260'er läufts jetzt mit Kernel 2.6.36 (und in-kernel Lirc!).

Jetzt mitmachen!

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