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

**URL:** <https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118>\
**Category:** Help\
**Created:** [February 16, 2020, 8:47pm UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118 "2020-02-16T20:47:11Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![rik](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/rik/32/315_2.png) [@rik](https://discourse.beets.io/u/rik)\
**Post date:** [February 16, 2020, 8:47pm UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118/1 "2020-02-16T20:47:11Z")

</div>

[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](https://canada1.discourse-cdn.com/flex029/uploads/beets/original/1X/da34a29b696116d3ab28029af54df59ecf3e37e6.png)

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](https://canada1.discourse-cdn.com/flex029/uploads/beets/original/1X/1723d9a3efecef79a6a3d274773334446468f4ce.png)

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](https://github.com/beetbox/beets/issues/3309). 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](https://github.com/beetbox/beets/pull/3330), 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!

---

<div class="post-metadata">

**Author:** ![rik](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/rik/32/315_2.png) [@rik](https://discourse.beets.io/u/rik)\
**Post date:** [February 16, 2020, 10:08pm UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118/2 "2020-02-16T22:08:17Z")

</div>

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](https://canada1.discourse-cdn.com/flex029/uploads/beets/original/1X/b6a6b064daa28b3fbfe70cac5093b2669a11c536.png)

---

<div class="post-metadata">

**Author:** ![adrian](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/adrian/32/4_2.png) [@adrian](https://discourse.beets.io/u/adrian)\
**Post date:** [February 17, 2020, 12:08am UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118/3 "2020-02-17T00:08:33Z")

</div>

> [@rik](#):
>
> ConnectionResetError: [Errno 104] Connection reset by peer

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

> [@rik](#):
>
> 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?

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

> [@rik](#):
>
> shouldn’t it be possible to save this state?

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

---

<div class="post-metadata">

**Author:** ![rik](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/rik/32/315_2.png) [@rik](https://discourse.beets.io/u/rik)\
**Post date:** [February 18, 2020, 12:49am UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118/4 "2020-02-18T00:49:36Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![adrian](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/adrian/32/4_2.png) [@adrian](https://discourse.beets.io/u/adrian)\
**Post date:** [February 18, 2020, 1:04am UTC](https://discourse.beets.io/t/bpd-slow-to-start-and-then-connectionreseterror-on-rpi3/1118/5 "2020-02-18T01:04:13Z")

</div>

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… 😕