hrhr ich ahne, wo eine (technische) Schwierigkeit liegen könnte - der “load” Befehl an’s OS ist “blocking”, richtig? Normalerweise gibt es (wenn ich mich an die POSIX Spezifikation richtig erinnere) auch einen non-blocking Systemcall - dann könnte man beim Umschalten ein globales Flag “HALT_LOAD” oder sowas setzen und die Player während der Laderoutine dieses periodisch abfragen lassen und, falls gesetzt, den Vorgang abbrechen - aber mit dem Non-Blocking Call (oder auch asynchronem laden) ist man gleich wieder im Reich des Schmerzes mit Resource locking und anderen Schweinereien… 
Bei “Play” halte ich es für extrem sinnvoll, auf den (oder die) spielenden Player zu warten - möglichweise könnte man das so lösen, daß man spielende Player an’s Ende der Schlange setzt und dann erst die nicht spielenden Player zum neuladen animiert und anschließend wartet, bis die einzelene spielenden Player fertig sind, bevor man auch auf diesen den Load-Befehl nachholt.
Auf alle zu warten könnte unangenehm werden, wenn’s schnell gehen muß - dann sollte man den Umschaltbefehl akzeptieren und irgendwie optisch anzeigen (Überschrift blinkt oder sowas) und dann nach dem Stopp des letzten Players den Befehl ausführen, damit der fahrende Moderator keine Panik kriegt und sich fragt, warum mAirlist auf seinen Befehl nicht reagiert - das löst aber immer noch nicht das Problem, das Cartplayer ja auch längere Elemente beinhalten könnt (Vielleicht Werbespots von 30 oder 45 Sekunden oder sowas) - und wenn man erst 30 Sekunden warten muß, ehe die Player umschalten, dann kan das schon sehr unangenehm sein, weil vielleicht ein Element aus der anderen Bank früher abfespielt werden soll.
Egal, wie man’s macht, es ist eh falsch Die komplizierteste (aber auch flexibelste) Lösung wäre, denke ich, das Load Problem über asynchrones Laden (so das unterstützt ist) mit der Möglichkeit zum abbruch über ein Flag zu lösen und das Play Problem über Queueing - aber erinnere an die Welt des Schmerzes (a.k.a. Resource Locking) - asynchron ist immer aasig und ich bin heilfroh, daß meine Rolle hier darauf beschränkt ist, wilde Ideen in den Raum zu werfen, und ich das nicht selber programmieren muß
LG
McCavity
P.S.: eine Ergänzung noch, die mir gerade eingefallen ist - würde auch Programmieraufwand bedeuten, wäre aber möglicherweise eine elegante (Teil-Lösung) des Load-Problems: mAirlist cachet ja eh Mediendateien im RAM (was auch sehr sinnvoll ist). Man könnte dann doch auch hergehen und die komplette (oder Teile der) Cartwall cachen, oder nicht? Wenn man das Ganze mit einem intelligenten Memory-Management-Dialog ausstattet (“Bei derzeitiger Belegung würde der Cartwall Cache xyMB groß, die größte Datei ist yzMB groß, der Durchschnitt za MB bei einer Standardwabweichung von abKB” (ja, ich übertreibe ;-)) und man dann auswählen könnte, welche Dateien beim Start von mAirlist gecached werden sollen (Dialog enthält alle geladenen .mlc, gespeichert wird die Information “Caching ja/nein” in der jeweiligen .mlc) könnte mAirlist beim Start schonmal alle markierten Dateien laden - und ein Umschalten wäre dann nur noch das verbiegen eines Pointers ('tschuldigung, ich komm aus der C-Welt und hab keine Ahnung von Delphi - ich kenn noch den Vorläufer Turbo-Pascal, aber auch nur bis zur Version 5.5 (zwar die erste mit Objektorientierung, aber so weit war ich damals noch nicht… ;-)) - dehalb schreib ich nur so High-Level-Quatsch und hab eigentlich keinen Schimmer, ob sich das in Delphi so umsetzen ließe ;-))
