nOpacity 0.0.3

louis & TomJoad: Danke. Dann ist die Schleife natürlich überflüssig.

Lars: Dein Vorschlag wirkt auf mich resourcenoptimierter und eleganter, aber ich bin gerade völlig fixiert darauf diesen verdammten Thread totzuschlagen, und zu prüfen, ob er wirklich weg ist. Das muss doch möglich sein.

Gruß, Ingo

P.S.: ob es sich lohnt FadeTime + 50 zu warten? Cancel(), also Cancel(0) macht doch sofort tot... Eigentlich ist doch das Abwarten von FadeTime schon überflüssig... Stecken da irgendwelche Latenzen drin....

Wäre es sinnvoll vor dem Zerstören der Pixmaps auf Active() abzufragen?

Zitat von nvertigo

Wäre es sinnvoll vor dem Zerstören der Pixmaps auf Active() abzufragen?

Ich teste den unten angehängten Patch jetzt seit 17:05 mit der Zahnstocher blockierten tab-Taste - bis jetzt stabil. Nachdem, was Lars gerade geschrieben hat, denke ich, dass das natürlich auch nur Zufall sein kann. Aber ich hänge den Patch mal an.

Gruß, Ingo

Hi Lars,

mein vdr wird gerade benutzt. Werde morgen früh testen.

Gruß, Ingo

p.S.: Guck mal ins Log und auf die load. Sehen tue ich beim "Zahnstochertest" auch nichts, Aber das Menu wird pausenlos auf und zu gemacht.

Torsten73: guck bitte mal hier. Das Problem ist wohl eher extrecmenu und 1.7.32 Umfeld angesiedelt.

Gruß, Ingo

Hallo Lars,

leider hats mit Deinem Patch recht schnell geknallt. Ich habe die Tab-Taste für vieleicht 15 oder 20 Sekunden gedrückt... Der Backtrace sieht aber geringfügig anders aus. In den Zeilen, wo sonst die Stelle in skinnopacity (z.B. displaymenu.c und displaymenu.h) erwähnt wurde stehen jetzt nur ?. Ich hänge es mal an:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/vdr --localedir=/etc/vdr/locale -u root -w 60 --config=/etc/vdr --shut'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000005435ff in cThread::StartThread (Thread=0x92d75b0) at thread.c:262
#2  0x00007fe39b0e2344 in ?? () from /usr/lib64/libGL.so.1
#3  0x00007fe3a2573f26 in start_thread () from /lib64/libpthread.so.0
#4  0x00007fe3a11ab4ed in clone () from /lib64/libc.so.6

Gruß, Ingo

P.S.: ch habe meinen Patch heute nacht durchlaufen lassen, mit einer Bedingung, dass die g2v-Scripte den Shutdown jedesmal abbrechen, so dass die früher kritische Stelle, wenn der Countdown zu Ende war, und das nächste Nachrichtenfenster angezeigt wird (in diesem Fall eben "Shutdown abgebrochen") alle 5 Minuten durchlaufen wurde. Der vdr lief heute morgen noch.

Ich habe ja alles gerne etwas größer, da ich ca 4m vom TV weg sitze. Ich habe bei mir die Symbols im Channeldisplay durch die, die es mal für enigma gab ersetzt (Deklaration auf xpm-Standard angepasst). Ich hänge das hier mal der Einfachheithalber als Patch an (ist ja eh nur Text). Dieser Ersetzt die xpms in symbols durch xpms, die 45x30 groß sind.

Gruß, Ingo

Zitat von louis

Na das klingt doch gut...wenn das stabil läuft, werde ich das demnächst mal ins git aufnehmen.

Ich habe uns aber einen kleinen Seiteneffekt eingebaut: Wenn sich der Text in der Countdown-Message-Box ändert fadet es kurz. Mich stört es nicht, aber da es ursprünglich nicht so war, ist es wohl auch nicht im Sinne des Erfinders...

Gruß, Ingo

Zitat von 3PO

Da ich in meiner Make.config keinen Eintrag "USEFHS" habe, gehe ich mal davon aus, dass ich es auch nicht verwende.

Mir ist das auch schon aufgefallen. Ich habe in der Make.config sogar ausdrücklich CONFDIR=/etc/vdr drin. Und: der vdr legt dieses Verzeichnis nur mancmal an. Bei den Tests der letzten Tage habe ich den vdr ja häufiger gestoppt und gestartet. Gefühlt würde ich sagen, das Verzeichnis ist nach jedem 2-3 Beenden da.

Gruß, Ingo
EDIT: vdr wird auch mit --config=/etc/vdr gestartet

Ich mache es so.

Gruß, Ingo