Oberfläche friert beim Titelstart für ca. 3 s ein - Version 2.1.44

Hallo Torben.

In der Version 2.1.44 friert uns beim Titelstart die Oberfläche für ca. 3 s ein.
Musik wird trotzdem ausgespielt. Karte ist eine Phase 28 (Auswahl WDM HW)
Bass Häkchen in allen Variation ausprobiert. Keinen Einfluss auf diesen Fehler.
Prescan ist nicht aktiviert. Rechner ist aktuell (3 GHz mit 1 GB Ram, XP)
Keine Probleme mit der im Einsatz befindlichen Version 2.1.40

Sind irgendwelche Scripts eingerichtet?

Ja.
NowPlayingHTML.mls
PlaylistEmpty.mls
und
Notplaylist laden.mls

Code:
begin
CurrentPlaylist.LoadFromFile(‘Y:\Verzeichnisse\mAirList\playlists\Notplaylisten\Notplayliste-’ + FormatDateTime(‘HH’, now) + ‘-Uhr.mld’);
end.

D.W. Logging in mySQL Datenbank und Datei.

Keine Fehlermeldungen.

Kommen die Log-Einträge im MySQL auch brav an?

Bin noch im Büro.
Schau ich mir nachher an.
mySQL Logging war auch in der 2.1.40 aktiv.
Gesetzt dem Fall DB Logging wäre fehlerhaft (keine Fehlermeldung!),
hätte das so starken Einfluss auf die grafische Oberfläche?

Ja, bei mir friert die Oberfläche auch ein.

Es wird ein script zum HP Logging ausgeführt.

Das selbe passiert wesentlich regelmäßiger, wenn man die neue Playliste (.m3u) in die Playlist lädt.

Das Logging findet für die meisten Arten im Haupt-Thread statt, blockiert also die GUI, bis es abgeschlossen ist.

aha, und was kann man dagegen machen?

Handelt es sich um einen HTTPGet-Aufruf? Dann kannst du seit den neuesten Snapshots die Funktion “HTTPGetAsync” verwenden. Die führt den Aufruf in einem separaten Thread (also im Hintergrund) aus. Allerdings ist sie auch nicht in der Lage, die vom Server gesendete Antwort zurückzuliefern. Falls dich das nicht stört…

nö, das stört nicht!
Danke!

Eventuell hilfreich:
Wir hatten dies auch schon, wenn beim Logging die MySQL Datenbank nicht mehr verfügbar war.

Dann muss ich auch das wohl mal in einen externen Thread verschieben. Das Problem ist immer die Synchronisierung, also dass sich der Thread am Ende nochmal beim Hauptprogramm meldet und ein Ergebnis zurückliefert. Sofern das aber nur (evtl.) eine Fehlermeldung ist, ist das kein großes Problem.

Oder, lässt sich prüfen, ob zur Datenbank eine Verbindung besteht (Eventuell bin optischer Anzeige)

Wenn nicht, wird das Logging deaktiviert.
Sobald die Verbindung wieder okay ist schaltet sich das Logging wieder ein.

Ja, das geht natürlich auch.

Ach so, nein, das geht natürlich nicht.

Das Datenbank-Logging-Interface baut die Verbindung erst in dem Moment auf, wo der Log-Eintrag anfällt. Die Verbindung wird nicht dauerhaft offen gehalten. Wenn nun der Server nicht erreichbar ist, dauert es halt x Sekunden, bis der Verbindungsversuch als “timed out” angesehen wird.

Also lieber doch die Methode mit dem separaten Thread.

Lässe sich der Status längerfristig auch anzeigen, so weiss der Moderator/in was eventuell nicht funktioniert.

Michel

Nein, aber es erscheint dann eine Fehlermeldung im System Log.

Hab’ mal in das mySQL Log geschaut, keine Einträge unter der 2.1.44
Alle Einträge der 2.1.40 werden hingegen einwandfrei geschrieben.
Fehlermeldungen gibt es nicht.

Nimm mal den aktuellen Snapshot. Es gab einen Bug, der dazu führte, dass MySQL-Fehler nicht angezeigt werden. Das ist nun behoben.

So, hier nun die Ausgabe mit dem Snapshot - Build 502

Hat das vielleicht hiermit zu tun?

[quote=“Torben, post:5, topic:4812”]Ich glaube, man darf nur eine Variable pro Feld benutzen. Das “%Y-%M-%D %h:%m:%s” kannst du auch durch NOW() ersetzen. Und bei festen Texten braucht man weiterhin Anführungszeichen.

Probier mal:

StartCommand=insert into history (text, eventtime,eventkey, location) values (%3, NOW(), 1, ‘Studio 1’)

(davon ausgehend, dass “eventkey” ein int ist, sonst auch um die 1 Anführungszeichen drum.)[/quote]

Gibt es da evtl. einen Zusammenhang?