Nun, daher bin ich ja auch relativ schnell davon abgekommen.
Auch wenn ich nicht Tom bin, würde ich aus Sicht eines Radiomoderators und/oder -betreibers folgende Begründung liefern:
Es ist deutlich mehr möglich mit Netzwerklaufwerken als mit der reinen Datenbankverbindung, da ich so beispielsweise Rohdateien für eine etwaige Nachbearbeitung zwischen den Studios austauschen kann, ohne die Datenbank mit Material zu belasten, das ohnehin nicht sendefähig ist (Studio A nimmt bspw. für den nächsten Tag etwas auf und Studio B/Redaktion kann es dann schneiden und nachbearbeiten).
Darüber hinaus lassen sich zwischen den Räumen dann auch mal Dateitypen austauschen, die gar nicht erst in die Datenbank importiert werden können/sollten. Primär hat da nämlich Audio etwas zu suchen, aber in der Regel keine Word-/PDF-Dateien oder z. B. Scripts für die Konfiguration.
Aus der täglichen Praxis kann ich sagen, dass es so sehr bequem ist und schnellere Möglichkeiten bietet. Ich nutze diese Funktion sehr gerne und kann sie nur wärmstens empfehlen!
4 Likes
Ich lege lediglich die für ein Netzwerk und mAirList vorgesehenen Möglichkeiten dar.
Soweit ich mich erinnern kann, ist das mAirList Server Programm (dbserv.bat) ja genau dafür entwickelt worden oder?
Alternativ eben direkt über die Netzwerkanbindung der Datenbank inclusive Filesystem.
Da ein Netzwerk vermutlich eh vorhanden ist.
Warum sollte man über ein bestehendes Netzwerk noch einmal eine Client/Server Architektur legen?
Weil es die Synchronisation zwischen den beiden Ausspielern vereinfacht?
Wir reden hier beide über den DB Server?
Was wird an der Stelle “wie” vereinfacht?
Weiß ich nicht. Du nanntest eine Architektur. Ich meine auch eine, nicht näher spezifizierte.
Danke für die ganzen Antworten!
Dies wäre wahrscheinlich die beste Option für mich! 
Nun da ich im Bereich Script und Datenbanken noch wenig Ahnung habe… bräuchte ich beim einrichten Hilfe. Könnte sich jemand vielleicht bisschen zeit für mich nehmen? Wäre sehr dankbar! 
Ist denn sämtliche Hard und Software vorhanden?
Sollen es nun 2 oder 3 Systeme sein?
Hardware ist da! Die Software muss ich noch besorgen, das kann aber erst Anfang nächsten Monat erfolgen.
Kann ich das nicht mit der Testversion schon ausprobieren?
Bin der Meinung dass, 3 Systeme besser wären!
Das ist nachvollziehbar und kann als “on top”-Mehrwert angesehen werden. Mit der Nutzung der reinen Audiofiles der Datenbank jedoch sollte das nichts zu tun haben bzw. in gewissen Fällen raten wir sogar davon ab.
Begründung:
Es gab im Support immer wieder mal Fälle, da referenzierten die Ausspieler auf ein Netzlaufwerk (warum auch immer). Das Playout warf vereinzelt, und das im Nachtprogramm, einen ERROR aus und das Notband sprang an. Natürlich außerhalb unserer Ansprechzeiten und am nächsten Morgen war dann erst mal Großalarm, weil mAirList schuld war. Klar, was auch sonst?
Ein Blick in die “fehlerhaften” Dateien ergab dann, dass ihr Ablageort U:\Radio\einekleineNachtmusik\ war und wir bei der Analyse des Dateisystems - also außerhalb mAirList - festgestellt haben, dass U:\ gar nicht (mehr) verbunden war bzw. nicht wiederverbunden wurde. Das kann also, je nach Gestaltung, eine ganz üble Fehlerquelle sein, denn mAirList sucht sich nach dem (aktuell nicht vorhandenen) Dateipfad erstmal dumm und dusselig.
Was Oliver beschreibt, kann man nutzen, klar; bei Audiodateien im Playout möchte ich zur Zurückhaltung raten.
Die direkte Verbindung zur Datenbank ohne Netzlaufwerk-Buchstaben erscheint, zumindest mir, betriebssicher. Und genau ist doch das Anliegen des TE?
Nicht im LAN, nein. Primär hat es eine andere Aufgabe:
mAirListDB Server is an application that allows you to share a mAirListDB over the public Internet.
Quelle: tutorials:mairlistdb:mairlistdb-server [mAirList Wiki]
Was TomJumbo83 da anspricht, ist eine beliebte Privatanwender-Lösung, weil der mAirListDB Server bereits in der Edition mAirList Advanced Server zur Verfügung steht und man auf dieser Ebene im Heimbereich auf die (lokale!) Datenbank des zweiten Rechners zugreift. Da macht es auch nichts aus, kurz mal das eigene LAN zu verlassen, ins Internet zu gehen und dann wieder das gleiche LAN zu betreten.
- Ob diese Hintertür bereits innerhalb des Routers abgekürzt wird, können die Spezialisten besser beurteilen. -
Nicht “alternativ”, sondern primär.
Einerseits schlägst du den Einsatz der PostgreSQL im heimischen LAN mit mAirList Professional Studio vor, andererseits kommst du dann mit dem mAirListDB Server um die Ecke. Das passt nicht wirklich zusammen.
Ich denke, dass wir hier gerade Erfahrungen aus Privatanwender-Lösungen (TomJumbo83, ssnoopy) mit professioallen Lösungsansätzen (Tondose) vermischen.
Nichts gegen ambitionierte Privatanwender, aber im Zweifel sollte der besten Lösung Vorzug gegeben werden: Damit meine ich die ohne Hilfsmittel.
Aus diesem Grund plädiere ich dafür, das stärker zu trennen und uns auf die Anforderungen des TE zu konzentrieren.
Das ist durchaus möglich.
Wende dich bitte zu den üblichen Büro- / Ansprechzeiten an sales@mairlist.com mit einer konkreten, ausführlichen Projektvorstellung, dann sehen wir weiter.
Das “warum auch immer” trifft es schon ganz gut. Das ist natürlich ein unschöner Anwendungsfehler, mit dem ich ehrlich gesagt nicht gerechnet habe… 
Im Playout hat logischerweise nur Datenbankmaterial etwas zu suchen. Ich war der Überzeugung, dass das klar sei, aber viele Anwender überraschen mich dann doch immer wieder aufs Neue. 
Das möchte ich noch mal unterstreichen: Die Datenbank muss dringend getrennt von solch einem Netzwerklaufwerk betrieben werden. Meine Idee war hier, dass das Netzwerklaufwerk zusätzlich implementiert wird, um den “Workflow” zu verbessern. 
Na ja, ich denke zunächst nur darauf herum. Tatsache ist, daß in allen Fällen einer Heim-Webradio-Anwendung eine Ein-Rechner-Lösung völlig ausreichend ist. Ebenso Tatsache sind dann Schwierigkeiten, wenn zwei oder mehr Ausspielstationen (vulgo Studios) beteiligt sind. Wie gesagt können die Lösungsansätze unterschiedlich aussehen.
In der professionellen Welt werden die Audiofiles und Playlisten jedoch immer in einer zentralen Datenbank auf einem extra Server (welche natürlich doppelt, gespiegelt vorhanden sind) vorgehalten. (Das meinte ich mit meiner Bemerkung, @ssnoopy). Das Material für z. B. einen Sendetag wird (komplett!) im voraus auf einem Ausspielrechner im Studio zwischengespeichert, gegebenenfalls mit Platzhaltern für aktuelle Beiträge usw. Damit ist man gegen den Ausfall des Servers recht gut abgesichert, die Crew hätte dann mindestens eine Nacht Zeit zur Fehlerbehebung.
Fällt wiederum das Studio aus, lädt man auf den Ausspielrechner im Havariestudio die Playlist und die Audiofiles (wiederum alle) der folgenden Stunden einschließlich der aktuellen. Nach ein paar Löschungen in der aktuellen Stunde läßt sich dann ungestört weitersenden.
Es bleibt zunächst die Frage, ob die von @dieserkamil geforderte totale Ausfallsicherheit eine kompromißlose Randbedingung oder eher ein sportlich-schickes Nice-to-have ist. Man kann natürlich, soll lediglich nach einem Studioausfall der Äther mit Musik befüllt werden, auch auf einen Stream zurückgreifen, der automatisch die Ausspielung eines Havarieprogrammes übernimmt. (@shorty.xs verfährt so, soweit ich weiß.) Im ersteren Falle bezweifle ich, daß mAirList dafür ein geeignetes Programm ist, weil da doch einige Single-points-of-failure übrigbleiben (Serverausfall, Ausfall der Internetverbindung usw.). Für einen Ausfall des LAN-Netzwerkes an sich (so mit die grausligste Situation) müßten ohnehin, wie beim „großen Vorbild“ auch, nochmal Extramaßnahmen getroffen werden.
1 Like
Ich warte jetzt einfach mal in aller Ruhe die Mail ab, wie die Anforderungen lauten und wie streng die Vorgaben sind. Dann schauen wir nach möglichen Lösungen.
Ohne den Wunsch nach möglichst perfekter Synchronisation kleinreden zu wollen: Aktuell ist mir kein Kunde bekannt, der eine solche Lösung in Betrieb hätte. Zwei Studios, Datenbank, Redaktionsplätze: Alles kein Problem. Und wenn’s im Studio A knallt, ist Studio B dran. Im fliegenden Wechsel. Geht alles.
Davon sind auch “die großen” nicht verschont:
In der letzten “Die Morningshow” mit Michael Wirbitzky und Sascha Zeus auf SWR3 gab es das unfreiwillige Thema “Karnevalsumzug”.
Genauer gesagt: ein “Umzug” in ein anderes Studio wurde notwendig, weil (Zitat) “hier stürzt gerade das gesamte Studio ab” - zumindest wurde später ein erfolgter Umzug erwähnt.
Quelle: Pannen über Pannen! ...am besten alle hier rein! | Seite 145 | radioforen.de, abgerufen am 20.03.2023.
Und wie man ein nahezu “totes” Studio souverän meistert (das Mikrofon und der Kopfhörer wurden ja immerhin noch versorgt) bzw. wie man bis zum Eintreffen eines Technikers improvisieren kann, lässt sich bei Radiopannen nachhören:
Anette Herbst übt sich im Improvisieren: Und das ganze sechs Minuten lang, in der Klassik-Frühsendung „Mattinata“ im Schweizer Radioprogramm DRS 2. Was hätten andere Moderatoren wohl getan, wenn plötzlich alle CD-Player ihren Dienst verweigern?
Nochmals: Das Streben nach Perfektion ist dem Projekt hoch anzurechnen, aber (nicht nur) bei SWR3 oder DRS 2 arbeiten auch nur Menschen, die mit allfälligen Problemen umzugehen wissen.
Bei den meisten Webradios gibt es nicht nur einen Single Point of Failure. mAirlist ist da vermutlich das geringste Problem.
Ja richtig @Tondose wir nutzen im wesentlichen 2 Dinge,
- den Stream Monitor von mAirlist. Sollte also ein Studio während der Sendung ausfallen, übernimmt die Automation wieder. Da wir das alle nur als Hobby betreibern, nicht jeder einen dedizierten Senderechner hat und wir alle privatkunden Neuland, äh Internet haben, kommt sowas gelegentich vor.
- Failover Punkte im Icecast befeuert von Liquidsoap, damit habe ich verzahnt auf beiden Icecast Streamservern die Möglichkeit einen Havariebetrieb zu fahren, der erfordert aber manuelles Eingreifen, je nach Problemgröße auf dem Hauptsystem. Grundsätzlich kann da aber jeder Moderator auch erstmal einspeisen wenn mAirlist Down sein sollte.Genau genommen ist das ein Fall-Forward und kein Fall-Back.
Natürlich wollen wir das technisch möglichst professionell aufstellen am Ende muss man die Kirche aber auch mal im Dorf lassen. Es ist halt ein Hobbyprojekt (ohne das als Ausrede zu Nutzen, weil ich Dinge nicht verändern/ verbessern will), wenn es denn mal zu einem Ausfall kommt, dreht sich die Welt definitiv weiter auch wenn bei uns der Stream tot ist.
1 Like
Das war mehr so eine Idee. Zwei Beiträge weiter rede ich das selber klein. Denn: WIe oft kommt denn der Fall überhaupt vor? Dreimal am Tag? Sicher nicht. Und schließlich: Leute – es ist „nur“ Radio. Keinem wird etwas bei einer Panne passieren. (Wobei mAirList für mich nicht die erste Wahl wäre, müßte ich z. B. ein Kernkraftwerk steuern.)
1 Like
Tja, die Ausfallsicherheit.
Das beginnt schon mit der USV in Studios und Serverräumen (mindestens aber ein Puffer zum Runterfahren) und endet…
… zwar nicht mit der Grundversorgung eines Kernkraftwerkes, aber was passiert,
Wenn die Wolke sich in Rauch auflöst
, Quelle
Gemeint ist ein Szenario, was vorher wie eine überspitzte Übertreibung gewirkt haben mag:
Erinnert ihr euch an das Feuer im OVH-Rechenzentrum in Staßburg in der Nacht auf den 10.03.2021?
Zitat aus dem Handelsblatt vom 07.04.2021, Stand 18:00 Uhr; Redakteure: Christof Kerkmann und Stephan Scheuer:
OVH bietet zwar an, eine Sicherheitskopie in einem mindestens 200 Kilometer entfernten Rechenzentrum zu speichern. Für diese Synchronisierung – im Jargon des Dienstleisters Georedundanz – müssen Kunden jedoch extra zahlen. Wie viele das tun, legt das Unternehmen nicht offen. Es ist zu befürchten, dass so mancher Kunde darauf verzichtet hat.
(…)
„ Das Entscheidende, das man verstehen muss: Ein Unternehmen hat die gleiche Verantwortung wie zuvor im eigenen Rechenzentrum – nur dass die Infrastruktur und Daten nun woanders liegen“, sagt René Büst, Analyst beim Marktforschungsunternehmen Gartner.
(…)
Bei „sehr hohen Anforderungen an Verfügbarkeit und Sicherheit“ empfiehlt der Verband der Internetwirtschaft Eco die Speicherung in zwei geografisch getrennten Rechenzentren. „Damit wären die Daten sogar bei extrem unwahrscheinlichen Eventualitäten wie Bränden oder infolge von Naturgewalten wiederherstellbar.“
So, und JETZT reden wir über Betriebssicherheit. 
Das ist der Grund weshalb ich zuimndest beide Streamserver bei unterschiedlichen Hostern in definitiv unterschiedlichen Rechenzentren gebucht habe. Ein Ähnliches Szenario haben wir nämlich breits durch, nur wir waren bei einem Hoster, der dort seine Server gemietet hatte und deshalb hingen wir ganz hinten dran mit der Problemösung und unser vServer mit dem Streamserver drauf war um die 2 Wochen komplett down. Die konnten uns nicht einmal sagen, wann das Problem gelöst wird, weil sie selber nur Kunde sind.
Da hatte ich noch nicht so viel mit der Infrastruktur zu tun, deshalb bekomme ich das nicht mehr ganz auf die Reihe.
Korrekt! Webradio ohne Grundversorgungsauftrag. Wir müssen jetzt halt abwarten, wo @dieserkamil die Kirche hinstellen will.
Ich entschuldige mich, dass ich heute keine Antworten gab, bin ziemlich im Stress!
Melde mich Morgen!
Mfg Kamil