beim arbeiten mit der mAirListDB stellen sich mir noch zwei Fragen:
Warum funktioniert der Button Speichern in Datenbank im PFL-CUE-Dialog im Zusammenhang mit der mAirListDB nicht (ich meine jetzt, wenn ich das vom Hauptprogramm mache)?
Wenn ich Events mit Datenbank-Playlists erstelle: Auf welchen Playlist bezieht sich das dann? (Beispiel: Ich lasse jede Stunde um XX:50:00 das Event “Datenbank-Playlist anhängen” starten. Welchen Playlist füngt mAirList dann ein? Den für die aktuelle Stunde (wäre ja unsinnig), oder den für die nächste Stunde? Geht es auch, dass ich den für die übernächste Stunde, usw. anhängen lassen kann?
zu 1: Der ist noch nicht implementiert. Warum, wirst du ab dem nächsten Snapshot sehen. Dann ist es nämlich möglich, einerseits die “Stammdaten” des Elementes zu pflegen, andererseits aber so Dinge wie Cuepunkte, Fixzeit usw. innerhalb einer Playlist nochmal (nur für diese Playlist) anzupassen. Ich weiß noch nicht genau, wie das zu der bisherigen “Speichern in Datenbank”-Funktion passt - soll dann Element auf Playlist-Ebene überschrieben werden, oder sogar die Stammdaten?
zu 2: Das bezieht sich immer auf die aktuelle Stunde. Hast du den Hinweis in dem Konfigurationsdialog gelesen? Wenn man auf der Seite “Optionen” eine Zeitverschiebung einstellt, dann kann man auch andere Playlisten als die aktuelle laden. Du trägst also eine Zeitverschiebung von “10 Minuten vorwärts” ein, und wenn das Event dann um xx:50:00 läuft, nimmt es schon die Playlist der nächsten Stunde. Tricky, hm?
2: Verstehe! Das ist praktisch - finde den Text (interne Uhr verschieben) aber etwas iritierend. Für mich hörte sich das so an, als ob dann die Uhr in mAirList (was man ja machen kann) verstellt würde!
1:
Ich würde mir das so Vorstellen:
In mAirList:
OK - Speichern nur für die aktuelle Playlist
Datei-Tag - Speichern in der Original-Datei (falls möglich)
Metadata-Datei - Speichern in einer Metadata-Datei
Datenbank - Speichern der CUE-Punkte des Elementes in der Datenbank (sofern sich das Element in der Dateinbank befindet)
In mAirListDB:
wie oben nur OK macht das gleiche wie “Datenbank”
Ich hab noch nicht ganz verstanden, was dagegen spricht…
Sollte man sich nicht prinzipiell daran gewöhnen, dass die Titel in der Datenbank-Verwaltung verwaltet (wie der Name schon sagt) werden?
Der neue Snapshot ist jetzt da. Erzeugt mal (in der Datenbank-Verwaltung) eine Playlist und macht einen Doppelklick auf ein Element. Wenn man irgendwas verstellt, erhält das Element danach so ein grünes Bleistift-Symbol. Das heißt, es ist jetzt für die Zwecke dieser Playlist angepasst worden. Man kann also Cuepunkte usw. verändern, ohne dass man das Element an sich in der Bibliothek ändert.
Die Preisfrage lautet nun: Wenn ich die Playlist nun in mAirList lade und den “Speichern in Datenbank”-Button drücke - sollen die Daten nur in den Playlist-Datensatz oder sogar in den Stammdatensatz geschrieben werden?
Ich würde sagen…nein! Das gibt nur Chaos…ich bin dafür, daß man solche Dinge nur in der DB machen kann…oder per Rechtemanagement einstellbar…also wenn nur Playlist
Ja, aus professionellen Gesichtspunkten darf der Informationsfluss eigentlich nur in eine Richtung gehen, von der Datenbankverwaltung in das Playout-Modul.
Ich sehe allerdings ein, dass viele unserer User Musikredaktion und Moderator in Personalunion sind. Da ist es schon praktisch, wenn man aus der Playout-Oberfläche heraus administrative Änderungen vornehmen kann.
OK in mAirList und in mAirListDB = Speichern für diese Playlist (in mAirList dementsprechend nur temporär)
Datenbank in mAirList und in mAirListDB = Elementeigenschaften verändern
Warum das ganze?
Wenn man unzählige Lieder in der Datenbank hat, ergibt sich häufig solch eine Situation:
Ich lade den Playlist (automatisch erzeugt) in mAirList. Mir fällt aber zum Beispiel auf, dass bei einem Lied die Ramp noch nicht eingegeben ist (so was sieht man im Haupprogramm deutlich schneller als in der Datenbank Verwaltung).
Jetzt kann ich natürlich gleichzeitig die Ramp für die temporäre Playlist in mAirList speichern, müsste aber auch noch einmal in die Datenbank gehen, um das Element zu ändern. Andernfalls hat man zwei Fliegen mit einer Klappe…
Ich sehe es genauso wie mein Vorredner. Zumal sich mir die Notwendigkeit dieser “doppelten Bearbeitungsmöglichkeit” nicht ganz erschließt. Mir reicht der Stammdatensatz und die Möglichkeit, Elemente in einer Playlist temporär in mAirList selbst zu verändern und durch einen Klick auf “Ok” temporär zu speichern.
Ich brauche auch diese Möglichkeit, Elemente schnell bearbeiten und die Änderung dann in die Playlist speichern zu können. In der mAirList-Playlist sehe ich sofort, wenn ein Element noch keine Ramp hat und kann sie schnell hinzufügen und in die Datenbank speichern.
Da in der DB-Verwaltung leider noch spalten wie Ramp-Zeit, Outro-Zeit oder Ramp-Art fehlen ist das hier weniger schnell möglich. Außerdem lande ich in mAirList durch Klicken auf den Vorhören-Button direkt im PFL-Dialog. In der DB-Verwaltung hingegen muss ich mich erst in den Eigenschaften-Dialog klicken, dann die PFL-Registerkarte aufrufen und “PFL starten” anklicken. Für das massenhafte Bearbeiten von Elementen ist das leider zu zeitaufwändig.
Die Darstellungs- und Bearbeitungsmöglichkeiten in der Datenbankverwaltung werden noch verbessert.
Ich kann eure Argumente nachvollziehen. Ich denke, wir werden den “Speichern in Datenbank”-Button auf jeden Fall weiter anbieten. Wenn nur der Stammdatensatz aktualisiert werden soll, kann ich das schnell einbauen. In echten Studio-Umgebungen mit Musikredaktion etc. würde man den Button dann einfach deaktivieren, fertig.
Dass man die Elemente auf Playlist-Ebene anpassen kann, eröffnet ganz neue Möglichkeiten. Zum Beispiel könnte ich mir eine Funktion vorstellen, die eine leicht überplante Playlist von z.B. 1:02 Stunden Länge nimmt und die Fade-Out-Punkte einzelner Lieder so anpasst, dass ein exaktes Backtiming auf die folgende Stunde bei rauskommt. Oder man möchte ein Element mit einer Fixzeit versehen. Auch das ist jetzt möglich, ohne diese Fixzeit generell für das Element einstellen zu müssen.
Wobei: Gehst du bei der überplanten Playlist von einer automatischen Funktion aus? Ich kann mir das nur manuell vorstellen.
Eine Funktion, die bei jedem Titel mal eben so 10 Sekunden wegnimmt, würde ja wenig Sinn machen. Wenn jeder Titel auf einmal zehn Sekunden vor Ende ausgefadet wird, auch wenn er ein richtiges Ende hat…
Das stimmt. Aber auch bei einem Fade Titel müsste das System (zumindest wenn man den Anspruch hat, “richtiges Radio” zu machen) so intelligent sein, dass es den Titel nicht mitten in der Strophe beendet. Sonst hagelt es Beschwerden…
Daraus wird dann vermutlich v3.0.5. In den nächsten Tagen werde ich mit anderen Dingen beschäftigt sein als zu programmieren, daher könnten wir die Zeit vielleicht mal für ein paar “Belastungstests” nutzen.
