Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Sonntag, 29. März 2009, 11:34

Erfahrungsbericht SlugOS 5.3

Moin!

Vor zwei Wochen endete mein erster Versuch mit SlugOS 5.3 damit, dass ich wieder 4.8 geflasht habe - Samba wollte gar nicht, NFS war extrem lahm. Ich habe damals auch bei der amerikanischen Mailinglist angefragtund seither dort mitgelesen. Gestern hatte ich dann alle Infos, die ich brauchte und habe daher einen neuen Versuch gestartet - diesmal erfolgreich. Hier mein Rezept:

1. Zunächst streng nach Rezept vorgehen:
http://www.nslu2-linux.org/wiki/SlugOS/I…sicSlugOSSystem

2. Für Deutsch und andere Sprachen mit Umlauten und anderen Sonderzeichen empfiehlt sich die Einrichtung der locales:
http://www.nslu2-linux.org/wiki/HowTo/Us…ctersOnOpenSlug
Dabei sollte unter "Building locale" Note 2 beachtet werden.

3. Wichtig ist, das man sich mit dem Mountverhalten von SlugOS 5.3 beschäftigt und ggf. das System anpasst. Standardmäßig versucht SlugOS 5.3, alle angestöpselten USB-Laufwerke automatisch zu mounten, wobei die "sync"-Option verwendet wird. Das ist sicher, aber lahm. Bei Verwendung von NFS stellt sich gerade das als Performance-Killer heraus. Abhilfe schafft es, wenn man für die Laufwerke einen Blacklist-Eintrag anlegt und sie dann mit den gewünschten Optionen in fstab mountet:
http://tech.groups.yahoo.com/group/nslu2-linux/message/23477

4. Das Samba-Paket von SlugOS 5.3 ist Samba 3.2.8. Leider ist gerade für Umgebungen mit unterschiedlichen Windows-Vaianten die Samba 3.2-Reihe ziemlich nervig. Für den Hausgebrauch geht's auch anders - das Paket samba-essential beinhaltet ein vorkonfiguriertes Samba 3.0.34, das für den Gebrauch im heimischen LAN völlig ausreicht (s. hier). Bisher genutzte smb.conf-Dateien können im Prinzip weiter genutzt werden (ggf. müssen die Pfade zu den Freigaben angepasst werden). Ein Stolperstrick ist allenfalls, dass das Startskript /etc/init.d/samba überprüft, ob in /etc/samba/private/smbpasswd Einträge vorhanden sind. Wenn man nun seine User anlegt, aber tdbsam als Backend verwendet, bleibt /etc/samba/private/smbpasswd natürlich leer und das Startskript verzweigt zur Default-Konfiguration. Man muss also entweder das Startskript ändern oder smbpasswd statt tdbsam verwenden.

Der Lohn der Mühe: Ein schlankes und flottes System auf der Slug! Die Performance von Samba und NFS liegt leicht über den Werten, die ich zuvor mit SlugOS 4.8 hatte, Streaming von VOB-Dateien per VLC an meine Settop-Box läuft wesentlich flüssiger als zuvor. Jetzt kommt noch die Feinarbeit und dann das eher Experimentelle ;)

Eine Beobachtung am Rande: Da ich ab und anmal etwas für die Slug kompilieren muss, aber keinen Crosscompiler aufsetzen will, brauche ich die entsprechenden Tools auf der Slug. Bislang gibt es jedoch kein Paket "slugos-native" für 5.3. Wenn man allerdings die Pakete aus dieser Liste installieren möchte, geht das per opkg problemlos. Ich weiß nicht, ob man damit ganze Pakete bauen kann, aber für's schnelle Kompilieren hat man damit wohl alles da.

Gruß,

Thomas

Anzeigen

2

Montag, 30. März 2009, 12:14

AW: Erfahrungsbericht SlugOS 5.3

2. Teil...

Um LastFM-Proxy zum Laufen zu kriegen, benötigte ich Python. Allerdings vermisste LastFM-Proxy beim Python aus dem opkg-Feed das Modul base64. Mit Python aus dem ipkg-Feed war das Problem dann aber behoben.
Da nun das Internet-Radio lief, machte ich mich ohne große Erwartungen an die Inbetriebnahme meiner USB-Lautsprecher. Früher (iirc unter Unslung) habe ich nur Soundfetzen, gepaart mit fiesen Geräuschen aus den Speakern bekommen. Insbesondere die Tatsache, dass ich die Speaker nicht direkt an der Slug, sondern am USB-Hub betreiben wollte, stimmte mich skeptisch. Doch durch folgende Vorgehensweise hat's geklappt:


Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
opkg kernel-module-snd-usb-audio kernel-module-snd-mixer-oss kernel-module-snd-pcm-oss

