mAirListDB logging proxy

Will there be a PRO version to test indicate?

Michel

Pardon?

Sorry, verstehe die Frage wirklich nicht. Frag ruhig auf Deutsch, ich antworte dann auf Englisch :wink:

;D Eigentlich wollte ich fragen, ob es wieder eine Version, mit der mAirListDB geben wird.

Sure. But not today :wink:

Kein Problem. Bin eh dabei die V3 im Playoutmodus zu testen.

Neue SystemLog gefällt mir ::slight_smile:

Ist aber noch nicht fertig, wie man an den fehlenden Buttons in der Toolbar sieht. Irgendwie will man das Log ja zwischendurch auch mal kürzen oder löschen.

Hey, you native English speakers, this is modern German, one out of five words is actually English :wink:

Oder automatisch :wink:

Oder beides.

In diesem Zusammenhang, möchte ich, noch folgendes in diesen Thread platzieren:
Habe heute bei allen unseren mAirList Instanzen eine zusätzliche Loginstanz hinzugefügt. War etwas aufwendig, und dieser Arbeitsgang gestaffelt erfolgen musste, da immer eine mAirList-Instanz Onair war. Wäre es nicht einfacher, wenn alle MAirList-Instanzen gebündelt in einen zentralen Service loggen könnten? Dieser hätte anschließend sämtliche Möglichkeiten die einzelnen Schnittstellen zu versorgen. Auch eine zentrale COM-Schnittstelle für RDS könnte hier angeschlossen werden. Hier könnten auch die SystemLog’s zentral gesammelt werden. mAirList müsste bei einem Netzwerkunterbruch die Loggingdaten zürückhalten, oder diese verwerfen, damit das Playout nicht ins stocken gerät.

LG
Michel

Im Prinzip ist doch jetzt schon soetwas möglich. Natürlich gibt es keinen “Standard” dafür, aber mit den Logging-Schnittstellen HTTP oder auch Datenbank-Logging stehen dir alle Möglichkeiten offen. Schreib dir einen PHP-basierten Logging-Server, oder realisiere das mit einer MySQL-Datenbank, die dann per Trigger andere Prozesse anstößt, die die Daten weiterverarbeiten.

Es ist geplant, nach und nach alles Logging in einen Thread zu verschieben, so dass es die GUI nicht mehr behindert, wenn es mal etwas länger dauern sollte.

If I understand this correctly, we’re talking about the numerous processes involved that takes place “playing” an item and the response time of the audio vs the GUI. I guess that it gets quite hard when you have various things happening like fade-outs, scripts and such during a Playlist transition…

I think it’s important to place emphasis on getting the sound out before doing background things like logging etc.

It’s about global logging. a kind of proxy
mAirList should forwared all data to the proxy

Charlie, even better - these tasks can take place in a thread seperated from the GUI thread. Most of mAirList is now thread-safe, so it’s no problem to access databases, files etc. from a separate thread.