Wacken Open Air – Aufbau

Nun ist es offiziell, Wacken Open Air – Live Stream powered by TEMPODOME. Klingt ganz schön super, ist es auch. Jedenfalls freuen wir uns riesig über diese Zusammenarbeit. Seit ein paar Wochen beschäftigen wir uns nun mit den Metalheads und lernen, was es heißt, ein solches Festival durchzuführen. Ich sags mal kurz so: WAHNSINN! Was da alles zusammenkommt und mit welcher Erfahrung, Routine und Übersicht das Ganze abgewickelt wird. Hut ab.
Heute war nun mein großer Tag – ich fuhr nach Wacken zum Ortstermin. Am Ortseingang wurde ich von Wacken-Bannern und Plakatwänden im Empfang genommen, um dann per Ausschilderung zum Check-In vorzufahren. Der Check-In befand sich in eine mittelgroßen Lagerhalle, wo mich ein freundliches Mädel empfing und mir so ein Tüdelbändchen mit einer amtlichen Plombe ums Handgelenk wickelte – „Working Crew“. Dann noch ‘ne Parkmarke und eine kurze Wegbeschreibung und Schwups stand ich vor der Backstage-Zufahrt. Nach eine kurzen Kontrolle fuhr ich also über das Gelände zum Production Office. Auf dem Weg kam ich an Bergen von Gerüstbau-Material und Dutzenden von Baufahrzeugen vorbei – aha, irgendetwas bauen die hier wohl auf: Ein ganzes Dorf aus Containern und dazu 3 riesige Bühnen und eine mittelgroße Zeltstadt – keine Fragen, hier die Bilder

Im Anbetracht der ganzen Dimension guckt man gern mal wie wichtig die Produktion des Live-Streamings ist. Linker Container – mehr brauchen wir nicht.

Vertrag kommt von „sich vertragen“.

Dass Vertrag von „sich vertragen“ kommt, mag ja sein, aber der Weg zum Vertrag ist ein langer. Besondere Schwierigkeit in unserem Fall, es soll ein Vertrag zwischen drei Parteien werden – und nun sitzen wir dran und schieben Verantwortlichkeiten, Rechte und Pflichten von links nach rechts, machen uns Gedanken, wie wir bestimmte Dinge gern regeln würden. Ein sehr mühsamer Prozess, es gehen Mails hin und her, es wird telefoniert, man ist sich inhaltlich einig, nur will die „Papierform“ nicht gelingen. Seltsam.

Am Ende steht man sich quasi für den Handschlag gegenüber und macht einfach mal weiter, ohne die letztendliche Unterschrift – die Zeit will einfach nicht verschenkt werden.

Nachtrag:

Verträge in der Musik-Branche haben ihren eigenen Charm.

Skalierung – kein Spaß.

In dieser Woche haben wir uns aus technischer Sicht erneut mit dem Thema der Skalierung unserer Chat-Applikation beschäftigt, da wir am Horizont schon sehr deutlich unsere nächste Herausforderung sehen können. Der Chat ist heute eine doch sehr einfach zusammengebaute FMS-Anwendung (Flash Media Interactive Server), die über eine Aufteilung von Usern in Chaträume die Interaktion der User vor der Online-Bühne steuert. So weit, so gut. Unser Modell funktioniert bis ca. 1000 Usern wunderbar, der Server liegt bei 25% Last auf einer CPU, Hauptspeicher bei 80 MB, alles prima. Nun geben wir ein paar User mehr hinzu und die Sache eskaliert – 2000 User wurden nie erreicht bevor die CPU am Ende war. Zugegeben wir haben die User auch ca. alle 300ms von mehreren Clients gleichzeitig hinzugefügt, aber das soll keine Entschuldingung sein. Die Anwendungsarchitektur ist hier der limitierende Faktor.
Schnell wurde die altgekannte Liste der Alternativen hervorgeholt:

1. Jabber-Chatserver (Openfire) und Flash-Client (XIFF)
2. Red5-Server – Lizenzfrei und serverseitige Entwicklung in Java
3. Anwendungsarchitektur umstellen

Die Entscheidungen fielen aufgrund des enge Zeitrahmens sehr schnell. Als kurzfristige Lösung sollte die Architekturumstellung durchgeführt werden, da wir uns hier mit eigenen Mitteln sehr schnelle Ergebnisse erhoffen, die uns auch jenseits der 10.000 User skalieren lassen. Mittel- bis langfristig soll der Umstieg auf einen XMPP-Server fokussiert werden, da wir hier zusätzlichen zu der einfacheren Skalierung auch den Vorteil eines offenen Standards hinzugewinnen können. Gesagt getan, zwei Teams, zwei Aufgaben. Wir sind gespannt auf die Ergebnisse.

ENERGY in the Park 2008

Wahnsinn! Am gestrigen Samstag haben wir 6 Stunden lang aus Berlin das ENERGY in the Park 2008 direkt vom Standbad am Wannsee übertragen. Das war ein wahrer Übertragungsmarathon, ganz zu schweigen von den tausend kleinen Einzelheiten die im Vorfeld einer solchen Veranstaltung alle schiefgehen können und natürlich genau dann, zwar immer ein wenig anders, auch garantiert eintreten. Aber so langsam bekommt man tatsächlich Routine im Krisenmanagement kurz vor der Übertragung, hier noch ein Problem mit dem Server, mit dem Upstream und mit der dem IE 6 – super, alles am Samstagmorgen. Tja und manchmal kann man auch einfach mal nichts machen – so bei uns -wenn die liebe T-Com einen Upstream von 768kBit/s nach ursprünglicher Anforderung von 2MBit/s als „sicher!“ zusagt und wir am Ende mit hängen und würgen knapp 480kBit/s maximal und manchmal sogar nur 350kBit/s durch die Leitung bekommen. Super! Glanzleistung liebe T-Com. Für alle Zuschauer die den ein oder anderen Wackler in der Übertragung hatten, möchte ich eine große Entschuldigung aussprechen, aber wir haben wirklich alles versucht. Anbei trotzdem ein paar schöne und lustig Impressionen von Online-Event.