Heute ist mal wieder einer dieser Tage, an denen man sich an den Kopf fassen und laut “Wie doof bin ich eigentlich!” schreien könnte. Die Geschichte hierzu wie gefolgt:
Wie Schakko in Rautiges 2009-07-14 berichtete sitze ich derzeit an der Konfiguration eines Mediastreams für unser Netz. Hierzu kommen MPD (Music Player Daemon) und Icecast2 zum Einsatz. Die Konfiguration der Beiden ging recht flott, die ersten Töne waren schnell entlockt. Zusätzlich noch RelaxxPlayer als grafisches Web-Frontend, welches Drag&Drop aus der Library, Kontextmenüs und noch einiges mehr unterstützt.
Doch leider kommt es bei bestimmten Playern (insbesondere dem VLC) bei Titelwechseln dazu, dass kein Sound mehr empfangen wird. Der Player behält dabei die Verbindung aufrecht, die Zeit läuft auf dem Client aber nicht weiter. Ein Blick in die Admin-Page vom Icecast2 zeigt ähnliches Verhalten, der Client bleibt verbunden, Zeit seit des Verbindens wird ebenfalls gezählt. Scheinen aber nicht die Einzigen zu sein, die dieses Problem haben. Laut diversen Foreneinträgen könnte es mit dem Wechsel der OGG-Header zu tun haben. Demnächst werde ich dann mal einen Test machen, ob es mit einer echten OGGs (bisher waren es MP3s) besser klappt.
Zudem wollten wir uns unseren StreamSRV so aufsetzen, dass sobald neue Musikstücke in den Musikordner kopiert werden, die MPD-DB geupdatet wird. Selbiges Spiel natürlich beim Verschieben und Löschen von Liedern. Da die Platte im StreamSRV jedoch recht begrenzt ist, mussten wir dieses Verzeichnis auslagern. Zunächst hatte ich es mit einer normalen Netzwerkfreigabe probiert. Zum Überwachen des Verzeichnisses fiel mir durch Tipp von Schakko inotify auf. Doch damit lassen sich ja nur lokale Verzeichnisse überwachen. Blöd, irgendwie muss es doch noch einen Umweg geben.
Unser nächster Einfall war, ein iSCSI-Target einzurichten und dieses für die Ablage zu benutzen. Das Target war schnell erstellt und eingerichtet. Nächstes Ziel war es nun, das Laufwerk beim Neustart automatisch wieder in das vorgegebene Musik-Verzeichnis zu mounten. Da dies leider trotz fstab-Eintrag
[sourcecode language="bash"]
/dev/sdb1 /var/lib/mpd/music/ ext3 defaults,auto,_netdev 0 0
[/sourcecode]
nicht automatisch geschah (vermutlich, weil zum Zeitpunkt des Mounts die Netzwerkverbindung noch nicht bestand), überlegte ich mir, wie ich dies nun realisieren könnte. Nach meinen gesammelten Erfahrungen mit EFA fiel mir dazu ein, dass es sich am einfachsten über eine udev-Regel realisieren ließe. Diese war auch schnell getippert:
[sourcecode language="bash"]
KERNEL==”sdb1″,SYMLINK+=”mmedia”,RUN+=”/var/lib/mpd/mnt.sh”
[/sourcecode]
Das zugehörige Mount-Script:
[sourcecode language="bash"]
echo “[$(date +%d.%m.%Y-%H:%M:%S)] versuche sdb1 auf /var/lib/mpd/music/ zu mounten” >> /var/log/test.log
mount /dev/sdb1
echo “[$(date +%d.%m.%Y-%H:%M:%S)] mounte sdb1 auf /var/lib/mpd/music/” >> /var/log/test.log
[/sourcecode]
Leider funktionierte dies nicht. Der Symlink wurde korrekt erzeugt, das Mount-Script wollte jedoch einfach nicht ausgeführt werden. Weder wurde ein Eintrag in die test.log getätigt, noch zeigte mir
[sourcecode language="bash"]
mount -l
[/sourcecode]
unser neues Laufwerk als gemountet an. Immer wieder erhielt ich laut Log den Fehler
[sourcecode language="bash"]
udevd-event[xxxx]: exec of program ‘/var/lib/mpd/mnt.sh’ failed
udevd-event[xxxx]: ‘/var/lib/mpd/mnt.sh’ returned with status 1
[/sourcecode]
Zunächst fiel mir nichts besonderes auf, Test mit einem USB-Stick verlief auch negativ. Rief ich das Mount-Script per Hand auf, verlief alles einwandfrei. Woher kam nun also der Fehler? Berechtigungen waren richtig gesetzt, ausführbar war das Script auch. Nach einiger Zeit knallte mir dann der Kopf auf den Tisch: Sollte ich etwa ein einfaches
[sourcecode language="bash"]
#!/bin/bash
[/sourcecode]
am Anfang des Mount-Scripts vergessen haben? Dem war so, und jetzt läuft es auch einwandfrei. Manchmal kann die Lösung so einfach sein
Kategorie:
Tags: keine
