jodal.dev - mopidy

10 years of Mopidy

2019-12-23T00:00:00+00:00

Ten years ago today, on December 23, 2009, Mopidy was born. While chatting with my friend and then-colleague Johannes Knutsen, we came up with the idea of building an MPD server that could play music from Spotify instead of local files.

This is the story of the first decade of Mopidy.

Pykka 2.0 released with better ergonomics and performance improvements

2019-05-07T00:00:00+00:00

I’ve finally released Pykka 2.0, the first major update to Pykka in almost six years.

Pykka is a Python implementation of the actor model. The actor model introduces some simple rules to control the sharing of state and cooperation between execution units, which makes it easier to build concurrent applications.

Pykka 2.0 is a major release because it is backwards incompatible in several minor ways. However, the backwards incompatible changes should only affect quite narrow use cases. Mopidy and its extensions, which is the largest open source ecosystem I know of that uses Pykka, runs unmodified on Pykka 2.0.

In this blog post I’ll go through some of the more important improvements in 2.0.

Mopidy-MPRIS 2.0 released

2018-12-07T00:00:00+00:00

I’ve released Mopidy-MPRIS 2.0, the first major update to Mopidy-MPRIS in about 3.5 years.

Mopidy-MPRIS is a Mopidy extension that makes Mopidy controllable from other programs on the same machine through D-Bus. This makes it possible to control Mopidy from various widgets in GNOME/KDE/etc, as well as with keyboard media keys.

Four years of JavaScript churn: Mopidy.js 1.0

2018-12-02T00:00:00+00:00

Yesterday, I released v1.0.0 of the Mopidy.js JavaScript library. Even though the library serves as the basis for most Mopidy web clients and has been in active use since 2013, this was the first release in almost four years.

Four years is quite a long time in the world of JavaScript.

Bringing the Mopidy music server to the browser

2017-08-26T00:00:00+00:00

Note: This is a blog post draft that was originally written in January 2013, left unattended for 1689 days, and rediscovered and published unedited in August 2017.

During the five years since Mopidy entered the browser with its HTTP JSON-RPC API and the Mopidy.js JavaScript library, many successful Mopidy web clients have been built on top of this foundation. The APIs themselves have survived the test of time and have required minimal maintenance, just as I hoped when implementing the APIs back in November 2012.

Mopidy is a music server written in Python. It plays music from various sources, including local disk and Spotify. Mopidy can be remote-controlled by, among others, MPD clients.

In Mopidy 0.10, released in the middle of December, we added an HTTP frontend. The HTTP frontend takes Mopidy’s full core API and makes it available from JavaScript in the browser. This means that you now can make your own web clients for Mopidy in JavaScript, and Wouter van Wijk has already started on his client (updated link).

I’d like to write a bit about how we made the HTTP client.

March and April contributions

2016-04-30T00:00:00+00:00

The following is a short summary of my open source work in March and April, almost like in previous months, except that I haven’t spent as much time as previously on Open Source the last two months.

February contributions

2016-03-01T00:00:00+00:00

The following is a short summary of my open source work in February, just like in previous months.

A guide to poor API management

2016-02-18T00:00:00+00:00

This is the story of libspotify, as experienced by a Spotify customer and libspotify developer for six years.

January contributions

2016-02-01T00:00:00+00:00

The following is a short summary of my open source work in January, just like I did back in November and December.

December contributions

2016-01-01T00:00:00+00:00

The following is a short summary of my open source work in December, following up on my first report in November.

November contributions

2015-11-30T00:00:00+00:00

The following is a short summary of my open source work in November. My hope is that keeping better track of what I’m doing will help me reflect on how I spend my time, and help me to focus my efforts better.

Building ARM Debian packages with pbuilder

2015-03-08T00:00:00+00:00

The goal of this post is to help myself reproduce this pbuilder setup in the future. If you find it useful too, then that’s great.

Building ARM packages on older ARM devices like the Raspberry Pi 1 is slow, so I want to use a single amd64 machine to build Debian packages for all my target platforms:

amd64,
i386,
armel/ARMv4+ (e.g. Debian on Raspberry Pi 1),
armhf/ARMv6+ (Raspbian), and
armhf/ARMv7+ (e.g. Debian/Ubuntu on Raspberry Pi 2, Odroid C1, etc.).

Preferably, I want to build the packages for the current Debian stable, which at the time of writing is wheezy, so that they’ll work for as many users as possible.

Debian packaging of Mopidy

2014-10-28T00:00:00+00:00

My first upload to Debian as a Debian Maintainer, Mopidy 0.19.4-3, landed in Debian testing today, well in time for the upcoming freeze.

The new version adjusts the LSB facilities the sysvinit script depends on, to make sure that DNS lookups, DBus (used by Mopidy-MPRIS), and Avahi (used for Zeroconf service publishing) are available before Mopidy starts.

pyspotify v2.0.0b1 released, with new event loop and audio sinks

2014-04-24T00:00:00+00:00

pyspotify 2.x is a full rewrite of pyspotify. While pyspotify 1.x is a CPython C extension, pyspotify 2.x uses CFFI to make 100% of the libspotify C library available from Python. It works on CPython 2.7 and 3.2+, as well as PyPy 2.1+.

New Python wrapper for libspotify

2014-02-14T00:00:00+00:00

Today, after about nine months of working on it now and then, I uploaded the first alpha release of pyspotify 2.0 to PyPI.

pyspotify provides a Python interface to Spotify’s online music streaming service. With it you can access music metadata, search in Spotify’s library of 20+ million tracks, manage your Spotify playlists, and play music from Spotify. All from your own Python applications.

Mopidy packaged in Debian and Ubuntu

2013-12-28T00:00:00+00:00

Looking back to my last post from September, my goal was to have the music server Mopidy packaged in Debian by the end of the year and in Ubuntu in time for the 14.04 LTS release in April. As of yesterday, Mopidy 0.17.0 is a part of Debian unstable and Ubuntu trusty, just a few days after Mopidy’s fourth anniversary on December 23.

Mopidy hosted by Rackspace

2013-07-22T00:00:00+00:00

A week ago Jesse Noller tweeted that Rackspace would provide free Rackspace cloud accounts for open source projects. It only took a couple of hours from I first mailed Jesse to we had two servers up and running.

pyspotify 1.2 released

2011-06-08T00:00:00+00:00

pyspotify is a Python wrapper for libspotify, which give developers access to the Spotify music streaming service.

Today, I tagged pyspotify 1.2 at GitHub and pushed the new release to PyPI. I’ve also made deb packages of libspotify and pyspotify available at apt.mopidy.com.

multiprocessing.Connection is not free

2011-03-20T00:00:00+00:00

I’ve previously written about how to wrap multiprocessing.Connection objects in a class that makes Connection objects picklable, and thus transferable over another Connection. That approach is still valid, but don’t use it–or Connection objects at all–for lots of use-once-and-throw-away connections.

Traits in Python using multiple inheritance

2011-03-15T00:00:00+00:00

As you probably know, if a class needs to handle two mostly unrelated concerns, the class should probably be split into two. This way, your will achieve higher cohesion in your code, which is generally considered a good thing. Though, there are times where you need to address two mostly unrelated concerns in a single class.

The Scala programming language has a concept they call traits. Scala traits can be compared to Java interfaces, except that Scala traits may be partially or fully implemented, like abstract classes. As with Java interfaces, you can mixin multiple traits in a class. If any of the traits has colliding method signatures, the last trait mixed in overrides the earlier ones. Just as with regular inheritance and interfaces, the class must implement any methods that has not been implemented by the traits, and may override any methods that already has been implemented.