Bpd: slow to start and then `ConnectionResetError` on RPI3

Help
1

[running beets version 1.4.9, Python version 3.7.3, raspbian buster]

Hi all, feeling better about the beets music DB i’ve swept together, and now pushing towards playing some tunes on a Raspberry (RPI3)! after browsing thru bunches of posts describing routes from beets via mopidy, mpd and now bpd, my picture looks like the following:

beets2mpd
beets2mpd982×402 14.8 KB

any corrections/clarifications appreciated.

bpd certainly seems to me the cleanest route as of this writing, but if others have had success (esp on RPI’s), i’d be curious.

hitting bpd (via the gpmc client) seems to work. this is what
the screen looks like for me:

gmpc_200216
gmpc_200216998×785 101 KB

but as soon as i try to PLAY a tune (select a track, then Ctl-UpArrow) i’m hitting an error:

	Traceback (most recent call last):
	File "/home/pi/.local/lib/python3.7/site-packages/beets/util/bluelet.py", line 343, in run
	value = event.fire()
	File "/home/pi/.local/lib/python3.7/site-packages/beets/util/bluelet.py", line 508, in fire
	return self.conn.sock.recv(self.bufsize)
	ConnectionResetError: [Errno 104] Connection reset by peer

this seems related to an issue arising in bpd testing. the issue describes a nice hack that passes port=0 to cause the OS to assign a port!? And it seems as if this feature was
merged, but i’m not sure whether the merge was only into the test suite, not bluelet.py?

And my uncertainty about this now makes me unclear about pip installs: it seems beets test directory is not installed, and so i can’t nose test/test_player.py or similar? i guess i need to install/build from source for this?

Finally, bpd does seem very slow (~ 5min on RPI3 over USB-mounted FAST SSD) and i’m wondering why? giving the beet -vv debug argument makes it seem as if it’s working hard to rebuild its directory tree, eg:

	bpd: Building directory tree...
	the: "The Cannonball Adderley Quintet feat. Nat Adderley" -> "Cannonball Adderley Quintet feat. Nat Adderley, The"
	the: "The Cannonball Adderley Quintet feat. Nat Adderley" -> "Cannonball Adderley Quintet feat. Nat Adderley, The"
	the: "The Cannonball Adderley Quintet feat. Nat Adderley" -> "Cannonball Adderley Quintet feat. Nat Adderley, The"
	...

shouldn’t it be possible to save this state?

thanks for any hints!

2

update: trying to use rompr as the client generates hopeful debug output:

bpd: *[127.0.0.1:49282]: connected
bpd: >[127.0.0.1:49282]: OK MPD 0.14.0
bpd: <[127.0.0.1:49282]: tagtypes
bpd: >[127.0.0.1:49282]: tagtype: Artist
bpd: >[127.0.0.1:49282]: tagtype: Album
bpd: >[127.0.0.1:49282]: tagtype: Title
bpd: >[127.0.0.1:49282]: tagtype: Track
bpd: >[127.0.0.1:49282]: tagtype: AlbumArtist
bpd: >[127.0.0.1:49282]: tagtype: AlbumArtistSort
bpd: >[127.0.0.1:49282]: tagtype: Genre
bpd: >[127.0.0.1:49282]: tagtype: Date
bpd: >[127.0.0.1:49282]: tagtype: Composer
bpd: >[127.0.0.1:49282]: tagtype: Disc
bpd: >[127.0.0.1:49282]: tagtype: filename
bpd: >[127.0.0.1:49282]: OK
bpd: <[127.0.0.1:49282]: status
bpd: >[127.0.0.1:49282]: repeat: 0
bpd: >[127.0.0.1:49282]: random: 0
bpd: >[127.0.0.1:49282]: consume: 0
bpd: >[127.0.0.1:49282]: single: 0
bpd: >[127.0.0.1:49282]: playlist: 0
bpd: >[127.0.0.1:49282]: playlistlength: 0
bpd: >[127.0.0.1:49282]: mixrampdb: 0.0
bpd: >[127.0.0.1:49282]: volume: 100
bpd: >[127.0.0.1:49282]: state: stop
bpd: >[127.0.0.1:49282]: OK
bpd: *[127.0.0.1:49282]: disconnected

seems to need details about beet’s (sqlite) database different than its default:

rompr-db-connect

3

Actually, this message is normal and not a problem, in my experience. If playing isn’t working, the problem is likely elsewhere…

Correct. You can also get it by manually downloading the “sdist” release from PyPI. Or you can just clone the git repository.

Perhaps! But we don’t currently. Raspberry Pis are super great but sometimes their slow I/O can be inconvenient…

4

thanks @adrian for your typically prompt reply!

so i’ve now cloned the beets repo, and the nosetests test/test_player.py runs successfully! (i did have to pip install mock; should i create a PR for adding this to setup.py and wiki/Hacking)

but using the repo code and firing up beet bpd , then firing up gmpc gets me only as far as being able to BROWSE the database, but NOT play it(: Here is what gmpc --debug-level=3 reports:

    ...
	17/02/20 16:34:36: INFO:    libmpd.c mpd_connect_real():#723:	Connected to mpd
	17/02/20 16:34:59: INFO:    libmpd-player.c mpd_player_play_id():#131:	trying to play id: -1
	17/02/20 16:34:59: INFO:    libmpd-status.c mpd_status_update():#137:	Songid has changed 0 32!
	17/02/20 16:34:59: INFO:    libmpd-playlist.c mpd_playlist_get_song():#107:	Trying to grab song with id: 32
	17/02/20 16:34:59: ERROR:   libmpd.c mpd_check_error():#228: Following error occurred: 1: code: 50 msg: problem parsing song info
	17/02/20 16:34:59: ERROR:   libmpd.c mpd_check_error():#232: Error callback 2
	17/02/20 16:34:59: INFO:    libmpd.c mpd_disconnect():#523:	disconnecting

any guesses? i can try to capture more via beet -vv bpd if that’d help?

5

Hmm, alas, it’s pretty hard to tell what the client means by the message “problem parsing song info.” I wish it gave more of a substantial error message! I think really getting to the bottom of it would require deeper debugging, unfortunately… :confused: