(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
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.
Leave a Reply