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....

  • Ingo: das sind die Fragen, die ich mir auch schon gestellt habe...


    Lars: an sich macht das keinen Unterschied. Der Thread setzt ja die alpha Werte aller verwendeten Pixmaps schrittweise hoch. Ich habe direkt die Klasse zur Darstellung (DisplayChannel, DisplayMenu, ...) von cThread erben lassen, dann kann ich in der Klasse direkt auf die Pixmaps zugreifen, das ist am einfachsten. Das Problem ist ja aber, dass beim Zerstören dieses Objekts die Pixmaps nicht mehr definiert sind, der Thread aber noch läuft und versucht auf diese Pixmaps zuzugreifen. Wenn der Thread nun ein externer wäre, wäre das das analog da man diesem Thread auch sagen müsste, dass er pausieren soll...und das kommt aufs gleiche raus wie den Thread zu stoppen.


    Ciao Louis

  • Moin!


    Multi-Threading macht immer viel Spaß... :)
    Da verschiedene Threads die Pixmaps bearbeiten, muss man sie schützen.


    Einfache Methode: In Action vor den ganzen Pixmaps-Aufrufen eine cMutex sperren und anschließend wieder freigeben.
    Und das ganze auch in den anderen Funktionen, die nach dem Start des Threads aufgerufen werden können, insbesondere im Destruktor (ich schau mir jetzt als Beispiel nur DisplayChannel an).
    Das passiert ja quasi schon mit cPixmap::Lock/Unlock. Was passiert denn, wenn man im Destruktor erst cPixmap::Lock aufruft, eine interne Variable auf "inDestruction = true" setzt und diese zusätzlich nach dem Lock in Action abfragt und bei true einfach aussteigt (und mit Verlassen von Action automatisch den Thread beendet)? Das Unlock im Destruktor darf man dann natürlich auch nicht vergessen...


    Ich installiere gerade ein paar Updates, werde das gleich mal probieren... Viel Zeit hab ich allerdings heute abend nicht mehr.


    Lars.

  • Moin!


    Da der Absturz bei mir nur schwer zu reproduzieren ist, ich ihn aber mit diesem Patch von mir bis jetzt auch noch nicht wieder bekommen habe, kann ja auch mal jemand anders testen. :)
    Bei mir geht das Einblenden auch nicht mit der Tab-Taste, sondern M, und wenn ich die gedrückt halte, passiert nicht viel...


    Der Patch bearbeitet erst mal nur DisplayChannel und DisplayMenu.


    Lars.

  • 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.

  • Zu dem Problem mit den Recordings Einträgen, die nicht verschwinden nach dem Löschen einer Aufnahme, kann ich bestätigen, dass dies solange die *.del existiert der Fall ist.
    D.h. der Skin zeigt auch die Aufnahmen an, die mit *.del zum löschen markiert sind. Eigentlich sollten die nicht mehr angezeigt werden.
    Ich denke mal sobald der vdr die aufräumt, werden die Einträge auch weg sein.

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:
    Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:
    Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150
    , DVBSky S960 und 1Tb WD Blue

  • 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:


    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.


  • 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.


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

  • Gibt es eigentlich einen speziellen Grund, weshalb das Plugin immer wieder folgendes Verzeichnis anlegt?

    Code
    /video/plugins/skinnopacity/


    Ist dein VDR mit FHS Unterstützung gebaut? Ich verwende als Default Verzeichnis für Logos und Icons das ResourceDirectory vom VDR, und das wird das dann wohl sein. Das Anlegen des Verzeichnisses macht der VDR selbst...


    Ciao Louis

  • 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

  • Ist dein VDR mit FHS Unterstützung gebaut? Ich verwende als Default Verzeichnis für Logos und Icons das ResourceDirectory vom VDR, und das wird das dann wohl sein. Das Anlegen des Verzeichnisses macht der VDR selbst...


    Ciao Louis


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


    Wenn ich nopcity deaktiviere, wird das Verzeichnis "/video/plugins" auch nicht mehr angelegt.

  • 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

  • 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

  • hallo,


    bei mir kommt es leider zu einem segfault - ohne aktivitiät oder daß der skin/OSD offen wäre ?


    Code
    Dec  1 23:52:52 pvr vdr: video: slow down video, duping frame
    Dec  1 23:52:52 pvr vdr: video: 22:01:28.047  +38  206   0/\ms  33+6 v-buf
    Dec  1 23:53:21 pvr vdr: [1480] channel 72 (Disney Channel HD) event Son 02.12.2012 00:00-06:00 'Disneys lange Nächte' status 4
    Dec  1 23:53:42 pvr vdr: video: slow down video, duping frame
    Dec  1 23:53:42 pvr vdr: video: 22:02:18.047  +38  190   0/\ms  35+6 v-buf
    Dec  1 23:53:49 pvr kernel: [15563.041250] __ratelimit: 18 callbacks suppressed
    Dec  1 23:53:49 pvr kernel: [15563.041255] vdr[1846]: segfault at 20 ip 00007f160e8f2c75 sp 00007f15e7da8e50 error 4 in libvdr-skinnopacity.so.1.7.32[7f160e8
    dd000+3b000]


    wie kann ich das spezifisch debuggen?


    gruß, ciax

Jetzt mitmachen!

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