nOpacity 0.0.3

ciax · 2. Dezember 2012

Zitat von nvertigo

Ich mache es so.

Gruß, Ingo

danke, mal sehen ob ich was rausbekomme - core file wird keines geschrieben, trotz ulimit auf "ulimited" gesetzt ...

gruß, ciax

jsffm · 2. Dezember 2012

Zitat von nvertigo

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

vdr löscht die Ordner irgendwann wieder, da sie leer sind. Da von anderen plugins keine solche Ordner angelgt werden, muss es doch mit diesem plugin zusammenhängen.

Zoolook · 2. Dezember 2012

Hi,

bei mir passiert dieser segfault systematisch wenn epgsearch auch mit an Bord ist und ich mir die EPG-Infos der laufenden Sendung ("Info"-Taste) angucken will, nur was ist denn da los?. Ich habe das nun so reproduziert, dass ich den VDR bloss mit 3 Plugins (softhddevice-git, nOpacity-git und epgsearch-1.0.0) geladen habe. Wenn ich ausser nOpacity auch ein anderes Skin lade und vorher darauf umschalte, sehe ich die Beschreibung der laufenden Sendung problemlos, schalte ich wieder auf nOpacity, kracht es sofort beim Druecken der "Info"-Taste. Ich bin mir auch sicher, ich hatte das schon mit der allerersten nOpacity-Version.

LG,

Lucian

mini73 · 2. Dezember 2012

@nvertigo:

Ich hab unsere Patche noch mal zusammen geworfen, es gibt da nämlich zwei drei Kleinigkeiten, die bei dir "theoretisch" unnötig sind:

Code

while (Active()) {
		Cancel();
		cCondWait::SleepMs(config.channelFrameTime + 1);
	}

Wenn du Cancel ohne Parameter aufrufst, dann wird der Thread sofort abgeschossen und active auf false gesetzt. Der while-Loop ist also unnötig und der Thread hat keine Chance, das, was er tut, vernünftig zu Ende zu bringen.
Deshalb benutze ich:

Code

Cancel(-1);
	while (Active())
		cCondWait::SleepMs(10);

Dem Thread wird gesagt, dass er aufhören soll und es wird so lange gewartet, bis er wirklich fertig ist. Und es muss nicht die ganze fadetime gewartet werden, da der Thread (mit meinen anderen Änderungen) auch zwischendurch schon aussteigt.

Außerdem ist das Abfragen von Running() vor dem Start() unnötig, das macht der vdr schon selbst, ist also doppelt-gemoppelt.

Hier läuft das schon eine Weile stabil, wäre toll, wenn du das auch noch mal testen könntest.

Ich teste das jetzt mit dbus2vdr, darüber schicke ich ständig die Menütaste, der vdr ist ordentlich ausgelastet und ich kann trotzdem noch nebenbei tippen...
Aber teste du bitte weiter mit dem Zahnstocher, nichts ist besser als unterschiedliche Testmethoden!

Code

#!/usr/bin/env python


import dbus
bus = dbus.SystemBus()
Remote = bus.get_object('de.tvdr.vdr', '/Remote')
var = 1;
while var == 1:
  Remote.HitKey('menu', dbus_interface = 'de.tvdr.vdr.remote')

Lars.

CKone · 2. Dezember 2012

Hi Lars,

kannst du mir kurz ne Idee geben welche magick (dev) Pakete ich benötige um unter precise mitspielen zu können, ich kriegs irgendwie nicht richtig hin

Danke
Christian

mini73 · 2. Dezember 2012

Moin!

Zitat von CKone

kannst du mir kurz ne Idee geben welche magick (dev) Pakete ich benötige um unter precise mitspielen zu können, ich kriegs irgendwie nicht richtig hin

Ich hab nichts besonderes installiert, einfach nur unser PPA-Paket. Und dann hab ich wahrscheinlich irgendwann ein "apt-get build-dep vdr-plugin-skinnopacity" gemacht...
Im control-file steht nur "libmagick++-dev".

Lars.

CKone · 2. Dezember 2012

Zitat von mini73

Und dann hab ich wahrscheinlich irgendwann ein "apt-get build-dep vdr-plugin-skinnopacity" gemacht...

Ahhh, reingefallen, habs versucht mit

Code

apt-get build-dep vdr-plugin-nopacity

Bedankt
Christian

3PO · 2. Dezember 2012

Alle Jahre wieder...

... zur Weihnachtszeit ändert Sky den Sendernamen von Sky-Comedy zu Sky-Christmas.

