Habe mich mal an diesem Forum angemeldet, weil es mich interessiert, ob Mairlist die richtige Software für mein
Vorhaben ist.
Für einen Klinikfunk würde ich gerne mehr auf automation setzen. Zur Zeit laufen dort zusammengesuchte Programme, die eher in der DJ Ecke was zu suchen haben. Auch ist das Verwalten der schon fertig von externen Zulieferern sehr aufwendig. Bis her wird das alles manuell runtergeladen und dann von einem Mitarbeiter passend abgefahren. Das ist sehr personalintensiv und fehleranfällig.
Meine Vorstellungen:
Ich möchte ein Hauptstudio mit weiteren Arbeitsplätzen zum schneiden und vorproduzieren mit zwei oder bald auch evtl. drei weiteren Studios mit ähnlicher Ausstattung vernetzen. Also egal wo ein Beitrag eingesprochen wird, oder anderes Material eingespielt wird, soll das an allen anderen Studios auch vorliegen und da verwednet werden können. Ohne das da manuell rumkopiert werden muss.! Das ganze am liebsten mit einer zentralen Datenbank, die auch die CUE Punkte oder Markierungen für die Ramp mit überträgt. Auch sollte Voicetracking eingesetzt werden. Alles an Material muss in einem platzsparenden Format gespeichert werden, da die Aussenstudios der Zulieferere nur über bestenfalls DSL 8000 angebunden sind.
Schön wäre es, wenn ein interner Scheduler die Playlisten für die unbeaufsichtigten Stunden der Nacht oder die Vorlagen zum Voicetracken erzeugen könnte.
Auch sollte es möglich sein, von externen Quellen Material wie Nachrichten oder sonstiges mit einem üblichen Protokoll wie FTP, Http usw per Zeitauftrag beziehen und einspielen zu können.
Ist sowas zu machen.? Und in welche Höhe (ungefähr) müsste das Budget für z.B. 10 Arbeitsplätze Auspielen bzw. Recorden angesetzt werden.?
Grundsätzlich - die genannten Anforderungen sind ja recht vage - würde ich sagen, dass mAirList dafür gut geeignet ist. Von der Ausspiel-Seite her sowieso.
Etwas problematisch ist derzeit die Sache mit dem Hochladen/Einpflegen von Beiträgen von Arbeitsplätzen außerhalb des LANs. Die mAirListDB möchte grundsätzlich, dass die Beiträge auf einem Netzlaufwerk liegen, das von allen PCs aus erreichbar ist. Das ist bei einem entfernten Arbeitsplatz - ohne VPN oder dergleichen - ja eher nicht der Fall.
Es gibt bereits Möglichkeiten, die Beiträge jedenfalls lesend über HTTP zur Verfügung zu stellen, so dass man sich alles Material von zuhause (oder wo auch immer) anhören kann. Hochladen klappt darüber aber noch nicht, wenngleich es Überlegungen gibt, das demnächst zu realisieren. Das Stichwort lautet hier: Webservice.
Die finanziellen Aspekte sollten wir per E-Mail besprechen.
Selbst bei einem VPN würde die Performance eines DSL ja nie reichen. Die Files müssten an jedem Standort alle verfügbar sein.
Die Datenbank dann ja auch.?
Achso. Also direkt und transparent für den Mod. geht das so nicht.? OK, werd mir die 4er Version mal anschauen.
Also, derzeit brauch man für den Netzwerkzugriff auf die Datenbank:
Zugriff auf den TCP-Port des Datenbankservers (PostgreSQL) - für die Liste der Dateien, Playlists, Metadaten usw.
Irgendeinen Zugriff auf die Dateien selbst - idealerweise als Netzlaufwerk (ggf. per VPN), es geht allerdings auch per HTTP über einen zwischengeschalteten Webserver
Relativ kurzfristig wird es eine Möglichkeit geben, Ausspielstationen über einen einzelnen TCP-Port an so eine mAirListDB-Landschaft zu hängen, über den dann sowohl Dateien als auch Metadaten ausgeliefert werden. Aber im Moment halt nur lesend.
Dass man die gesamte mAirListDB-Verwaltung - incl. Dateizugriff lesend und schreibend - über einen einzelnen TCP-Port abwickelt, ist eine hervorrangende Idee, die allerdings noch etwas Arbeit erfordert.
Ob die Dateien jetzt über VPN oder HTTP oder was auch immer zum per DSL angeschlossenen Rechner übertragen werden, spielt keine große Rolle. Langsam ist langsam. In dem Moment, wo ich die Datei abspielen möchte, muss sie bei mir auf dem Rechner sein, egal auf welchem Wege sie dorthin gekommen ist. VPN bedeutet ja nicht, dass alle Inhalte erst gespiegelt werden. Auch dort werden nur die Dateien beim Öffnen übertragen, und das dauert halt je nach Bandbreite.
Dieses DSL ist ja leider der Flaschenhals. Wenn die SQL Verbindung übers Internet geroutet wird, und die Daten aus der Datenbank für den Betrieb wichtig sind, dann wird die Latenz wohl zu gross sein. Von den Dateien ganz zu schweigen. Im lokalen Netz ist das alles kein Problem…Dann wird nur eine Replizierung helfen.
Die Kollegen der Rundfunkanstalten mit dem dicken Budget haben bei sowas natürlich passende Leitungen…
Die Datenmenge, die über die SQL-Verbindung geht, ist minimal. Da merkt man im laufenden Betrieb kaum einen Unterschied.
Die Audiodateien brauchen natürlich einige Zeit zum Download, das ist richtig. mAirList 4 ist aber so schlau, die nächsten paar Files in der Playlist im Hintergrund schon herunterzuladen und zwischenzuspeichern (zu erkennen an dem kleinen grünen Haken im Icon in der Playlist). Dadurch merkt man bei der Ausspielung auch kaum einen Unterschied, vorausgesetzt natürlich, man schiebt die Dateien rechtzeitig in die Playlist. Sonst dauert’s eben ein paar Sekunden, bis der Player geladen ist.
Die SQL-Verbindung wird alle 10 Sekunden auf Funktionsfähigkeit überprüft und bei Bedarf neu hergestellt.
Die HTTP-“Verbindung” für die Dateien ist ja keine durchgängige Verbindung, sondern es handelt sich um einzelne Anfragen, die jeweils eine neue Verbindung zum Server herstellen. Wenn mittendrin die Zwangstrennung (ich denke, darauf spielst du an) stattfindet, gibt’s halt eine entsprechende Fehlermeldung, dass die Datei nicht (komplett) heruntergeladen werden konnte.
Frage dabei, ob bei Fehlen der SQL Verbindung Mairlist sofort steht.? Die Playlisten sind doch auch in der Datenbank, oder.?
Was wird denn überhaupt lokal gepuffert.? Alles, was in der Liste steht.? Die kann ja auch aus mehreren langen Dateien von jeweils einer Stunde bestehen… Denke nicht, das bei einem Setup mit externen Installationen auf eine syncronisation des Content nach dem Vorbild von rsync verzichtet werden kann…
Die Playlisten (nur die Metadaten, nicht die Audiodateien) der kommenden 24 Sendestunden (Wert in der Konfiguration einstellbar) werden lokal zwischengespeichert für den Fall, dass die Verbindung nicht verfügbar ist in dem Moment, wo die Playliste nachgeladen werden soll.
Was wird denn überhaupt lokal gepuffert.? Alles, was in der Liste steht.? Die kann ja auch aus mehreren langen Dateien von jeweils einer Stunde bestehen... Denke nicht, das bei einem Setup mit externen Installationen auf eine syncronisation des Content nach dem Vorbild von rsync verzichtet werden kann...
Standardmäßig werden die nächsten fünf Titel der Playlist vorgepuffert, bedeutet konkret: ggf. schon heruntergeladen (bei Elementen, die per HTTP angeliefert werden) und dann in einen unsichtbaren Player geladen. Sobald das vorgepufferte Element tatsächlich gespielt wird, wird es dann in den echten Player “verschoben”.
Wenn man eh eine jederzeit aktuelle Spiegelung (mit rsync o.ä.) hat, kann man die mAirListDB auch direkt auf diese Kopie lenken (über die Einstellung “Lokaler Ordner” in der Speicherort-Konfiguration, oder daürber, dass man überall denselben Laufwerksbuchstaben verwendet). Dann kommen nur die Metadaten per SQL, die Dateien werden von der lokalen Platte gelesen.
Das empfiehlt sich sogar in LANs, wenn man besonderen Wert auf Ausfallsicherheit legt. Allerdings sollte man dafür sorgen, dass die Kopie immer aktuell gehalten wird, also alle x Minuten synchronisiert, je nach Bedarf.
Das liesst sich so, als wäre die mairlistdb nicht in die SQL DB integriert.?
Ich hatte jetzt angenommen, das alles! (Clientconfig, Userrechte, Playlisten, Audiodatenbank…in einer zentralen Datenbank liegt, die dann mit den üblichen Tools zur Replikation verteilt werden kann.