GNOME Music: the road to 3.24

(Disclaimer: this is a guest post from Marinus Schraal, the maintainer of Music)

GNOME Music 3.24.1.1 has just been released, a good time to reflect on what has happened last development cycle.

A goal for Music is to make it an exemplary application of GNOME/GTK+ Python programming and make it an entry-level project for new contributors. However the codebase was a mixture of coding styles and oversized multi-functional classes. Python is a powerful and easily accessible language, but the downside is that it can quickly get out of control if not some constraints are set on how to use it. So we started a rework to split up some of the bigger source files and enforce PEP-8 (code-style) & PEP-257 (docstrings) on new commits and bring existing code in line with it. We are not quite there yet on the clean-up front, but we have come a long way and going forward it is gonna get better.

This effort also entailed that we put off some feature additions and mainly worked on core issues, like grouping albums correctly. Album grouping has always been a sore point for Music and is usually mainly visible with for example ‘Greatest Hits’ albums being all presented as one album or with the wrong artist. Over time Music has had a lot of bug reports of this and similar issues. The underlying reason is that Music is purely metadata driven and is actually completely dependant on the data that is provided by Grilo and in turn (for local media) Tracker. If this metadata is incomplete or incorrect then Music cannot correctly display it.

So that is why we worked with the Tracker folks – in particular Garnacho – to get some indexing issues fixed and I think we did come a long way. However, to get the right experience you need to re-index your music files with a recent enough Tracker (at least 1.12) to get the metadata correctly indexed. Music can’t (understandably) force re-indexing and it’s only available via the following command line command.

$ tracker index -m audio/mpeg -m audio/flac -m audio/x-vorbis+ogg -m audio/mp4

It re-indexes the most common audio mime-types. Of course, this is based on the assumption that your music is tagged correctly to begin with. Note that tagging is prone to be taste/ripper/format specific and is often incomplete, we had to make some informed decisions here what we consider ‘correct’.

We also reworked the album art code, which in most places now supports HiDPI art. Because of changes in Tracker security policies we were forced to add some code to do local art retrieval in Music itself. It is ultimately not what we want, but it has to do for now. This also caused some stability issues in the 3.24.0 release, which should hopefully be resolved in the current release.

Part of the clean-up meant we wanted to get rid of libgd as much as possible this cycle as most of it is superseded by regular GTK+ widgets. We made some good progress, replacing (and speeding up) the albums view significantly, reworked the single album view and notifications. Kudos to Feaneron who did some heavy lifting here. There’s still more work left here coming cycle(s).

Despite the focus on making Music future ready code-wise, there were many user-visible improvements all over the place. To list a few:

  • smooth progress bar movement
  • smoother seeking
  • an empty state for the playlist dialog
  • new playlist entry for the playlist dialog
  • a shortcuts window
  • addition of composer information to the album view
  • the ability to search by composer
  • album disc separation
Captura de tela de 2017-04-12 12-27-07
Keyboard Shortcuts for GNOME Music

The most satisfying about this is that most of these contributions were made by a number of different new contributors, so a big thanks to everyone who made Music better this cycle.

Onward to 3.26

The rewrite has brought to the surface some rough edges in Music. There are some things that used to work and might not at this point, maybe because they were held together with band-aids and actually need more work to get right. There are things we want (remote sources/live updating/proper indication of played tracks/etcetera), but we can’t do yet. The core infrastructure is lacking.

The one big thing we want this cycle -besides finishing what we started last cycle- is doing the rework Feaneron blogged about earlier: having a single core model that drives the different views. This would solve a plethora of currently hard to tackle issues, some of which I just mentioned. From there we would be able to land bigger new features, like the GSoC work done on tagging & webdav sources. The Core Apps hackfest was a big part of crystallizing what needs to be done here.

Of course we cannot do this without help and we hope to see you soon on IRC (#gnome-music), on Bugzilla or check the Wiki for more info.

A final note on Tracker

In the past we used to ask people to hard reset their Tracker database if something went wrong or seemed out of whack, meaning it would be fully cleared and rebuilt. A lot of effort has gone into Tracker to make it more robust and stable. At this point we strongly suggest to not do a hard reset lightly; Music is using the tracker database for keeping track of things like playlists, favourites and played count. This might extend even further in the future.

If you have a problem with Tracker, don’t wipe it and the exclusive data that might live in it’s database: file a bug, seek help on IRC (#tracker) and we can work from there.

Advertisements

8 thoughts on “GNOME Music: the road to 3.24

  1. Sorry for the question (I’m sure you already answered it many time) but could you please describe why we need new yet another music player for GNOME (and for Linux in common)? I mean, we already have Rhythmbox. Why not to contribute to it?

    Like

    1. People do what they want. There were mockups for a music player with a GNOME-ish interface, Rhythmbox wouldn’t change to that, someone wanted to write another music player and that’s it.

      We already have Rhythmbox. Why not to contribute to it?

      For many reasons. First, Rhythmbox and Music are made with much different purposes, scopes and technologies. Music, for example, relies on Tracker, and we improved it a whole lot by developing Music.

      Second, while Rhythmbox is a GNOME application, it doesn’t follow the GNOME HIG. AFAIK the Rtmbx devs don’t think changing their UI fits their agenda. There were mockups of a simpler music player with less features and a different workflow, and it doesn’t fit Rhythmbox… What are the options? Fork+rework, or a new app.

      At last, because GNOME is about plurality. Someone wanted, entirely out of their free will, using their own free time, to create a new music player. Others liked that idea. We’re not a single-minded group of blind developers – we have different opinions, wishes and visions. Freedom (the libre type) lies in the options 🙂

      Like

      1. Thanks for detailed answer! My “pain” is about popular situation in FOSS where are a lot of music players, image viewers, text editors etc. But really big part of them is with a few maintainers (often 1-2) and without any active development. Imho, it will be better if we have much less such apps but with more stable status and active development. However, I also understand that FOSS (including GNOME) is about plurality and freedom 🙂

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s