Kiste ist jetzt neu installiert und läuft wieder.
XP SP2, nur mAirList drauf alle Scripts abgeschaltet bis auf Emergency Playliste und Nächste Playliste laden.
Aufgefallen ist mir jetzt folgendes:
Nach dem zurück kopieren der konfig ist mAirList nicht mehr gestartet. Lag an Remote.ini. Habe die Konfig zum grösstenteil jetzt manuell neu erstellt. Nur um sicher zu gehen. Komisch ist dass es vorher damit funktionniert hat. Kann mir das nicht erklären…
Beim Schliessen der Config bekomme ich manchmal (öfters) eine Windows Fehlermeldung " Application had to close… etc". Ich schicke dir mal den Screenshot mit dem Fehler sowie der Textdatei welche an MS gehen soll. Vorher war in der Registry das automatische Versenden der Fehler abgeschaltet. Kann sein dass das schon vorher war, ich hab’s eventuell deswegen nicht bemerkt.
Danke für die Mail mit der Fehlermeldung. Leider ist Microsoft da nicht besonders hilfreich. Es wird lediglich die Fehleradresse angezeigt. Die zeigt in diesem Fall in eine Routine, die für die Lokalisierung (Übersetzung der GUI) zuständig ist. Von wo und warum die aufgerufen wird, kann ich nicht sehen.
Dass der Fehler überhaupt von Windows in dieser Weise berichtet wird und nicht von mAirList, deutet darauf hin, dass er zu einem Zeitpunkt auftritt, wo mAirList eigentlich schon komplett deinitialisiert ist und auch die eigenen Fehlerbehandlungs-Routinen (madExcept) nicht mehr aktiv sind. Vielleicht bleibt irgendwo was im Speicher hängen, was dann am Ende den Fehler verursacht.
Nach Programmende wird eine Dialogbox erscheinen, die anzeigt, ob noch Objekte im Speicher verbleiben sind und wenn ja welche. Das wird auch in einer Datei namens mAirList_MemoryManager_EventLog.txt protokolliert. Die hätte ich gerne.
Ich kann es momentan nicht reproduzieren (mit der Debug Version)
Teste heute abend noch mal mit der 934.
Hmm, das System war neu aufgesetzt und es lief wahrscheinlich ebenfalls ein Windows-update während ich die Config bearbeitet habe.
Nicht dass der Update Service da reingefunkt hat.
Wie auch immer, ich teste das heute abend noch ausgiebig und berichte dann.
ich kann es wirklich nicht mehr reproduzieren. Ich gehe nun mal ernsthaft davon aus dass Windows Update hier mitgespielt hat.
Der war nämlich aktiv und ich nutzte die Zeit um die Config neu zu erstellen da die alte Config die GUI von mAirList irgendwie “versteckte”
Habe keine Erklärung dazu. Ich kann die Config auf dem anderen Test PC kopieren, da klappt’s.
Hier war nur der mAirList-Icon zu sehen, die GUI von mAirlist selbst aber nicht. Soundausgabe lief…
Ich denke wir belassen es mal dabei und ich lasse das Ganze jetzt mal im Test laufen.
Habe auch jetzt bewusst nur den Windows Treiber der Graphikkarte geladen. Das reicht vollkommen, all die andern Einstellungen brauchen wir eh’ nicht. SP3 von XP ist auch nicht installiert
Wie gesagt alle Scripts sind immer noch ausgeschaltet.
Gestern abend wieder ausgestiegen. Build 936 die Debug Version.
Also mir fällt jetzt nur noch ein dass ich in der Playliste Icons und Farben für die jeweiligen Kategorien benutze.
Das Programm wo die Playlisten erstellt fügt die automatisch mit ein.
Ich werde das mal jetzt noch herausnehmen. Auch das automatische setzen des “StartNext” Markers werde ich abschalten…
Wenn andere mAirList 24/7 benutzen ohne Ausfall, dann muss es bei mir etwas spezifisches wie z.B. die Icons sein welche den Ausfall provozieren. Das Icon wird ja auch bei den Eigenschaften der Datei angezeigt. Da steigt das Programm ja auch nach einer Weile aus wenn man die aufruft.
Alternativ kann ich dir, Torben, mal eine Playliste zuschicken ob vielleicht im xml code was verbogen ist? (Was ich zwar bezweifele aber man weiss ja nie)
Am XML liegt’s sicher nicht, da würde einfach eine Fehlermeldung kommen, wenn die Datei kaputt ist.
Ein normaler Anwendungsfehler kann es auch nicht sein, da würde madExcept anspringen.
Aus irgendeinem Grund schießt Windows den Prozess ab. Ich hab bislang leider nichts darüber gefunden, unter welchen Bedingungen das passieren kann/darf.
Hast du eigentlich mal im Task-Manager die die Anzahl der GDI-Objekte beobachtet, wie der Wert sich über die Zeit verändert? (Siehe meine Antwort #15). Zwar müsste auch da immer eine Fehlermeldung kommen, bevor der Prozess beendet wird, aber nunja, Microsoft…
Das könnte eine heiße Spur sein. Gerade weil du davon sprichst, dass viele Icons verwendet werden.
Also ich kann mittlerweile ziemlich genau sagen ab wann die Sache aussteigt ;D
Ist nach ca 2,5-3 Tagen immer der Fall.
Die Sache mit den GDI habe ich noch ncht gemacht. Werde das aber auch noch machen.
Ich versuche es jetzt zunächst mal ohne Farbe und Icons in den Playlisten.
Es muss bei mir was spezifisches sein was andere User nicht haben. Da fallen mir direkt nur die Icons und Farbkennung in den Playlisten ein, sowie das setzen des StartNext-Markers über die Playliste.
Ich bleibe auf jeden Fall an der Sache dran. Das muss zu finden sein… zumal ich das hier auf beiden PCs reproduzieren kann.
Die Scripts und die Hardware kann man ja jetzt schon mal ausschliessen.
Wir werden sehen…
Ich habe gerade nochmal debuggt, und zwar speziell den Fall, wenn man eigene Playlist-Icons benutzt. Und siehe da, es gibt tatsächlich einen memory leak (und damit verbundenen GDI leak). Pro Playlist-Element mit eigenem JPG-Icon (PNG ist nicht betroffen) gehen zwei GDI-Handles und ein bisschen RAM verloren.
Das würde auch erklären, warum der Fehler immer nach etwa derselben Zeit auftritt - wenn x Elemente durchgelaufen sind.
Warum Windows den Prozess dann einfach beendet, weiß ich noch immer nicht. Aber ich gehe stark davon aus, dass das die Ursache war. Wir waren schon auf der richtigen Fährte, du hättest nur meine Anweisungen befolgen müssen
Der Fehler ist übrigens behoben. Build 938 liegt bereit.
Ich benutze .ico Icon-files. Betrifft es auch die?
Habe jetzt mal geschaut. Programm ist ja jetzt neu gestartet. Vor 1 Stunde waren es ca 1100, mittlerweile schon knapp 1300 GDIs.
Wollte den BUGREPORT mit dem Laden der nächsten Playliste per Event ausführen lassen.
Also quasi: Ececute command(BUGREPORT)
Da kommt aber immer das Dialogfenster. Gibt es da keinen Qualifier um automatisch abzuspeichern/überschreiben.
Dann hätte man für jede Stunde einen Report und könnte eventuell was nachschauen.
Aber gut dass du das gefunden hast. Sorry dass ich nicht immer die Anweisungen befolge ;D
Das im Posting #15 mit den GDIs habe ich komplett verbummelt…
Ja, .ico ist auch betroffen. Alles außer PNG. (Intern verwendet mAirList nur PNGs, andere Dateien werden vor der Anzeige konvertiert - und genau dort steckte der Fehler.)
Eine komplette Playliste “verbraucht” ca 250-280 GDIs. Hängt von ab wieviel Titel drin sind und ob Icons in der Liste “nachrutschen”
Sind ca 12 GDIs pro Item in der Playliste wo “verrauchen”.
So, und wenn mAirList minimized ist, werden pro gespieltem Item wieder 2 GDIs “gutgemacht”
Ich hatte mich gewundert wieso heute morgen mAirList nur bei einem der 2 PCs gestoppt war…
Beim 2ten PC lief mAirList nämlich minimized.
Genau, die Grafiken werden erst in dem Moment geladen/konvertiert, wo sie angezeigt werden sollen. Fenster minimiert -> keine Anzeige -> kein Laden -> kein GDI Leak
