I've set up mpd per the second configuration option on the wiki. In other words:
$ ls -l ~/.mpd -rw-r--r-- 1 jwhendy users 13933 Feb 13 09:20 config -rw-r--r-- 1 jwhendy users 0 Jul 1 2010 db -rw-r--r-- 1 jwhendy users 305914 Feb 13 08:50 mpd.db -rw-r--r-- 1 jwhendy users 0 Jul 1 2010 mpd.error -rw-r--r-- 1 jwhendy users 0 Jul 1 2010 mpd.log -rw-r--r-- 1 jwhendy users 0 Jul 1 2010 mpd.pid -rw-r--r-- 1 jwhendy users 192 Feb 13 09:20 mpdstate drwxr-xr-x 2 jwhendy users 4096 Jul 1 2010 playlists
$ cat ~/.mpd/config music_directory "/path/to music" playlist_directory "/home/jwhendy/.mpd/playlists" db_file "/home/jwhendy/.mpd/mpd.db" state_file "/home/jwhendy/.mpd/mpdstate" log_file "/home/jwhendy/.mpd/mpd.log" pid_file "/home/jwhendy/.mpd/mpd.pid" bind_to_address "127.0.0.1" ### the rest is commented out ###
Starting mpd works:
$ mpd .mpd/configoutput: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a alsa audio device output: Successfully detected a alsa audio device
$ ps ax |grep mpd 4067 ? Ssl 0:00 mpd .mpd/config $ sudo netstate -nlp |grep mpd tcp 0 0 127.0.0.1:6600 0.0.0.0:* LISTEN 4067/mpd
mpd.log shows nothing odd as far as I can tell. It complains about mpdstate not existing (but afterward it exists and the error does not show up again) and then there are (I guess what I would expect) a ton of "Feb 13 timestamp: update: added /path/to/all-my-various-music" messages. It seems like mpd is doing just fine.
ncmpcpp config (extremely basic, just trying to get running):
$ cat ~/.ncmpcpp/config ##### connection settings ##### #mpd_host = "localhost" #mpd_port = "6600" mpd_music_dir = "/path/to/Music" mpd_connection_timeout = "5" mpd_crossfade_time = "5"
the grand finale:
$ ncmpcpp Cannot connect to mpd: Connection closed by the server
What am I doing wrong? I'm 80% expecting that it's something unbelievably stupid, but that doesn't mean I know what it is. This is my first time setting up mpd and a client. I'm clueless but want to see what the rage is around here about ncmpcpp. I currently use cmus.
Lastly, the wiki presents two methods; which is recommended (root + rc.conf or normal user with everything in ~)?
Thanks for your help.
Last edited by jwhendy (2011-02-14 01:55:11)
Maybe its related to https://bbs.archlinux.org/viewtopic.php?id=109962
If not, run "mpd --verbose" and post the output, if you are unsure what to do next.
Thanks for the suggestions. From following the thread, it looks like the following were proposed:
1) compile without tcp_wrapper support (due to the error "libwrap refused connection")
2) add mpd to /etc/hosts.allow
3) removing the mpd.error setting from mpd config
The output form my recent starts of mpd using 'mpd --verbose .mpd/config' are like so:
Feb 13 13:39 : state_file: Loading state file /home/jwhendy/.mpd/mpdstate Feb 13 13:40 : state_file: Saving state file /home/jwhendy/.mpd/mpdstate Feb 13 13:40 : listen: listen_global_finish called Feb 13 13:40 : db_finish took 0.000000 seconds Feb 13 13:42 : state_file: Loading state file /home/jwhendy/.mpd/mpdstate
I see no libwrap issue, so I'm tempted to rule out #1.
In the thread, the consensus was that you don't need to add mpd to /etc/hosts.allow if you're using 127.0.0.1, which is what I'm doing. So I'm also tempted to rule out #2.
I don't have the mpd.error line in my config, so I'm tempted to rule out #3.
Did I miss any? I don't see anything odd from the log, assuming I called mpd --verbose correctly. Can you suggest a way to obtain better output? Can I enable something verbose in ncmpcpp?
to /etc/hosts.allow and then rebooting works.
Would someone please explain why this is necessary if I'm operating on localhost? Should this be in the wiki? The other thread suggests that this is not necessary if I'm only operating locally. Thanks.
@jasonwryan: To be clear, you are talking about:
$ cat ~/.ncmpcpp/config mpd_port = "6600"
$ cat ~/.mpd/config port "6600"
Right? If so, doing that and removing the mpd line from /etc/hosts.allow does not work. I get connection refused. Could this at all be related to me running via the "normal user" way vs. the "root - daemon - /etc/rc.conf" way?
Yes - they are the two entries that I have in my respective conf files (I don't have the bind_to_address either) with no mpd entry in hosts.allow, and I use the $HOME approach.
I also use mpd+ncmpcpp as a normal user without a hosts.allow entry. I Played with your config settings, commenting out or in the mentioned options... it always runs flawlessly. So you shouldn't have a config problem.
I noticed that your mpd output doesn't list any daemon lines like:
... database: reading DB daemon: opening pid file daemon: daemonized! daemon: writing pid file ...
Are you sure you have not started the mpd daemon in /etc/rc.d ?
And other possibilites:
Do you have the latest packages from the arch repositories?
Do you have some uncommon firewall settings?
Btw: the other thread was related to https://bugs.archlinux.org/task/22071 , which was already fixed (i know you haven't the errors, but the same symptoms)
Last edited by metzengerstein (2011-02-13 22:46:34)
Asking the obvious, but you've got the following, right?
/etc/hosts 127.0.0.1 <foo> localhost
.ncmpcpp/config mpd_host = "127.0.0.1"
And have you tried another client like mpc to see, if that works?
HHNNNNGG | nyahahahaha *meow*
Thanks for the input, everyone. This is so puzzling! My responses:
- weird that it works flawlessly for you...
- sorry, my posted output above was from ~/.mpd/mpd.log, not startup. Here is the result when starting mpd:
$ mpd --verbose .mpd/config config: loading file .mpd/config path: path_set_fs_charset: fs charset is: UTF-8 database: reading DB output: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a alsa audio device output: Successfully detected a alsa audio device disabling the last.fm playlist plugin because account is not configured daemon: opening pid file daemon: daemonized! daemon: writing pid file
$ pacman -Q |grep mpd mpd-git 20110213-1
- definitely no mpd in /etc/rc.conf
- no firewall
- that thread you linked to was interesting -- isn't it saying that and entry in /etc/hosts.allow is always required now?
- re. /etc/hosts... yup:
$ cat /etc/hosts 127.0.0.1 localhost.localdomain localhost foo ::1 localhost.localdomain localhost foo
- just tried the mpd_host line and that didn't work
- have not tried mpc, but I did try sonata and get an endless string of:
2011-02-13 18:33:05 Connection lost while reading MPD hello 2011-02-13 18:33:05 Not connected 2011-02-13 18:33:05 Not connected
Any other thoughts? Is it just that /etc/hosts.allow needs 'mpd: ALL' now? What version are the rest of you using?
The only difference between my setup (that works) and yours is that I don't have any IPV6 entries in /etc/hosts. I don't have any MPD lines in /etc/hosts.allow
@All: fixed via the suggestion to compile with "--disable libwrap", which I accomplished like so (for any else who stumble on this):
$ yaourt -S mpd-git ,----- | Choose Y to edit PKGBUILD and scroll down to this section: `----- # Configure Source ./autogen.sh \ --prefix=/usr \ --sysconfdir=/etc \ --disable-ao \ --disable-jack \ --enable-bzip2 \ --enable-httpd-output \ --enable-iso9660 \ --enable-lastfm \ --enable-modplug \ --enable-pulse \ --enable-zzip \ --with-zeroconf=no ,----- | so it reads like this: `----- ... --with-zeroconf=no \ --disable-libwrap
Then continue with the build. Worked for me.
My only puzzlement is that unlike the issue where it's discussed HERE), I never had any "Dec 12 13:51 : client: libwrap refused connection (libwrap=mpd) from 127.0.0.1:54755" errors. Libwrap was never mentioned in my errors as far as I could tell.
In any case, it seems the fixes are either
1) add 'mpd: ALL' to /etc/hosts.allow or
2) compile with "--disable-libwrap"
I'll mark as solved but would be happy for anyone else to correct this conclusion for the benefit of others. I'll add references to this post and the other relevant ones to the wiki unless someone beats me to it.
Last edited by jwhendy (2011-02-14 01:54:42)
Update: added summary of the recent posts and bug report to the mpd page on Arch Wiki. See HERE. Edit, correct, and/or update as needed. Just wanted something there to point to the recent developments.
If you look at the PKGBUILD of the current /extra/mpd (v. 0.16.1), you can see it gets build with "--disable-libwrap".
So have you really installed this package?
Also next time you encounter a client problem, you should first try it with mpc.
I already answered that when you asked the first time (HERE). I said::
$ pacman -Q |grep mpd mpd-git 20110213-1
I'm using aur/mpd-git, not extra/mpd 0.16.1-1.
Edit: Perhaps I should note that in the wki adds I made, as this won't be an issue for anyone using the package in [extra].
Last edited by jwhendy (2011-02-14 15:17:32)
Sorry, didn't see that line.
Yes, I think deleting your adds could prevent the confusion with already fixed issues.
Last edited by metzengerstein (2011-02-14 17:45:49)
just for information: the only way to be absolutely sure your mpd binary does not use libwrap is this:
ldd `which mpd`|grep wrap
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.