Robbinaer

Dokumentationen sind gut, eigene Kreativität beim Umsetzen der Anweisungen ist aber auch nicht verkehrt - so jedenfalls meine Erfahrung des gestrigen Abends. Kopfzerbrechen bereitete mir da der ProFTPD-Server, welcher unter Debian Jessie offenbar recht seltsame Voreinstellungen mitbringt.

Ein neuer Server, ein neues Debian, ansonsten aber dieselben Software-Komponenten mit weitgehend identischer Konfiguration, das machte die Migration der Daten relativ einfach. Dann natürlich die vielen Kleinigkeiten und Tweaks, die man sich besser irgendwo notieren sollte, um sie beim nächsten Umzug wieder zur Hand zu haben. Manchmal treten jedoch auch neue Probleme auf, von denen vorher nie eine Rede war. So geschehen, als mich eine Freundin, die bei mir Webseiten und Dateien hostet, darauf aufmerksam machte, dass sie während FTP-Uploads Verbindungsabbrüche erleidet, welche die angefangenen Übertragungen komplett zurücksetzen, sodass sie mit dem Hochladen wieder von vorn anfangen muss. Bei großen Dateien und einer schmalen Bandbreite ist das natürlich ärgerlich. Also kurz gecheckt, ob auf dem Server alles in Ordnung ist. "AllowStoreRestart" war in "/etc/proftpd/proftpd.conf" wie erwartet auf "on" gesetzt, Netzwerkprobleme beim Server waren ebenfalls nicht erkennbar. Kurz noch mit einer eigenen Datei getestet, ob "AllowStoreRestart" tatsächlich greift, dann die Sache mit einem "liegt halt an deiner Verbindung" abgehakt, wie es sich für einen guten Hobby-Admin eben gehört, dessen Fußvolk ohnehin alle Probleme selbst verursacht. :)

Tja, wenn da diese "penetranten" User nicht wären. Die Verbindungsabbrüche blieben, also habe ich im Weltnetz nach möglichen Ursachen und Lösungen geforscht. Jemand schlug vor, ganz einfach die Timeout-Einstellungen auf 0 zu setzen, sodass der Server die Verbindung geöffnet hält. Hmm, wann er unter der Last hunderter offener TCP-Verbindungen wohl zusammenbrechen würde? Nein, das war also keine Option.

Der ausschlaggebende Hinweis kam dann jedoch von meiner Freundin, die dadurch von jeglicher Mitschuld freigesprochen war, sieht man mal davon ab, dass die Verbindungsabbrüche durch ihr wackliges WLAN passierten. Entscheidend zur Problemfindung war, dass nur jene Dateien, die korrekt während des Uploads pausiert wurden, auf dem Server erhalten blieben und später fortgesetzt werden konnten. Wurde eine Verbindung aber unerwartet unterbrochen, verschwanden die bisher hochgeladenen Daten vom Server, und man musste von vorn anfangen. Dies konnte ich zweifelsfrei reproduzieren, also ging die Suche jetzt zielgerichtet weiter.

Fündig wurde ich recht schnell in der ProFTPD-Dokumentation. Die Option "DeleteAbortedStores" sah ganz danach aus, als könnte sie mir weiterhelfen, aber:

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded HiddenStores files if the transfer is stopped via the ABOR command rather than a connection failure.

Nun, es vergingen weitere grüblerische Minuten, bis ich mich dann dazu durchringen konnte, diese eigentlich unsinnig erscheinende Option dann doch einfach mal auszuprobieren. Also in der ProFTPD-Konfiguration die Option "DeleteAbortedStores" hinzugefügt und auf "off" gesetzt. Siehe da, nach einem Neustart des Dienstes funktionierten die Uploads wieder so, wie sie sein sollten. Offenbar war die Dokumentation in diesem Punkt schon etwas veraltet, wie ich wenig später herausfand, als ich eine leicht abgewandelte Formulierung in der Dokumentation des Mod_xfer-Moduls fand:

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the FTP ABOR command (as opposed to a connection failure). By default, DeleteAbortedStores is off; however when HiddenStores is enabled, then DeleteAbortedStores is automatically enabled as well.

Fall erledigt, Freundin wieder glücklich. Das nächste Mal überlege ich mir aber schlagkräftigere Argumente, damit endlich wieder der User die Schuld tragen kann! :)

