You are not logged in.
Pages: 1
My MPD just suddenly stopped working. In Cantata, I'm getting this error:
Connection to "Default" (192.168.1.3:6600) failedWhen I run ncmpcpp, it just says "Connected to localhost" but the music listing is empty.
This is part of my mpd.conf
bind_to_address "127.0.0.1"
port "6600"The logs says it has been opened properly:
Apr 15 23:15 : avahi: Service 'Music Player' successfully established.
Apr 15 23:15 : client: [0] opened from 127.0.0.1:53254
Apr 15 23:19 : client: [1] opened from 127.0.0.1:54608What could be the problem? Everything was working fine before.
Last edited by d_fajardo (2018-04-17 16:59:30)
Offline
Are you sure your IP didn't change? Check to make sure that Cantata is trying to connect to your actual IP or localhost.
Offline
It doesn't seem like it but here is the output of ip addr:
[dipswitch@TUF-Z270 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: net0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
link/ether 2c:56:dc:39:e2:20 brd ff:ff:ff:ff:ff:ff
3: net1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP group default qlen 1000
link/ether 2c:56:dc:39:e2:20 brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2c:56:dc:39:e2:20 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.3/24 brd 192.168.1.255 scope global bond0
valid_lft forever preferred_lft forever
inet6 fdb0:8900:7867:b200:2e56:dcff:fe39:e220/64 scope global dynamic mngtmpaddr
valid_lft 6691sec preferred_lft 3091sec
inet6 fe80::2e56:dcff:fe39:e220/64 scope link
valid_lft forever preferred_lft foreverresolv.conf gives this:
# Generated by resolvconf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4And I can ping the addresses.
Offline
mpc --verbose --host localhost statusOffline
mpc seems to be working:
[dipswitch@TUF-Z270 ~]$ mpc --verbose --host localhost status
volume: 91% repeat: off random: off single: off consume: on Offline
I killed and restarted the daemon and now mpc doesn't start neither:
[dipswitch@TUF-Z270 ~]$ mpc --verbose --host localhost status
volume: n/a repeat: off random: off single: off consume: offI can play music elsewhere that uses PulseAudio so this is really an mpd problem.
Offline
mpd --kill
ps aux | grep mpd
mpd --stderr -v
mpc --verbose --host localhost statusPost all output.
Side question: did you maybe run an update? Tried to reboot?
Offline
When I run nmcpcpp, it says "Connected to localhost" but when I run u (update), it does an update with the message "Database update finished" yet the list remains empty.
Cantata however gives me a different output. On startup it says:
Failed to send command to "Default" (192.168.1.3:6600) - not connectedAnd when I try to connect, I get:
Connection to "Default" (192.168.1.3:6600) failedOffline
ps aux | grep mpd:
dipswit+ 9180 0.0 0.0 11180 2292 pts/1 S+ 09:01 0:00 grep mpdmpd --stderr -v:
config_file: loading file /home/dipswitch/.config/mpd/mpd.conf
libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
vorbis: Xiph.Org libVorbis 1.3.6
opus: libopus 1.2.1
sndfile: libsndfile-1.0.28
simple_db: reading DB
curl: version 7.59.0
curl: with OpenSSL/1.1.0h
avahi: Initializing interface
avahi: Client changed to state 2
avahi: Client is RUNNING
avahi: Registering service _mpd._tcp/Music Player
avahi: Service group changed to state 0
avahi: Service group is UNCOMMITED
state_file: Loading state file /home/dipswitch/.config/mpd/state
avahi: Service group changed to state 1
avahi: Service group is REGISTERING
[dipswitch@TUF-Z270 ~]$ client: [0] opened from 127.0.0.1:42260
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "currentsong"
client: [0] command returned 0
avahi: Service group changed to state 2
avahi: Service 'Music Player' successfully established.
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "currentsong"
client: [0] command returned 0
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "currentsong"
client: [0] command returned 0
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "currentsong" This is interesting. This commands outputs to this infinite loop:
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "currentsong"
client: [0] command returned 0I had to kill this by Ctrl D.
Is this normal or could this be the problem?
mpc --verbose --host localhost status
volume: 91% repeat: off random: off single: off consume: onMight the "status" and "currentsong" be the clue? I must add I do use Cantata to stream content from the internet and this might have a bearing on this as well. Some unresolved streams perhaps?
Last edited by d_fajardo (2018-04-16 08:14:50)
Offline
Side question: did you maybe run an update? Tried to reboot?
According to pacman logs, these are the last updates before everything got wiry:
[2018-04-15 22:40] [ALPM] upgraded python2-gmpy2 (2.1.0a1-3 -> 2.1.0a2-1)
[2018-04-15 22:40] [ALPM] upgraded python2-pexpect (4.4.0-1 -> 4.5.0-1)
[2018-04-15 22:40] [ALPM] upgraded python2-psutil (5.4.3-1 -> 5.4.5-1)
[2018-04-15 22:40] [ALPM] transaction completed
[2018-04-15 22:40] [ALPM] running 'remove_old_cache.hook'...
[2018-04-15 22:40] [ALPM-SCRIPTLET] Could any of these updates have a bearing to the problem?
And yes I have rebooted many times.
Offline
I don't think that some python updates could break mpd, the "client: [0] process command "status"" calls are likely from something like conky or a taskbar widget or whatever.
The mpc status request actually seems good and should have triggered a
client: [1] opened from 127.0.0.1:12345
client: [1] process command list
client: process command "status"
client: command returned 0
client: process command "currentsong"
client: command returned 0
client: [1] process command list returned 0
client: [1] closedsection in the output of mpd?
I'll randomly blame avahi.
Is the avahi daemon running? Why? And do you have an mdns_minimal entry in your /etc/nsswitch.conf?
Also your LAN interface is a bond (yeah for more complexity) - did you try to bypass this and configure cantata to connect localhost or 127.0.0.1 (assuming its a local mpd)?
Offline
I run systemctl status avahi.service and I get
Unit avahi.service could not be found.So I assume the daemon is not running.
This is the line from nsswitch.conf:
hosts: files mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnameI tried a different tack. I decided to start mpd via systemd by enabling mpd.service. Now cantata and mpc reports a different error:
MPD reported the following error: No databaseI tried something else. I killed mpd and started it via systemd enabling mpd.service. Now Cantata, nmcpcpp and mpc all report this error:
MPD reported the following error: No databaseDoes this mean the server issue is resolved? But why doesn't mpd read the database?
Offline
"avahi-daemon.service" and the nsswitch.conf supports this setup - the fact that you're not aware of it is a bit worrying; it does not install itself.
If you have no idea why it is running, stop and disable the service and revert nsswitch.conf, https://wiki.archlinux.org/index.php/Avahi
The mpd system service will operate on a global config, not yours. It reports there's no database because there's no sane global config.
Offline
Sorry seth. My personal error. Typed in the wrong command. systemctl status avahi.service instead of systemctl status avahi-daemon.service
Avahi is actually running. I am aware of avahi.
Just not sure why suddenly not working. I played music last name, left the programming running to do something else, but came back and was flagged by the errors.
How to check global config?
Offline
systemctl status avahi-daemon:
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2018-04-16 20:20:37 BST; 2h 33min ago
Main PID: 674 (avahi-daemon)
Status: "avahi-daemon 0.7 starting up."
Tasks: 2 (limit: 4915)
Memory: 2.3M
CGroup: /system.slice/avahi-daemon.service
├─674 avahi-daemon: running [TUF-Z270.local]
└─685 avahi-daemon: chroot helper
Apr 16 20:20:37 TUF-Z270 avahi-daemon[674]: Joining mDNS multicast group on interface bond0.IPv4 with address 192.168.1.3.
Apr 16 20:20:37 TUF-Z270 avahi-daemon[674]: New relevant interface bond0.IPv4 for mDNS.
Apr 16 20:20:37 TUF-Z270 avahi-daemon[674]: Registering new address record for 192.168.1.3 on bond0.IPv4.
Apr 16 20:20:40 TUF-Z270 avahi-daemon[674]: Joining mDNS multicast group on interface bond0.IPv6 with address fe80::2e56:dcff:fe39:e220.
Apr 16 20:20:40 TUF-Z270 avahi-daemon[674]: New relevant interface bond0.IPv6 for mDNS.
Apr 16 20:20:40 TUF-Z270 avahi-daemon[674]: Registering new address record for fe80::2e56:dcff:fe39:e220 on bond0.*.
Apr 16 20:20:46 TUF-Z270 avahi-daemon[674]: Leaving mDNS multicast group on interface bond0.IPv6 with address fe80::2e56:dcff:fe39:e220.
Apr 16 20:20:46 TUF-Z270 avahi-daemon[674]: Joining mDNS multicast group on interface bond0.IPv6 with address fdb0:8900:7867:b200:2e56:dcff:fe39:e220.
Apr 16 20:20:46 TUF-Z270 avahi-daemon[674]: Registering new address record for fdb0:8900:7867:b200:2e56:dcff:fe39:e220 on bond0.*.
Apr 16 20:20:46 TUF-Z270 avahi-daemon[674]: Withdrawing address record for fe80::2e56:dcff:fe39:e220 on bond0.systemctl status mpd.service:
● mpd.service - Music Player Daemon
Loaded: loaded (/usr/lib/systemd/system/mpd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2018-04-16 20:20:37 BST; 2h 34min ago
Docs: man:mpd(1)
man:mpd.conf(5)
Main PID: 739 (mpd)
Tasks: 5 (limit: 4915)
Memory: 77.3M
CGroup: /system.slice/mpd.service
└─739 /usr/bin/mpd --no-daemon
Apr 16 20:20:37 TUF-Z270 systemd[1]: Starting Music Player Daemon...
Apr 16 20:20:37 TUF-Z270 mpd[739]: config: Found database setting without music_directory - disabling database
Apr 16 20:20:37 TUF-Z270 mpd[739]: output: No 'AudioOutput' defined in config file
Apr 16 20:20:37 TUF-Z270 mpd[739]: output: Attempt to detect audio output device
Apr 16 20:20:37 TUF-Z270 mpd[739]: output: Attempting to detect a alsa audio device
Apr 16 20:20:37 TUF-Z270 mpd[739]: output: Successfully detected a alsa audio device
Apr 16 20:20:37 TUF-Z270 systemd[1]: Started Music Player Daemon. Why found database without music_directory? Here is mpd.conf:
This setting controls the top directory which MPD will search to discover the
# available audio files and add them to the daemon's online database. This
# setting defaults to the XDG directory, otherwise the music directory will be
# be disabled and audio files will only be accepted over ipc socket (using
# file:// protocol) or streaming files over an accepted protocol.
#
music_directory "/home/DataPool/Music"
#
# This setting sets the MPD internal playlist directory. The purpose of this
# directory is storage for playlists created by MPD. The server will use
# playlist files not created by the server but only if they are in the MPD
# format. This setting defaults to playlist saving being disabled.
#
playlist_directory "~/.config/mpd/playlists"
#
# This setting sets the location of the MPD database. This file is used to
# load the database at server start up and store the database while the
# server is not up. This setting defaults to disabled which will allow
# MPD to accept files over ipc socket (using file:// protocol) or streaming
# files over an accepted protocol.
#
db_file "~/.config/mpd/database"
#
# These settings are the locations for the daemon log files for the daemon.
# These logs are great for troubleshooting, depending on your log_level
# settings.
#
# The special value "syslog" makes MPD use the local syslog daemon. This
# setting defaults to logging to syslog, otherwise logging is disabled.
#
log_file "~/.config/mpd/log"
#
# This setting sets the location of the file which stores the process ID
# for use of mpd --kill and some init scripts. This setting is disabled by
# default and the pid file will not be stored.
#
pid_file "~/.config/mpd/pid"
#
# This setting sets the location of the file which contains information about
# most variables to get MPD back into the same general shape it was in before
# it was brought down. This setting is disabled by default and the server
# state will be reset on server start up.
#
state_file "~/.config/mpd/state"
#
# The location of the sticker database. This is a database which
# manages dynamic information attached to songs.
#
sticker_file "~/.config/mpd/sticker.sql"Offline
did you try to bypass this and configure cantata to connect localhost or 127.0.0.1 (assuming its a local mpd)?
Offline
I somehow was able to make it work by copying my database directory to /etc/mpd.conf:
# See: /usr/share/doc/mpd/mpdconf.example
pid_file "/run/mpd/mpd.pid"
db_file "/var/lib/mpd/mpd.db"
state_file "/var/lib/mpd/mpdstate"
playlist_directory "/var/lib/mpd/playlists"
music_directory "/home/DataPool/Music"I can play music, update db, etc but this is giving me a strange behaviour. I can only play music if JACK is tuned off. When I start JACK and try to play music, it doesn't play music.
Can this be a problem with JACK or alsa? Why is mpd ignoring the configuration file in my home directory and reading from /etc/mpd.conf? Permissions perhaps?
And I did try localhost for Cantata. Same behaviour.
Last edited by d_fajardo (2018-04-17 14:13:26)
Offline
I got everything working.
I went back to the daemon instead of systemd, bypassed to connect to localhost 127.0.0.1 and mpd, jack, alsa are all working again.
Thanks seth for your patience.
Offline
Pages: 1