Webshout – Music anywhere – Die zweite Version
In einer Reihe von Beiträgen möchte ich gern über ein Software-Projekt berichten, was mich die letzten Jahre begleitet hat. Es handelt sich dabei bislang um ein rein privates Projekt.
Anfang 2009 hat der alte Rechner seinen Geist aufgegeben und wir mussten einen “Neuen” installieren. Das erwies sich als ein Problem, was mich zum kompletten Neubau von Webshout verleitet hat. Der alte Rechner diente als Webshout-Server und als Fileserver für Backups. Aus dem Grund hab ich, bis auf Security-Updates, nichts an dem System gemacht. Nachdem der neue Rechner (Ein Celeron 133) aufgesetzt war, mit zu dem Zeitpunkt aktuellen Linux-Version, lies sich keines der C++ Tools mehr kompilieren. Grund dafür war, dass sich die verwendeten APIs über die Jahre natürlich verändert haben. Ein Um- bzw. Neubauen der Tools war daher fällig.
Ich habe mich damals entschlossen, das komplette System neu zu bauen. Mich störten einige Dinge zu sehr: Der C++ Part, der die mp3 Dateien indiziert hat, musste auf der Konsole angeschmissen werden, Webseite und C++ Streaming-App kommunizierten über ein simples TCP-Protokoll. Die Streaming App hat einen Socket zum Lauschen offen gehabt, PHP hat drauf verbunden und Befehle geschickt. Zu guter letzt, war die Navigation teilweise mühsam, das Suchen langsam und über die Zeit stelle ich fest, dass die Datenstruktur in der Datenbank Stressig war, wenn etwas verändert werden musste. Alles nicht Grund genug, um es einfach so zu tun, aber wo ich eh ran musste …
Webshout 2.0 ist mittlerweile ein Java-Server, der für alles zuständig ist. Die Webanbindung läuft über einen integrierten Jetty Webserver, die mit einem eigenen “MVC” System mit Velocity als Template-Engine gesteuert wird und die Suche wird von Lucene übernommen. Probleme haben am Ende exakt die Teile gemacht, die vorher in C++ implementiert waren. Es gab keine mich zufrieden stellende ID3-Lib für Java und die verfügbaren Java-Libs zum Streamen mit dem shoutcast-Protokoll waren total veraltet und extrem Buggy. So war es z.b. nicht möglich (Obwohl die Lib explizit als Threadsafe beschrieben wurde) 2 Streams parallel zu fahren.
Gelöst hab ich das Problem mit JNI. Ich hab die mir bekannten und mich zufrieden stellenden C/C++ Libs genommen, ein JNI Binding für implementiert und alles läuft, wie es laufen muss. Der einzige Nachteil an der Nutzung von JNI ist, dass ich nun daran gebunden bin, für das OS, auf dem Webshout gerade läuft, einen C++ Compiler vorliegen zu haben, der die entsprechenden Sourcen kompiliert. Da ich für solche Zwecke aber eh immer ein Linux am Laufen habe, ist das egal.
Webshout 2.0 läuft seit Anfang 2009 durchgehend ohne große Probleme. Das Einzige, was mich noch störte, war die Art und Weise, wie Dateien indiziert wurden. Der Server ist das Dateisystem rekursiv durchgelaufen und hat Musik-Files gesucht. Webshout 2.0 hat hierfür zwar die Möglichkeit den Startpfad anzugeben, sodass wirklich nur die Verzeichnisse durchsucht werden, bei denen sich was geändert hat, aber hat man viel neue Musik hochgeladen, war es vom Aufwand her einfacher, das komplette Musikverzeichniss neu zu parsen. Das hat leider (vorallem auf der langsamen Hardware) sehr lange gedauert.