mopidy_beets 1.1.0 and beets 1.3.9 incompatible get_tracks (title edited)

General
1

I am not sure whether i am having an issue with mopidy beets or mopidy core or something completely different altogether.

1.)
While the mopidy beets extension works fine for me when it is used to access single tracks or it is queried for a subset of tracks, it fails when it tries to fetch all data. I use rompr as a frontend. Rompr has a feature to cache different Backends in a DB. When asked to update its music collection it issues a request to mopidy beets to fetch all data.

DEBUG    2014-12-08 09:28:42,277 [13736:BeetsBackend-5] mopidy_beets.library
  Query "{}": 
INFO     2014-12-08 09:28:42,277 [13736:BeetsBackend-5] mopidy_beets.library  
  Fetch all data(browse library)  
DEBUG    2014-12-08 09:28:42,278 [13736:BeetsBackend-5] mopidy_beets.client
  Requesting http://192.168.0.2:8337/item/                                   
INFO     2014-12-08 09:28:42,279 [13736:BeetsBackend-5] requests.packages.urllib3.connectionpool                                                                                       
  Resetting dropped connection: 192.168.0.2                                                 
DEBUG    2014-12-08 09:28:46,011 [13736:BeetsBackend-5] requests.packages.urllib3.connectionpool
"GET /item/ HTTP/1.1" 200 None

client.py then fails in line 66, in get_tracks
for track_id in track_ids:
TypeError: ‘NoneType’ object is not iterable

I tried to access http://192.168.0.2:8337/item/ with curl and it returned my collection as json.
As i suspect my system to suffer from a mixed setup from apt and pip, i have setup a virtualenv with mopidy and beets where i encountered the same behaviour. In trying to track this down further, i changed mopidy_beets to access the beets api instead of the web api to fetch all data in client.py.

   def get_tracks(self):
        lib = beets.library.Library("/data/music/beetslibrary.blb")
        tracks = []
        for row in lib.items():
            logger.info('Track id: %s' % row['id'])
            tracks.append(self.get_track(row['id']))
        return tracks

Now this works as expected.
So i suspect something is wrong with mopidy_beets and the connectionpool at least on my system.
i use:

  • mopidy 0.19.4
  • mopidy_beets 1.1.0
  • beets 1.3.9

beet stats:

Tracks: 30875
Total time: 13.0 weeks
Approximate total size: 315.0 GB
Artists: 4758
Albums: 4037
Album artists: 1612

2.)
While i am sure @jodal had good reasons to use the web api when writing mopidy_beets, i started to wonder whether using the beets api wouldn`t be a good alternative. The Advantage of not having to make sure a beets web process is running before mopidy is started and overall reduced complexity would outweigh the disadvantage of it being a local only setup for me.
What needs to be considered when writing a mopidy_beets_local extension?
Obviously such an extension would return a local file path instead of beets web url to the clients.

2

I think you are best off directing this to @dz0ny (mopidy-beets author).

3

I am confused https://github.com/mopidy/mopidy-beets gives @jodal as the author.

Meanwhile i dug a little further and found a pull request by geigerzähler.
https://github.com/mopidy/mopidy-beets/pull/9

When changing get_tracks in client.py to

def get_tracks(self):
    res = self._get('/item/').get('items')
    try:
        return self._parse_query(res)
    except Exception:
        return False

it works. So i guess the issue is incompatible versions of beets and mopidy_beets.

4

I’ve just done monkey work on Mopidy-Beets. Most of the code is from the first commit in the repo, which is by @dz0ny.

5

okay, good then.
Should i open a bug-report in the github repo or wait for @dz0ny to reply?

6

If you want a quick reply try him on IRC. He is usually in the Mopidy channel.

7

Thank you. Since everything works for me, i am in no hurry.