[gelöscht]
Hallo,
ich bin grade dabei ein "Küchenradio" zu bauen, das möglichst unkompliziert funktionieren soll. Basis ist ein 5,25"-Board mit einem K6-2 ("lowarch" sei dank) und mit einer USB-Karte im einzigen PCI-Slot. --> Sound und Wlan werden über USB benutzt. Gebootet wird von einer CFCard (mit IDE-Adapter).
Was bis jetzt geht: Sound, mpg321 und mp3blaster spielen wie sie sollen Musik.
Usbsticks einbinden kann ich auch, allerdings passiert das noch nicht automatisch (aber das kriege ich wohl noch selbst hin).
Was ich will: einfach einen Speicherstick einstecken und dann soll entweder eine evtl vorhandene Playlist (die auch auf dem Medium liegt) oder einfach alle Dateien wiedergegeben werden.
-->Mein Ansatz: wenn man den Stick einsteckt muss der gemountet werden, dann muss automatisch ein Script/Programm/sonstwas starten, das nach Playlists sucht und dann zb den mp3blaster mit der Playlist als Option startet.
Kann mir jemand kurz und knapp sagen wie das geht (gehen könnte) bzw wenn das kurz und knapp nicht geht Literatur empfehlen?
GerBra
MadCyborg schrieb
-->Mein Ansatz: wenn man den Stick einsteckt muss der gemountet werden, dann muss automatisch ein Script/Programm/sonstwas starten, das nach Playlists sucht und dann zb den mp3blaster mit der Playlist als Option startet.
Ich würde das über udev machen. Udev kennt die Option RUN, kann also ein Programm
ausführen nach dem Registrieren und Anlegen des Devices.
Als Ansatz mal:
http://wiki.archlinux.org/index.php/Using_udev_to_map_multiple_entries_to_a_device
Ich würde so vorgehen:
Erstmal eine udev-Regel erstellen, die für alle USB-Sticks einen einheitlichen Namen
vergibt, z.B. /dev/mystick.
Dann diese Regel um die RUN Option erweitern, damit ein Skript gestartet wird was:
a) Das /dev/mystick mountet
b) nach einer Playlist schaut, ggf. diese abspielt
c) Wenn keine Playlist, dann alle mp3,ogg,... Files abspielen
d) Wenn fertig den Stick umountet
Schau mal, wie weit du kommst. Bei Problemen gerne weiter fragen.
[gelöscht]
Danke, das hat schonmal weitergeholfen. Ich habe mir das jetzt soweit zurechtgebastelt, das mein Stick gemountet wird. Jedoch klappt irgendwas mit dem Aufruf vom mp3blaster nicht. Ich denke es handelt sich um einen typischen Fehler: der Aufruf vom mp3blaster funktioniert nur wenn ich das Script von Hand starte. Woran könnte das liegen?
Mein Script (mein erstes überhaup übrigens):
#!/bin/sh
mount /mnt/usbdrive
mp3blaster --autolist /mnt/usbdrive/testlist.lst
Wie man sieht benutze ich im Moment noch eine fest eingestellte Liste, darum kümmere ich mich später.
edit: ich habe grade festgestellt das der Aufruf meines Scripts ansich nicht hinhaut...
edit2: korrigiert, aber das ist nicht das Problem.
Hier:
http://reactivated.net/writing_udev_rules.html#external-run
steht, das "run" die Befehle nicht in einer Shell ausführt und man keine Ausgaben erhält. Außerdem ist udev während der Ausführung "paused" was ja zumindest unschön ist.
GerBra
Diese Einleitungszeile beim Skript muß so aussehen:
#!/bin/sh
Dann kommt es jalt drauf an, wer das Skript aufruft.
In dieser Form bei mount muß es einen Eintrag in der /etc/fstab geben.
[gelöscht]
Die Zeile habe ich mittlerweile korrigiert, und einen Eintrag in fstab habe ich auch. Das automatische Mounten funktioniert auch immer (also auch wenn das Script mit run aufgerufen wird). Nur der mp3blaster taucht nicht auf, wenn das Script per run aufgerufen wird...
GerBra
Ich vermute, daß die Umgebung des Skriptes keine PATH mitkriegt, mp3blaster
also garnicht findet.
Rufe mp3blaster mal mit explizitem Pfad auf, müßte /usr/bin/mp3blaster sein.
which mp3blaster kann dir das genau sagen.
Gegen das "Blockieren" von udev (???) könntest du (wenn alles funktioniert) den
Player im Hintergrund starten, dann könnte sich das Skript schnellstmöglich wieder
beenden.
Damit du evtl. doch siehst, wo was passiert würde ich das so versuchen:
#!/bin/sh
mount /mnt/usbdrive
sleep 3
touch /tmp/player
echo "Starte Blaster" >> /tmp/player
/usr/bin/mp3blaster --autolist /mnt/usbdrive/testlist.lst
# Nachfolgend wäre der Start im Hintergrund
# /usr/bin/mp3blaster --autolist /mnt/usbdrive/testlist.lst &
echo "Verlasse Skript" >> /tmp/player
Dann mal in /tmp/player schauen, ob und was da drin steht.
[gelöscht]
Leider wieder Fehlanzeige. Mit dem Pfad hatte ich das sowieso schon probiert, weil ich /usr/local/bin anfangs garnicht im PATH hatte. Die Strings die in die Datei "geechot" werden tauchen dort ordnungsgemäß auf, aber sehen tu ich auf mein konsole nichts.
Im Hintergrund starten habe ich spaßenshalber auch mal Probiert, das führt zum selben Ergebnis. Ich werde jetzt mal mpg321 testen, mal gucken was das so sagt...
Gibts sonst eventuell eine andere Möglichkeit die Einsteck- oder Mountvorgang zu registrieren und dann ein Skript auszulösen? Oder vielleicht aus einem Skript heraus ein anderes zu einem gezielten Zeitpunk (10 Sekunden später oä) nach Beendung des laufenden zu starten?
GerBra
"aber sehen tu ich auf mein konsole nichts."
Ach, das ist ein Konsolen-Programm mit Ausgaben usw.?
Das kann dann so nicht funktionieren IMHO, ich dachte das wäre ein reiner
Abspieler (mpg321 könnte da in der Tat funktionieren).
Soll der Player dann auf einer Konsole / X etwas ausgeben /steuerbar sein?
Evtl. kann man den mpd dazu besser gebrauchen (liest jemand mit mit mpd
Erfahrung?). Dann könnte der Daemon den/die Sticks überwachen und ein
mpd-Client das Ding steuern... so in etwa 😉
[gelöscht]
Ja ist es, praktischerweise so simpel gehalten, das man es prima mit einem gehackten Tastaturcontroller steuern könnte. Ausgaben währen eigentlich auch ganz nett, weil USB-Medien sind ja mitunter doch recht groß sind und dann auch ziemlich viele Dateien drauf sind. Da wäre ein Display (welcher Art ist noch nicht entschieden 😉 )für die Orientierung ganz angebracht.
Mpg321 funktioniert übrigens tatsächlich.
mpd...? nie gehört, ich guck mal nach.
GerBra
Zum mpd gibt es auch hier einen Wiki-Beitrag, bin mir aber nach dem Querlesen nicht
so sicher ob das was taugt für dein Vorhaben.
X ist auf dem Rechner nicht vorgesehen?
Bliebe eine tty-Konsole übrig. Die einzige Möglichkeit, ein Programm in einem tty zu
starten die mir einfällt wäre über die /etc/inittab.
Wenn der mp3blaster eine Option hätte, daß man ein schon gestartetes mp3blaster
per Optionen o.ä. steuern könnte, dann wäre das möglich:
mp3blaster läuft z.B. auf tty/vt12
Neuer Stick eingemountet schickt entweder eine vorhandene Playlist oder
die Liste der Stücke an der laufenden mp3blaster.
Ich werde mir den Player auch mal anschauen.
GerBra
So, kurzer Nachtrag:
Den mp3blaster kann man AFAIK nicht "fernsteuern" (außer evtl. beim Start eine
feste Playlist vorzugeben und diese dann von udev aktualisieren zu lassen?)
Der mpd scheint doch eher was zu taugen. Hintergrund vom mpd ist ja eine "Datenbank".
Diese kann man mit "mpc update" evtl. vom udev-Skript nach dem Mounten
neu einlesen lassen.
- Daemon läuft im Hintergrund
- udev erstellt/aktualisert beim Einstecken die Datenbank
- ein mpd-Client-programm läuft z.B. auf tty12 zum Interagieren.
[gelöscht]
So, ich habe mal versucht den mp3blaster vorher zu starten und ihm dann später die playlist nachzureichen. Geht nicht.
X soll es definitiv nicht geben, erstens weil die CF-Karte nur 1GB hat und zweitens will ich keinen Bildschirm benutzen, außer mir fällt ein günstiges <10" TFT in die Hände. Was aber sinnvoll wäre, wäre LCD-Display, da habe ich einerseits noch Zeichenbasierte rumfligen, anderseits kosten Glcds auch nicht mehr die Welt. Und da mpd anscheinend wesentlich mächtiger ist, und es da bestimmt was für mich gibt, bin ich grade dabei diesen zu installieren.
offtopic: wovon hängt eigentlich die Ausführungsgeschwindigkeit von ./configure und make ab? Lesegeschwindigkeit und Prozessorleistung wahrscheinlich, sonst nochwas? Das läuft hier nämlich alles schleppend lahm ab...
[gelöscht]
Es geht!
Danke für deine Beiträge.
MPD ist scheinbar ideal. Ich benutzte jetzt ncmpc als Benuterschnittstelle und mpc aus dem Script heraus. Funktioniert genau wie es soll.
Jetzt muss ich nur noch die udev-Regel so umbauen, das jedes Speichergerät als solchen erkannt wird. Hast du da evtl noch eine Idee parat? Produkt/Bezeichnung/Key der Medien sind ja irgendwie immer unterschiedlich. Aber das es sich um ein Speichergerät handelt muss udev ja auch erkennen (können).
edit: im udev-rule einfach DRIVERS=="usb-storage" benutzen, funktioniert zumindest mit meinem Stick.
GerBra
Mit den Sticks mußt du wirklich ausprobieren und rumtesten, v.a. weil manche ja
ganz ohne Partition daherkommen (sda), andere dann wieder auf sda1 usw. passen.
Wenn du nur wenige Sticks hast (und die alle "kennst") dann wäre eine Option,
nach dem Attribut serial zu regeln. Und für jeden Stick dann eine eigene Regel.
Ich selbst tue mich mit udev auch teils schwer, kann dir aber zwei Links anbieten:
http://reactivated.net/writing_udev_rules.html
Und aus dem engl. Wiki ein Beispiel aus dem Beitrag zu verschlüsselten HD's:
http://wiki.archlinux.org/index.php/LUKS_Encrypted_Root#Store_the_key_externally_.28USB_stick.29
Das könnte dir ggf. weiterhelfen.
Wenn's denn läuft 😉 :
Hat das jetzt nicht mehr Spaß gemacht als packet_xyz zu installieren? War sicher auch
lehrreicher und ist v.a. nach deinem Gusto ausbaufähig.
Wenn du noch gerade "frisch dabei" bist: wäre das Vorgehen und Aufbau nicht was für
einen kleinen Wiki-Beitrag?
[gelöscht]
MadCyborg schrieb
Jetzt muss ich nur noch die udev-Regel so umbauen, das jedes Speichergerät als solchen erkannt wird. Hast du da evtl noch eine Idee parat? Produkt/Bezeichnung/Key der Medien sind ja irgendwie immer unterschiedlich. Aber das es sich um ein Speichergerät handelt muss udev ja auch erkennen (können).
Du brauchst noch
hal. Das weiß mehr über die Geräte als udev.
Ich habe aber auch keine weitere Erfahrung damit. Dieser LinuxMagazin-Artikel hilft dir vielleicht weiter:
http://www.linux-magazin.de/heft_abo/ausgaben/2006/09/backup_ueber_bande
In der Ausgabe gibt es noch mehr Artikel über hotplug, udev, hal & Co.
[gelöscht]
Auf die drei Artikel bin ich bei meiner Recherche schon gestoßen, die sind durchaus hilfreich. Überhaupt ist das ganze Thema ja sehr interessant.
Ich denke ich bleibe vorerst dabei nach usb-storage zu suchen, denn letztendlich will ich ja immer das selbe tun (in den Artikeln werden andere Möglichkeiten erwähnt, wie starten eine Bildbetrachters beim anstecken einer Kamera, das ist schön, aber ich baue ja ein "Radio" 😉 ).
Es sind jetzt allerdings 2 Probleme aufgetaucht:
1.: wie kannst ich regeln, das ein USB-Stick nach dem abstecken wieder unmounted wird? Wenn ich meinen Stick mehrmals an- und abstecke bekommt er jedes mal den folgenden Buchstaben nach "sd", also beim dritten mal sdc und beim vierten mal "sdd" und so weiter. Das ist schonmal unschön, und was passiert wohl wenn die Buchstaben ausgehen?
2.: Wenn ich ein Gerät mit mehreren Laufwerken anstecke (MP3-Player mit Kartenslot zb), dann passiert meine Prozedur erst mit dem internen Speicher, und dann mit der (evtl nicht eingesteckten) Karte, d.h. es wird ein lerer Speicher gemounted und die Datenbank aktualisiert, wodurch sie natürlich leer ist.
-->ich muss noch regeln, das mindestens 4 Geräte gleichzeitig benutzt werden können.
Wenn das läuft, könnte man über einen Wikibeitrag nachdenken (Input erwünscht).
ps: ich gehe jetzt erstmal im Schnee spielen, bevor der wieder weg ist...
GerBra
Zu 1:
Bei den udev-Regeln gibt es ACTION=="remove", da könntest du das umounten
veranlassen. Ich würde beim mounten evtl. schon sicherstellen daß das Device nur
read-only gemountet wird. Beim umount mußt du ggf. mit -f oder -l arbeiten.
Oder zum Einbinden statt mount das Paket pmount nehmen. Das ist speziell auf
entfernbare Medien zugeschnitten.
Zu den unterscheidlichen Device-Namen: wie ich schon sagte, den Devices mit SYMLINK
feste Namen zuweisen. Dann sind die Skripts nicht mehr auf Rätselraten(sdb,sdc)
angeweisen. Wie und ob das allerdings bei mehreren Sticks funktioniert kann ich
momentan nicht sagen.
Nochmal die Frage: Sind es immer die selben USB-Massenspeicher oder mußt du auch
"Fremdsticks" behandeln?
Zu 2:
Du könntest nach dem Mounten überprüfen, ob das Mount-Dir leer oder keine Lieder
daruf sind. Wenn das zutrifft halt wieder entmounten. Das alles bevor dem mpd seine
Datenbank aktualisiert wird.
[gelöscht]
So, hier mal ein Update:
1. Nach einem harten Kampf lässt sich mpd jetzt endlich beim booten starten, irgendwie ist meine installation wohl unvollständig (wie auch immer), jedenfalls hat neben der mpd.conf (auch der Beispieldatei) auch das Startupscript in /etc/rc.d/ gefehlt...hat mich gut Zeit gekostet...
2. Ich gehe immernoch nach der udev-regel DRIVERS==usb-storage vor, ich habe derweilen mehrere Geräte getestet (Kartenleser, 2 verschiedene MP3-Player, Stick), das funktioniert soweit ganz gut. Ums mal explizit auf den Punkt zu bringen: ich will jedes (--> Fremdsticks 😉 ) und nicht nur mir bekannte Geräte nutzen können.
3. Die Geräte bekommen jetzt einen symlink der ihren (Kernel-) Namen enthält, und mit dem Kernelnamen als Option wird dann mein Mountscript aufgerufen, was seinerseits die Option benutzt um entsprechende Verzeichnisse in /mnt/ anzulegen und die Laufwerke zu mounten (jetzt ohne fstab-Eintrag). Außerdem wird das gemountete Verzeichnis mit mount --bind nach "/etc/mpddb/" in einen seinem Namen ensprechenden Unterordner eingebunden. "/etc/mpddb" ist dann das Verzeichnis was ich in der mpd.conf als music_directory angegeben habe.
4. Der Ablauf ist kurz gesagt:
-Medium einstecken
-udev setzt symlink und ruft mountscript auf
-mountscript erstellt Verzeichnisse und mountet
-mountscript mach --bind und ruft mein mpd-script auf (ich habe die mpd-spezifischen sachen wegen der Übersichtlichkeit aus dem mountscript genommen)
-mpd-script mach db-update und startet die Wiedergabe
5. Das ganze funktioniert ohne login komplett im Hintergrund.
Das ist schon ganz schön, aber was ich jetzt noch bräuchte, wäre ein automatische login-Vorgang und dann müsste ncmpc gestartet werden (letzteres sollte ja das kleinere Problem sein).
In Sachen Autologin hatte ich mich schonmal kurz belesen und bin auf mingetty und andere *gettys gestoßen...is das was?
Ich werde natürlich selbst weiterrecherchieren...
GerBra
Sieht doch schon gut aus 😉
Dieses ncmpc ist das Cleint-Programm zum Interagieren mit dem mpd-Damon?
Du könntest es z.B. auf Terminal 12 über die /etc/inittab starten lassen.
Dann entfiele auch der Mechanismus des (Auto)-Einloggen-Müssens.
Das beste getty dafür wäre rungetty (huch, gibt es nicht als Paket oder im AUR, ich
schaue morgen mal).
Testen kannst du schon mal mit (inittab):
12:2345:respawn:/usr/bin/ncmpc
(Bin mir über die Syntax grad nicht so im Klaren, und auch nicht ob das Tastatureingaben
richtig annimmt.)
Eine Alternative ist openvt, z.B. nach /etc/rc.local
openvt -s -- /usr/bin/ncmpc
oder
openvt -s -- sudo -u username /usr/bin/ncmpc
(sudo natürlich einrichten, damit ncmpc nicht als root gestartet wird)
Momentan habe ich keine Lust da rumzuprobieren, deswegen alles ohne Gewähr 😉
Das rungetty kann ich dir Morgen zeigen wie du es kriegst.
[gelöscht]
Kurz (weil ich gleich weg muss): der Eintrag in inititab funktioniert so (nur das mein Pfad leicht anders ist, aber das tut ja nicht wirklich zur Sache).
Und: ja, ncmpc ist mein Client.