Wenn man einen eigenen Server betreibt, ist natürlich auch das Wissen über die Zuverlässigkeit sehr wichtig. Um über Ausfälle benachrichtigt zu werden, nutze ich den Dienst Uptime Robot und bin damit sehr zufrieden. Bereits in der Gratis-Variante lassen sich Features nutzen, die man anderswo nur gegen Geld bekommen würde. Es lassen sich bis zu 50 Monitore anlegen, die dann alle 5 Minuten geprüft werden. Fällt einer der Monitore aus, wird eine Benachrichtigung an die zuvor hinterlegten Alert-Kontakte gesendet. Hierbei können E-Mails, Twitter-Direktnachrichten, SMS oder Pushbenachrichtigungen auf Smartphones und Tablets gesendet werden. Gegen einen geringen Aufpreis lässt sich das Prüfintervall auch auf bis zu eine Minute herabsetzen.

Uptimerobot bietet zahlreiche Möglichkeiten, den Status eines Dienstes oder ganzer Server zu überwachen, darunter HTTP- und Ping-Abfragen sowie Keyword-Alerts. Vor allem die Keyword-Alerts sind nützlich, um den Status bestimmter Dienste oder Webseiten zu prüfen. Hier geht es nicht so sehr darum, ob ein Server ausfällt, sondern ob sich der Status eines laufenden Prozesses ändert. Ein Anwendungsfall hierfür ist die Überwachung eines Streaming-Servers auf Source-Verbindungen hin, also ob jemand auf diesem Server sendet oder nicht. Um einen solchen Monitor einzurichten, geht man wie folgt vor:

1. Im Dashboard auf "Add new monitor" klicken.
2. "Friendly name": Ein Name für den Monitor, z. B. Sendestream.
3. "URL (or IP)": Die Adresse zum Streaming-Server inklusive Port. Soll ein Icecast-Server überwacht werden, auf welchem mehrere Mountpoints laufen, empfiehlt es sich, den Mountpoint an die URL anzuhängen, z. B.: http://server:Port/status.xsl?mount=/Mountname.mp3. Auf diese Weise wird nur dieser eine Mountpoint berücksichtigt.
4. "Keyword": Hier wird ein Schlüsselwort eingetragen, auf das der Robot anspringen soll. Es muss eine Zeichenkette sein, welche nur dann auf der Webseite zu sehen ist, wenn der Stream aktiv ist oder inaktiv, je nachdem, welches Ziel man verfolgt. Beispiele für Icecast wären "Currently playing" oder "Stream started". Letzteres empfiehlt sich dann, wenn der Icecast-Mountpoint eine Fallback-Datei angegeben hat, da bei solchen Mountpoints auch dann noch "Currently playing" als leerer Wert angezeigt wird, wenn niemand darauf sendet.
5. "Alert when": Hier wählt man aus, wann der Robot eine Benachrichtigung senden soll - Schlüsselwort existiert oder existiert nicht. Im Icecast-Beispiel ist die Schaltfläche "Keyword Exists" am sinnvollsten.
6. Nun noch die Alert-Kontakte anhaken und den Monitor speichern.

Ist der Streaming-Server online, aber kein Sende-Client verbunden, erfolgt zeitnah eine Benachrichtigung und es kann schnell eingegriffen werden, um den Sendebetrieb wieder aufzunehmen.

Ein ernst zu nehmender Programmierer war ich nie und werde es wohl auch nie sein. Meine Erfahrung dahingehend beschränkt sich zumeist auf das Modifizieren existierender Codebeispiele, um nicht zu sagen schamloser, aber nicht allzu offensichtlicher Klauerei. :) Dennoch haben sich über die Jahre einige Tools angesammelt, die eigentlich zu schade zum Wegwerfen sind und dem ein oder anderen vielleicht noch nützlich sein können, sei es auch nur als Anschauungsmaterial für miesen Code. Deshalb habe ich mir mal die Zeit genommen, mein schon länger existierendes GitHub-Profil etwas aktiver zu nutzen und dort ein wenig Code hochzuladen bzw. mich an anderen Projekten zu beteiligen.

Neben meinem Streamkick-Tool, das erstaunlicherweise immer noch auf Interesse zu stoßen scheint, findet sich dort auch mein erstes Plugin für das Markdown-CMS Yellow. Dieses Plugin lädt automatisch die für die von Heise Online programmierten Shariff-Buttons benötigten CSS- und JS-Dateien, sodass man die eigentlichen Social-Sharing-Buttons nur noch über das Div-Element an beliebiger Stelle platzieren muss. Des Weiteren werde ich GitHub für meine Übersetzungsaktivität z. B. beim TeamTalk-Projekt nutzen.

Screen-Reader-Nutzer unter Linux dürfen sich freuen: Gestern wurde Version 1.0 der Voxin-Sprachausgabe veröffentlicht. Hierbei handelt es sich um die Linux-Portierung der von IBM entwickelten Text-To-Speech-Engine ViaVoice, die inzwischen zwar nicht mehr weiterentwickelt wird, sich jedoch nicht zuletzt durch den vom JAWS-Bildschirmleser bekannten Ableger Eloquence immer noch großer Beliebtheit erfreut. Da viele der zeitgemäßeren kommerziellen Sprachausgaben für Linux nicht verfügbar sind, ist Voxin momentan somit eine zwar proprietäre, aber eine der besten Alternativen zur quelloffenen eSpeak. Sie kann in Verbindung mit Speech-Dispatcher als Sprachausgabe mit Orca verwendet werden und ist auch im Audio-Desktop Emacspeak nutzbar.