[Blockierte Grafik: http://imageshack.us/a/img833/852/94587517.jpg][Blockierte Grafik: http://imageshack.us/a/img21/6981/21386313.jpg]

Ich hänge mal die fehlenden Senderlogos dazu an.

nvertigo · 2. Dezember 2012

Lars: hier gucken meine Jungs gerade Happy Feet - ein Neustart würde zu einer sozialen Schutzverletzung führen... und da hilft dann kein gdb und nix mehr... Bin am späteren Nachmittag wieder dabei.

Ich lerne hier gerade sehr viel. c++ ist eigentlich nicht meine Baustelle (eher c und sh), und mit threads stehe ich auch bei c auf dem Kriegsfuß. Was ich gemacht habe ist trail and error. Ich sauge hier gerade jede Erklärung auf. Die Schleifen sind reine Paranoia. "Nur weil ich paraniod bin, heißt das ja noch lange nicht, dass sie nicht doch hinter mir her sind... (der Thread noch versucht Pixmaps zu ändern...)"

Kannst Du mir kurz erklären, was der Unterschied zwischen Running() und Active() ist? Ich hatte die Kommentare in threads.h so verstanden, dass Cancel() das running-flag augenblicklich kippt, und Running() von da an nichts mehr liefert, Active() guckt, ob der Thread noch da ist.... Wie gesagt: trail and error...

Gruß, Ingo

mini73 · 2. Dezember 2012

Moin!

Ich hab in meinem Patch noch einen kleinen Fehler in displaychannel.c (ganz am Ende in Action). In dem if vor dem SleepMs muss es natürlich "Running()" heißen und nicht "!Running()".

Zitat von nvertigo

Kannst Du mir kurz erklären,...

Bei Start werden active und running auf true gesetzt, dann wird der Thread gestartet (pthread_create).
Cancel setzt running auf false, damit der Thread in seiner Action-Methode testen kann, ob er überhaupt noch arbeiten soll. Wenn nicht, sollte er möglichst bald aus seiner Action-Methode aussteigen, hat aber noch Zeit aufzuräumen.
Action wird nicht direkt von pthread_create gestartet, sondern von einer Hilfsfunktion "StartThread". Sobald Action zurückkommt, wird active auf false gesetzt, der Thread ist dann also wirklich "fertig".
Wird nun kein Timeout mitgegeben (Cancel(-1)), wird nur running auf false gesetzt, mehr nicht. Wenn der Thread nicht darauf reagiert, wird er ewig weiterlaufen.
Wird Cancel(0) aufgerufen, wird der Thread sofort gekillt, was zur Folge haben kann, dass irgendwelche Resourcen/Locks usw. nicht aufgehoben werden.
Mit einem Timeout wartet Cancel die angegebene Zeit, ob active auf false wechselt (der Thread also fertig ist). Wenn das nicht in der angegebenen Zeit passiert, wird der Thread auch einfach gekillt.

Code

Methode        | Running | Active
---------------------------------
               | false   | false
Start          | true    | true
Action         | true    | true
---------------------------------
Cancel(-1)     | false   | true
Action zu Ende | false   | false
---------------------------------
Cancel(0)      | false   | false
Action kommt nicht zum Ende
---------------------------------
Cancel(x > 0)  | false   | true
Action zu Ende | false   | false
evtl. kommt Action nicht zum Ende
wenn es zu lange braucht
---------------------------------

Alles anzeigen

EDIT:

Code

Cancel(-1);
	while (Active())
		cCondWait::SleepMs(10);

Mit dieser Variante von mir wird dem Thread also so viel Zeit eingeräumt, wie er braucht, um sich vernünftig zu beenden.

Lars.

nvertigo · 2. Dezember 2012

Dankeschön, Lars.

Nach Deiner (super verständlichen) Erklärung würde ich dann zu meinem Patch mal sagen: intuitiv halb-richtig geraten...

Muss noch etwas warten bis ich testen kann. Habe mir gerade den v3 Patch angesehen: Hast Du das locking wieder rausgenommen? Der Patch geht doch gegen git-Version und ist nicht der Patch für den Patch für den Patch, oder?

Gruß, Ingo

nvertigo · 2. Dezember 2012

Zitat von mini73
[/code]
EDIT:
Code
Cancel(-1);
	while (Active())
		cCondWait::SleepMs(10);
Mit dieser Variante von mir wird dem Thread also so viel Zeit eingeräumt, wie er braucht, um sich vernünftig zu beenden.

Wäre dann nicht so etwas paranoid sinnvoller:

Code

int my_i=0
	Cancel(-1);
	while (Active()) {
		cCondWait::SleepMs(10);
                    my_i++; 
                    if (my_i > MY_MAXWAIT)
                    Cancel();
                }

MY_MAXWAIT wäre dann in 1/100s - geht mir halt nur darum, dass auf jeden Fall irgendwann Scluss ist.
Sonst bestünde doch zumindest theoretsch die Gefahr, das man für immer im Menu hängen bleibt...

EDIT: sorry, wegen der Einrückung, bekomme das ohne tabs auf meinem Tablet gerade nicht besser hin.

Gruß, Ingo

mini73 · 2. Dezember 2012

Moin!

Zitat von nvertigo

Habe mir gerade den v3 Patch angesehen: Hast Du das locking wieder rausgenommen? Der Patch geht doch gegen git-Version und ist nicht der Patch für den Patch für den Patch, oder?

Ja, das Locking ist wieder raus. Meine Patche sind immer gegen git.
Da jetzt gewartet wird, bis der Thread zu Ende ist, kommt kein konkurrierender Zugriff mehr zustande.

Zitat von nvertigo

Wäre dann nicht so etwas paranoid sinnvoller:

Könnte man machen, aber der Thread wird auf alle Fälle beendet, ist also nicht nötig (so die Theorie).
Ich hab in Action nichts gesehen, was blockieren könnte.

Mein vdr wird schon seit über einer Stunde mit der Menütaste gequält, bis jetzt noch kein Absturz... Ich hoffe, bei dir ist es nachher auch so...

Lars.

nvertigo · 2. Dezember 2012

Mein Stress-Test läuft seit 20 Minuten - habe von Zahnstochern auf eine Logostein mit Holzscheit als Gewicht umgestellt.

Das sieht gut aus! *freu*

Kannst Du mal kurz hier drüber gucken, wenn ich nämlich vergesse displaymessage umzubauen, geht mein vdr heute nach nicht schlafen...

Diff

diff --git a/displaymessage.c b/displaymessage.c
index ad420af..779e57e 100644
--- a/displaymessage.c
+++ b/displaymessage.c
@@ -16,6 +16,9 @@ cNopacityDisplayMessage::cNopacityDisplayMessage(void) {
 }


 cNopacityDisplayMessage::~cNopacityDisplayMessage() {
+       Cancel(-1);
+       while (Active())
+               cCondWait::SleepMs(10);
        osd->DestroyPixmap(pixmap);
        delete font;
        delete osd;
@@ -53,7 +56,7 @@ void cNopacityDisplayMessage::Flush(void) {


 void cNopacityDisplayMessage::Action(void) {
        uint64_t Start = cTimeMs::Now();
-       while (true) {
+       while (Running()) {
                uint64_t Now = cTimeMs::Now();
                cPixmap::Lock();
                double t = min(double(Now - Start) / FadeTime, 1.0);

Alles anzeigen

Gruß, Ingo

mini73 · 2. Dezember 2012

Moin!

Sieht schon gut aus.
Ich würde in Action noch ein paar Stellen einbauen, wo der Thread vorzeitig aussteigen kann vor potentiell zeitaufwendigen Aufrufen (und noch ein bisschen whitespace cleanup).

Lars.

nvertigo · 2. Dezember 2012

OK. Danke. Ich baue gleich nochmal neu, und lasse ihn dann wieder stresstesten und heute nacht wieder durchlaufen, damit er in die countdown -> "Shutdown abgebrochen" Situation rein läuft.

Wenns passt baue ich (oder Du - wie Du willst) displayreplay und displaytracks noch um, damit louis endlich einen finalen Patch bekommt.

Gruß, Ingo

mini73 · 2. Dezember 2012

Zitat von nvertigo

(oder Du - wie Du willst)

Ich mach das eben mal, dann kannst du das wieder testen.

Lars.

louis · 2. Dezember 2012

Lars & Ingo: ich finde es Klasse, dass ihr euch dieses Problems annehmt...vielen Dank! Das spart mir jede Menge Zeit.

Ich freue mich schon auf den finalen Patch

Ciao Louis

louis · 2. Dezember 2012

Zitat von Zoolook

Hi,

bei mir passiert dieser segfault systematisch wenn epgsearch auch mit an Bord ist und ich mir die EPG-Infos der laufenden Sendung ("Info"-Taste) angucken will, nur was ist denn da los?. Ich habe das nun so reproduziert, dass ich den VDR bloss mit 3 Plugins (softhddevice-git, nOpacity-git und epgsearch-1.0.0) geladen habe. Wenn ich ausser nOpacity auch ein anderes Skin lade und vorher darauf umschalte, sehe ich die Beschreibung der laufenden Sendung problemlos, schalte ich wieder auf nOpacity, kracht es sofort beim Druecken der "Info"-Taste. Ich bin mir auch sicher, ich hatte das schon mit der allerersten nOpacity-Version.

LG,

Lucian

Alles anzeigen

Hi Lucian,

passiert das auch, wenn du "normal" die EPG Infos einer Sendung anschaust (also in der Liste der Sendungen "OK" drücken)?

Ich habe in der 0.0.3 eingebaut, dass per epgsearch nach Wiederholungen gesucht wird, wenn der EPG Detal View aufgemacht wird...vielleicht ist da noch ein Bug drinn.

Ciao Louis

mini73 · 2. Dezember 2012

Zitat von louis

Ich freue mich schon auf den finalen Patch

Ich hoffe, der v4 ist es... Das wird sich nach den Tests von Ingo zeigen.

Lars

nOpacity 0.0.3

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema