r3580 cannot connect with mpd 0.18.1 - "Failed to send command to "Default" (localhost:6,600) - not connected"

[GoogleCodeExporter]

Recently updated to the new version of mpd and cantata (1.1.3 and r3580) can no 
longer connect to it.  Other clients such as QMPDclient and ncmpcpp still work 
fine.  My mpd.conf is pretty much vanilla except for my collection location, 
which is located on an external drive, symlinked through my /~.

Archlinux
mpd 0.18.1
KDE 4.11.3
Qt 4.8.5
qmpdclient 1.2.2
ncmpcpp 0.5.10

1. Start cantata
2. It briefly displays the coverart of the current track played by mpd in the 
background of the play queue window (settings>interface>Play Queue>"Use 
coverart as background") while the artist window (Alt+1) is querying its list 
artists.
3. The querying stops, no artists are displayed and the message "Failed to send 
command to "Default" (localhost:6,600) - not connected" shows up in a red box.
4. Pressing the connect button brings up the same error message in step 3.
5. Exiting cantata brings up KDE's crash handler (see attached).


Attached is a trace

Original issue reported on code.google.com by ms6676...@gmail.com on 7 Nov 2013 at 10:37

Attachments:

• cantata-20131107-023552.kcrash.txt

[GoogleCodeExporter]

Moved ~/.kde4/share/config/cantatarc to somewhere else and restarted the 
initial setup process, "standard multi-user/server setup" as before.  I still 
get the "failed to send command" error. 

Original comment by ms6676...@gmail.com on 7 Nov 2013 at 10:59

[GoogleCodeExporter]

Hmmm.... odd, I've tried with a self compiled 0.18 (not 0.18.1 though), and 
Cantata can connect. Its obviously connected in you case too - else it would 
not know when the current track is.

Please update to trunk, so that I know you are using the latest version (and 
the same as I'm using here). Then start cantata from the command line using:

CANTATA_DEBUG=1 cantata

This should log MPD communications to ~/.cache/cantata/cantata.log Please post 
the contents of this here.

The crash I'll look into later, as its not related to mpd version - is this 
with trunk, or 1.1.3?

Original comment by craig.p....@gmail.com on 7 Nov 2013 at 10:44

[GoogleCodeExporter]

Okay, I checked out r3584 and running the debug command in post #2 does not 
yield ~/.cache/cantata/cantata.log for the KDE build, strange, but it does so 
for the Qt build.  

For both KDE and Qt builds, as stated in post #1, cantata connects on my end 
for a split second and if the tune is playing knotify pops up with the album 
art and track info before cantata abrupt disconnects from mpd.  Pressing 
connect again when another track is playing yields the same thing: split second 
connection, display of the album info through knotify and then disconnection.

Here's the terminal output from the KDE build whenever I attempt to connect to 
mpd (I don't have kwallet installed nor do I plan to):

cantata(4578)/kdeui (Wallet): The kwalletd service has been disabled 
cantata(4578)/kdeui (Wallet) KWallet::Wallet::isEnabled: Invalid DBus reply:  
QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name 
org.kde.kwalletd was not provided by any .service files")

I also included the buildscripts I used to compile the latest revision.  I 
don't know why the KDE version does not yield a log file under ~/.cache/cantata 
or anywhere in ~/.kde4.

Original comment by ms6676...@gmail.com on 8 Nov 2013 at 2:44

Attachments:

• cantata-KDE_20131107_mpd_connect_error.txt
• cantata-Qt_20131107_mpd_connect_error.log
• Cantata-Qt-SVN_PKGBUILD
• Cantata-KDE-svn_PKGBUILD

[GoogleCodeExporter]

From the log file, it looks as if "listallinfo" failed. Cantata uses this 
command to get the music listing from mpd. Do you have this disabled in your 
MPD setup? (not sure if this can be done though!)

What happens if you run the following from a commandline:

1. Connect to to MPD via telnet:
    telnet localhost 6600

2. In the telnet window, type
    listallinfo

3. To quit telnet; press 'Ctrl' and  ']' together - then type 'quit' at the 
'telnet>' prompt.

Did the listallinfo work above?

-------------------

You mention KWallet - is your MPD password protected? With the trunk version of 
Cantata, you can disable the KWallet usage (pass -DENABLE_KWALLET=OFF to cmake)

Original comment by craig.p....@gmail.com on 8 Nov 2013 at 1:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

$ telnet localhost 6600
Trying ::1...
Connected to localhost.
Escape character is '^]'.
OK MPD 0.18.0
listallinfo
Connection closed by foreign host.
---
Peculiar and peculiar...  I downgraded to 0.17.6 and the listallinfo command 
worked.  Attached is Arch's buildscript for mpd and the mpdconf.example 
included with 0.18.3.  I don't see any flag that would disable it nor any 
mpd.conf setting included in 0.18 that would suggest it disabled.  I note that 
the command worked with your self-compiled mpd 0.18.  I wonder if the packager 
missed a compile flag.  The only significant change I made to my mpd.conf 
(during 0.17.*) is the following to deal with a large collection:

max_playlist_length     "81920" #4096
max_command_list_size       "32048" #2048
max_output_buffer_size      "40960" #8192

EDIT: I commented out the custom max_foo settings, restarted mpd, and the 
listallinfo command still doesn't work.  Thanks for the hint to disable kwallet.

Original comment by ms6676...@gmail.com on 8 Nov 2013 at 6:41

Attachments:

• mpdconf.example
• mpd_PKGBUILD

[GoogleCodeExporter]

This would appear to be an issue with your system. I have just compiled mpd 
0.18.3 - and again, Cantata connects and plays songs just fine.

As you can see by your telnet above, your MPD closes the connection when 
receiving a 'listallinfo' request. Cantata is designed to use this, so cannot 
work without this command.

Original comment by craig.p....@gmail.com on 8 Nov 2013 at 10:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I also have the same problem on archlinux_64. Tried with cantata-1.1.2-1 and 
mpd 0.18.3-1. The telnet issue also appears.

When I try to build mpd from AUR it fails to build.I'll give it a try again 
tomorow.

cantata says:

MPDConnection 140412971501312 0x2911a78 sendCommand: "listallinfo" true false 
MPDConnection 140412971501312 0x2911a78 Connecting (std) 
MPDConnection 140412971501312 0x2911a78 established 
MPDConnection 140412971501312 0x2911a78 Waiting for read data. 0 
MPDConnection 140412971501312 0x2911a78 Read: "OK MPD 0.18.0
" 
MPDConnection 140412971501312 0x2911a78 Received identification string 
MPDConnection 140412971501312 0x2911a78 Waiting for read data. 0 
MPDConnection 140412971501312 0x2911a78 Read: "" 
MPDConnection 140412971501312 "listallinfo" failed 
MPDConnection 140412971501312 disconnectFromMPD 

Original comment by donaubum...@googlemail.com on 9 Nov 2013 at 12:01

[GoogleCodeExporter]

okay, i tried it again with a smaller collection and telnet didn't exit on 
listallinfo. Cantata also works well now.:)
Does eventually anybody how i could increase  collection size?

Original comment by donaubum...@googlemail.com on 9 Nov 2013 at 9:22

[GoogleCodeExporter]

Just an FYI, on a collection of 100,000+ tracks, listallinfo works fine with 
0.17.6, but not so with 0.18.  Could be a regression with upstream.

Original comment by ms6676...@gmail.com on 9 Nov 2013 at 2:32

[GoogleCodeExporter]

I got it working now. Only had to increase max_output_buffer_size in 
/etc/mpd.conf... my fault :)

thanks a lot!

Original comment by donaubum...@googlemail.com on 9 Nov 2013 at 3:33

[GoogleCodeExporter]

Bumped my max_output_buffer_size to 81920 from 40960 and it works fine.  I 
guess it is something to keep in mind with mpd version bumps.  Thanks don for 
the fix and craig for your patience.

Original comment by ms6676...@gmail.com on 9 Nov 2013 at 11:06

[GoogleCodeExporter]

OK, I'll mark this bug as invalid. Looks like mpd >=0.18 needs more memory to 
read all tags.

I#d report the issue upstream though, as mpd should be able to handle this. 
Perhaps there needs to be a streaming version of listallinfo - i.e. mpd could 
send the info in chunks to the client, as opposed to all at once.

Original comment by craig.p....@gmail.com on 10 Nov 2013 at 7:25

• Changed state: Invalid

[GoogleCodeExporter]

What the ....

Cantata sends "listallinfo" each time it connects to MPD?

Original comment by max.kell...@gmail.com on 13 Nov 2013 at 7:03

[GoogleCodeExporter]

It seems so, yes. That should be the reason for those ~10 seconds pause when i 
start cantata... :/

Original comment by donaubum...@googlemail.com on 13 Nov 2013 at 12:47

[GoogleCodeExporter]

No, it only sends a 'listallinfo' if its cache is out-of-date. Cantata cache's 
an XML copy of the MPD database - in ~/.cache/cantata/library/*.xml.gz Cantata 
reads this on start-up, and then compares the stored date with MPD's DB date. 
If the MPD DB is newer, then listallinfo is called to refresh the Cache.

As stated before, Cantata started as a fork of QtMPC - and this behavior was 
inherited from here. I have not changed this, however, as it makes certain 
features easier:

1. listing albums with blank-AlbumArtist (Cantata stores both artist and 
albumartist, and uses albumartist if its present, artist otherwise)
2. listing albums by date
3. Show album counts on artists, track counts on albums, total album duration, 
etc.
4. Copying songs to/from devices - its easier to check which songs, etc, are 
already present


The 10 second delay at start-up is probably Cantata reading its cache. Although 
I'm surprised its so slow. For example, Cantata reads the whole cached copy of 
Jamendo in ~5s (this cache is roughly 8meg, with 26634 artists). How large is 
you cache file?

Original comment by craig.p....@gmail.com on 15 Nov 2013 at 1:04

[GoogleCodeExporter]

Issue 328 has been merged into this issue.

Original comment by craig.p....@gmail.com on 16 Nov 2013 at 8:46

[GoogleCodeExporter]

Ok, cool! 
My cache file is 1,9mb and cantata now needs about 4 seconds. I'm running 
multiple mpd's on my pc and i switched between them for configuration-tests. 
Now, perhaps because I only use one server (or it only felt like ten:D), it 
loads faster :)
Thank you for the explanation

Original comment by donaubum...@googlemail.com on 17 Nov 2013 at 3:17

[GoogleCodeExporter]

Wow! That's a large cache file - mine is only 172k!

Can you try the following:

1. Edit models/musiclibraryitemroot.cpp and add

    #define TIME_XML_FILE_LOADING

    ...just *before* the line with '#ifdef TIME_XML_FILE_LOADING' - should be line 40

2. Recompile cantata

3. Run from the commandline

Cantata should the print out the cache filename, and how long it took to parse 
the XML. What time does it state for your 1.9mb file? My 172k takes 120ms

Original comment by craig.p....@gmail.com on 17 Nov 2013 at 9:11

[GoogleCodeExporter]

Just FYI, my output: "~/.cache/cantata/library/localhost_6600.xml.gz" 1910 

My cache file is ~4mb and I typically run one instance of mpd.  So far, I have 
yet to experience a significant delay when starting up cantata.  This program 
has been pretty performant, as 1.7 to 1.9s to load ~10k albums is great!

Original comment by ms6676...@gmail.com on 18 Nov 2013 at 3:32

[GoogleCodeExporter]

Issue 363 has been merged into this issue.

Original comment by craig.p....@gmail.com on 26 Dec 2013 at 8:18

[GoogleCodeExporter]

With regards to the original issue - MPD dropping the connection as listallinfo 
required too much memory - in trunk (which will be 1.3.0), Cantata will now use 
lsinfo recursively to obtain the music collection if listallinfo fails. (There 
is a config item to force the lsinfo usage - see the README for further details)

Original comment by craig.p....@gmail.com on 9 Jan 2014 at 10:39

[GoogleCodeExporter]

Hi,
I had the same issue with mpd 0.18.7. Thanks for the help here.

BTW: my "~/.cache/cantata/library/localhost_6600.xml.gz" is 1.5 MB. In my 
mpd.conf these values have been commented out:
#max_command_list_size      "2048"
#max_output_buffer_size     "8192"

No idea if these are the default values, but after setting them to the doubled 
size it works again:
max_command_list_size       "4096"
max_output_buffer_size      "16384"

Original comment by thenk...@gmail.com on 25 Jan 2014 at 1:12

[GoogleCodeExporter]

Original comment by kamika...@gmail.com on 27 Feb 2014 at 12:42

• Changed state: Fixed