Posts by cooljay032

    Ja hatte auch mit der Version 1.7 Probleme und dann wieder zurückgedreht. Es gibt mittlerweile ja ne neue (1.18) die iss aber noch nicht ins Arch Repo gewandert. Dann könnte ich das nochmal testen...


    P.S.: Jepp nutze Skindesigner

    So bin endlich mal dazu gekommen nen Backtrace zu erstellen, Absturz wie gesagt mit dem neuen X Version 1.20.4.

    Code
    1. Apr 01 20:15:52 vdr vdr[14427]: X Error of failed request: GLXBadContextTag
    2. Apr 01 20:15:52 vdr vdr[14427]: Major opcode of failed request: 150 (GLX)
    3. Apr 01 20:15:52 vdr vdr[14427]: Minor opcode of failed request: 5 (X_GLXMakeCurrent)
    4. Apr 01 20:15:52 vdr vdr[14427]: Serial number of failed request: 99
    5. Apr 01 20:15:52 vdr vdr[14427]: Current serial number in output stream: 99

    Mich wunderts ja dass sonst keiner sone Probleme hat, hoffe ich bin da kein tragisches Einzelschicksal... :/

    Ich habe auch den Xorg 1.20.4 im Einsatz und da funktioniert das. Allerdings compiliere ich das plugin neu wenn ich den xorg aktualisiere.

    Problem mit X leider auch nach recomp noch da...


    Läuft die Kombi bei einem der vdr4arch Jungs??


    Ich habe das PKGBUILD mal so angepasst, dass "cuda" nun eine "makedepend" ist. "namcap" hat kein Problem damit (keine nicht aufgelösten Ahängigkeiten). Bitte mal testen. Wenn das passt, dann könnte man das Monster "cuda" zumindest auf dem "Zielsystem" weglassen.

    Habs das neue Build getestet, läuft einwandfrei OHNE installiertes cuda, prima!


    Lars

    Ich habe auch den Xorg 1.20.4 im Einsatz und da funktioniert das. Allerdings compiliere ich das plugin neu wenn ich den xorg aktualisiere.

    Hatte nach dem "großen" Update eigentlich alles bzgl. VDR recompiliert, werd aber nochmal prüfen dass da nix schiefgegangen iss.

    Ansonsten, du hast ja Suse, könnts evtl. noch was Arch-spezifisches sein. Unwahrscheinlich aber naja...

    Nabnd,


    nach Update der xorg Pakete (1.19.6 auf 1.20.4) läuft das plugin nicht mehr. Sobald ich per ATTACH starte schmiert mir der VDR ab...

    Downgrade xorg-server, xorg-server-common und xorg-server-xvfb auf die 1.19'er Version und alles ist gut. Nutze aktuelles Arch mit den aktuellen vdr4arch Paketen.


    Lars

    Hi,


    bin zur Zeit auch auf dem Suche nach nem gescheiten, bezahlbaren 65'er und der XE7096 würde gut in mein Beuteschema passen. Kannst du zum Thema Laufschrift mittlerweile mehr sagen?

    Kurioser weise sind die Laufschriften sind mal super sauber, mal nicht und das wechselt hin und her. Das Tritt aber auch bei meinem anderen TV auf.

    Sieht so aus, als ob irgendwo die Fieldorder durcheinander gerät.

    Bei Gelegenheit muss ich mal schauen, ob der VDR die Ursache ist, oder ob es auch bei einem anderen Zuspieler auftritt.

    Da scheint ffmpeg technisch noch was zu fehlen.


    als würdest du softhddevice-openglosd detached starten lassen

    Jepp so ist es!


    Code
    1. Thread 1 "vdr" received signal SIGSEGV, Segmentation fault.
    2. 0x00007fffddda67c3 in cFlatBaseRender::TopBarCreate() () from /usr/lib/vdr/plugins/libvdr-skinflatplus.so.2.4.0
    3. (gdb) bt full
    4. #0 0x00007fffddda67c3 in cFlatBaseRender::TopBarCreate() () at /usr/lib/vdr/plugins/libvdr-skinflatplus.so.2.4.0
    5. #1 0x00007fffddddae8f in cFlatDisplayMenu::cFlatDisplayMenu() () at /usr/lib/vdr/plugins/libvdr-skinflatplus.so.2.4.0
    6. #2 0x00007fffddd9d4fb in cImageCache::PreLoadImage() () at /usr/lib/vdr/plugins/libvdr-skinflatplus.so.2.4.0
    7. #3 0x00007fffddde6ab8 in cPluginFlat::Start() () at /usr/lib/vdr/plugins/libvdr-skinflatplus.so.2.4.0
    8. #4 0x0000555555673e14 in cPluginManager::StartPlugins() ()
    9. #5 0x00005555555f2831 in main ()

    Reihenfolge der Plugins so geändert, dass skinflatplus als letztes geladen wird?

    Ja, dann fliegt der VDR bei Start ab :/

    Moin moin,


    da die Kiste einfach hängen bleibt gibts leider kein Backtrace. Kann ich denn sonst irgendwas beisteuern,testen,...?


    Ich frage mich gerade, ob bei dem Skin durch das Initialisieren der Bibliotheken vor der TrueColorOSD-Abfrage den Start zufällig ausreichend lange verzögert wird, bis das Ausgabe-Plugin initialisiert wurde.

    Iss das evtl. schon die richtige Richtung...?

    Moin!


    Mein Lieblingsskin verweigert leider die Mitarbeit seitdem ich softhddevice/softhdcuvid mit OPENGLOSD verwende. Ist der Plugin aktiviert startet der VDR erst gar nicht, hab ich hier auch kurz beschrieben. Andere Skins (LCARS, EnigmaNG, Designer) laufen ohne zu mucken. Hab nur ich das Problem, bzw. hat das überhaupt irgendjemand am Laufen??


    Lars