mpd stottert, wenn es unter launchd ausgeführt wird

Hintergrund

Als Terminal-Junkie habe ich angefangen, mit einer Kombination aus mpd (Music Player Daemon) und einem Player, ncmpcpp (NCurses Media Player Client C++), herumzuspielen .

Ich habe diese über Homebrew installiert - eine einfache brew install mpd ncmpcpp. Ein bisschen Konfiguration später, und die Apps laufen ganz gut. Der Effekt ist eigentlich ziemlich beeindruckend:ncmpcpp spielt einige zufällige Dinge

Das Problem, auf das ich stoße, ist, wenn ich automatisch laufen möchte, mpdanstatt es in meinem Terminal starten zu lassen. Es wird mit einer launchdPlist geliefert, also installiere ich diese und es scheint zu funktionieren - Das Problem ist, dass alles, was ich spiele, sei es MP3, Streaming-Audio von einem Server oder was auch immer, das Audio alle 5 Sekunden stottert

Dies passiert absolut nicht, wenn mpdes direkt von der Befehlszeile aus aufgerufen wird, sondern nur, wenn es über launchd ausgelöst wird.

So sieht die Plist aus:

<!--homebrew.mxcl.mpd.plist-->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>homebrew.mxcl.mpd</string>
    <key>ProcessType</key>
    <string>Interactive</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/opt/mpd/bin/mpd</string>
        <string>--no-daemon</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>WorkingDirectory</key>
    <string>/usr/local</string>
</dict>

Das ProcessType interactivewurde von mir hinzugefügt, um launchd zu zwingen, dem Daemon eine höhere Priorität zu geben, ohne Wirkung.

Debuggen?

Wenn wir dtrussden Vorgang ausführen, gibt es eine riesige Explosion identischer gettimeofdayNachrichten, die mit jedem Stottern korrelieren. Es sieht aus wie das:

gettimeofday(0x10A03FD40, 0x0, 0x1000)       = 1428698761 0

Dinge, die ich bereits eliminiert habe

  • CPU / Festplatten-IO

Das System ist relativ leise - während der Stotterer ist mpd nicht einmal unter den Top 25 für Speicher- oder CPU-Auslastung, und die Auslastung liegt deutlich unter 1,0

  • Falsche Umgebung, die dazu führt, dass fehlerhafte Konfigurationseinstellungen geladen werden

Meine mpd-Konfiguration ist diejenige, von der geladen wird ~/.mpdconf- genauso wie wenn ich sie von Hand ausführe.

Dies scheint ein Symptom dafür zu sein, wie launchd den Prozess handhabt.

Die ultimative Frage

Warum verhält sich der Daemon so schlecht, wenn er unter launchd ausgeführt wird, aber nicht, wenn er über das Terminal ausgeführt wird?

Bonus-Frage:

Was an der Art und Weise, wie launchd Prozesse startet, könnte dieses Verhalten manifestieren?

Antworten (1)

Ich hatte ein ähnliches Problem und Google führte mich zu diesem Thread. Jetzt habe ich eine Lösung für das Problem, wenn jemand anderes dies findet.

Entfernen Sie einfach die --no-daemonLinie.

Das scheint gut zu funktionieren:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>homebrew.mxcl.mpd</string>
    <key>WorkingDirectory</key>
    <string>/usr/local</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/opt/mpd/bin/mpd</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>
Ich musste zusätzlich noch etwas anderes tun, und das war, den FIFO-Ausgang (der für die Visualisierung verwendet wird) auszuschalten. Es gibt einen offenen Fehler, der auf MPD gemeldet wurde, dass das „osx“-Ausgabe-Plugin dieses Problem hat, nicht gewartet wird und wahrscheinlich nicht behoben wird
bugs.musicpd.org/view.php?id=4316 ist der erwähnte Bug im MPD Bugtracker.
Das Ausführen mpdund mpd --no-daemonvon der Befehlszeile aus funktioniert einwandfrei. Beide Optionen führen zu Stottern, wenn sie über ausgeführt werden launchd( brew serviceseigentlich).