Voxin wird von Oralux betreut, einer Non-Profit-Organisation, die sich für die Zugänglichkeit quelloffener Software einsetzt. Die Sprachausgabe an sich kann dabei nicht weiterentwickelt werden, wird aber an aktuelle Distributionen angepasst. Version 1.0 erschien nach einer längeren Pause und bringt unter anderem Unterstützung für Debian Jessie und Ubuntu 15.10/16.04 mit, außerdem wurde die Integration in 64-Bit-Systeme optimiert.

Die Liste brauchbarer Standalone-Audio-Streamer für Windows ist sehr überschaubar. Als populäre Gratis-Lösung sind zwar immer noch diverse Oddcast/Edcast-Forks im Umlauf, deren Weiterentwicklung ist jedoch sehr fraglich. Längst gibt es Protokolle und Features, die nicht mehr unterstützt werden, so etwa Shoutcast2. Dieses Protokoll ist bislang neben dem originalen Shoutcast-Streamer nur noch in kommerziellen Streaming-Automationen enthalten. Doch man muss nicht hunderte Euro ausgeben, um von aktueller Software zu profitieren, denn einige Software-Anbieter stellen ihre Streaming-Clients auch als Standalone-Lösung zur Verfügung.

StationPlaylist.com, Entwickler einer der verbreitetsten Radioautomationslösungen, stellt mit dem StationPlaylist Streamer eine preisgünstigere Standalone-Software zur Verfügung, welche das Eingangssignal einer Soundkarte an beliebige Streaming-Server im Internet senden kann. Der Streamer basierte ursprünglich auf einer angepassten Oddcast-Version, ist mittlerweile jedoch als Eigenentwicklung zu betrachten. Neben Icecast und Shoutcast in Version 1 wird auch das neue Shoutcast2-Protokoll unterstützt, des Weiteren die Verbindung zu Windows-Media-Servern. Winamp-DSP-Plugins erlauben das Einbinden von z. B. Compressor/Limiter-Effekten in den Signalweg. Das Auslesen von Metadaten, also die Infos zum gerade gespielten Song, erfolgt über Fenstertitelklassen, URL oder eine TeXtdatei. Mit $86 ist der Streamer jedoch immer noch verhältnismäßig teuer.

Deutlich preisgünstiger und vielfältiger im Funktionsumfang ist der RadioCaster von djsoft.net. Er bietet ähnliche Features wie StationPlaylist Streamer, geht jedoch in einigen Punkten noch mehr ins Detail. So ist es bei der Wahl der Eingangs-Soundkarte möglich, beim verwendeten Soundsystem zwischen DirectSound, ASIO oder WASAPI zu wählen, sofern die Soundkarte dies unterstützt. Des Weiteren lässt sich RadioCaster auch als Transcoder verwenden, d. h. zum direkten Umwandeln und Weiterverbreiten bestehender Internet-Streams. Neben einem integrierten Equalizer und Compressor/Limiter erlaubt das Tool auch die Einbindung von Winamp- und sogar VST-Effektplugins. Auch der Metadaten-Abruf ist detailreich konfigurierbar und gestattet sogar einige individuelle Einstellungen für jeden Encoder. Ein nettes Zusatz-Feature ist das Statistik-Modul, welches für jeden Stream die Hörerzahlen anzeigt, und man so sein Publikum stets im Blick hat. Einzig an der Screen-Reader-Zugänglichkeit hakt es an einigen Stellen noch etwas, jedoch sind die notwendigsten Funktionen gut zugänglich, und der Rest kann notfalls auch über eine problemlos lesbare Konfigurationsdatei angepasst werden.
RadioCaster ist für umgerechnet knapp €40 zu haben und wird ein Jahr lang mit kostenlosen Updates versorgt, danach ist eine Update-Gebühr fällig. Ob die Lizenz an den Computer gebunden ist oder auch auf mehreren Geräten aktiviert werden kann, entzieht sich momentan meiner Kenntnis. Imho ist der Preis jedoch dem Funktionsumfang völlig angemessen.

Derzeit leistet mir Edcast noch gute Dienste, daher sehe ich noch keine Notwendigkeit, auf ein kommerzielles Produkt umzusteigen. Jedoch ist es gut zu wissen, dass man nicht gleich eine große Radioautomation kaufen muss, um einfach nur ein bisschen Radio zu machen.