mknod /dev/dsp c 14 3
mknod /dev/mixer c 14 0

insmod /lib/modules/2.6.27.8/kernel/sound/soundcore.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd-timer.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd-page-alloc.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd-pcm.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd-rawmidi.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/snd-hwdep.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/oss/snd-mixer-oss.ko
insmod /lib/modules/2.6.27.8/kernel/sound/core/oss/snd-pcm-oss.ko
insmod /lib/modules/2.6.27.8/kernel/sound/usb/snd-usb-lib.ko
insmod /lib/modules/2.6.27.8/kernel/sound/usb/snd-usb-audio.ko

depmod -a
Ein Wermutstropfen ist allerdings, dass die Devices nach einem Neustart weg sind (die Module werden dagegen geladen). Das lässt sich aber mit einem kleinen Skript beheben, so dass man sich nicht die Parameter merken muss.
aplay und madplay liefern nach der Installation jeweils das gewünschte Ergebnis (Musik aus den Speakern). Um nun LastFM zu hören, muss man madplay überlisten, da es Netzwerksstreams nicht von Haus aus akzeptiert:

Quellcode

1
wget -q -O - http://192.168.1.5:1881/lastfm.mp3 | madplay - &
Streamripper läuft auch, so dass man LastFM auch als Quelle für MP3s nutzen kann. Dem gleichzeitigen Hören und Mitschneiden steht nichts im Wege, wenn man Streamripper als Relay verwendet:

Quellcode

1
 streamripper http://192.168.1.5:1881/lastfm.mp3 --quiet -d /mount/sdb2/Musik/mp3/LastFM -r 8888 &
-r sorgt für die Weiterleitung; 8888 ist der Port, an dem der Stream abgegriffen werden kann.
Ich habe auch kurz über MPD nachgedacht, aber da tritt leider ein Fehler auf:

Quellcode

1
mpd: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: Error 116
libglib-2.0.so.0 ist durchaus installiert, so ganz schlau werde ich daraus nicht. Kollege Google konnte auch nicht so recht helfen, ist aber für mich vorerst auch nicht so wichtig. Bis auf weiteres reicht mir zur Steuerung das WebIF von LastFM-Proxy aus, solange ich nicht auf andere Quellen zugreife. (Obwohl ein Lautstärkeregler nicht schlecht wäre...)

Ich bin von SlugOS 5.3 zunehmend angetan - es klappt einfach fast alles :D. Ein paar mehr oder weniger abwegige Kleinigkeiten stehen noch an (z.B. TFTP-Bootserver und Verwaltung der USB-Steckdose), aber ich bin erstmals a dem Punkt, wo mit die realistischen Ideen für die Slug ausgehen. Ich muss wohl doch noch einen VDR aufsetzen ;)

Gruß,

Thomas

Anzeigen

3

Dienstag, 31. März 2009, 12:50

AW: Erfahrungsbericht SlugOS 5.3

3. Teil...
Das oben geschilderte Problem mit mpd habe ich in den Griff bekommen. Zum einen hatte ich Fehler im Dateisystem, zum anderen lag die Library unter /opt/lib, was ich noch nicht in den Pfad aufgenommen hatte. Jetzt muss ich noch die mpd-Audio-Konfiguration begreifen... [EDIT] Erledigt... ;)[/EDIT]
In diesem Zusammenhang: Ich habe den Eindruck, dass die in /etc/profile definierte Variable $PATH noch nicht mit ihrem vollen Inhalt zur Verfügung steht, wenn die Skripte in /etc/init.d beim Booten ausgeführt werden. Daher müssen ggf. absolute Pfade verwendet werden.

Eine Frage an eventuell mitlesende Linux-Gurus:
Ich muss nach jedem Neustart die Devices /dev/dsp und /dev/mixer für USB-Sound neu erzeugen. Ich habe mich soweit durchgegooglet, dass ich auf /etc/udev/rules.d gestoßen bin. Allerdings habe ich keinen blassen Schimmer, wie ich dort in einer der Dateien local.rules, permissions.rules oder udev.rules einen entsprechenden Eintrag vornehme (falls das überhaupt der richtige Ort ist). Für die Zwischenzeit habe ich mir ein madplay-Startskript gestrickt, das bei Bedarf die Devices anlegt, aber besser wär es umgekehrt: Ich stöpsle die Speaker an den Hub und die Slug führt automatisch Aktionen durch (wobei ich gleichermaßen an das Erzeugen der Devices bzw. die eventuell nötigen insmod-Befehle denke als auch an automatischen Start der Internetradio-Wiedergabe). Hinweise sind willkommen.

Gruß,

Thomas

Social Bookmarks