Even faster GNOME Music

Hello my GNOMEish friends!

This afternoon, I felt an urge to hear some classical music. Perhaps because I’m overworking a lot these days, I wanted to grab a good hot tea, and listen to relaxing music, and rest for a few minutes.

My player of choice is GNOME Music.

In the past, I couldn’t use it. It was way too slow to be usable. After a round of improvements in a sleepless night, however, Music was usable again to me.

But it was not fast enough for me.

It was taking 15~20 seconds just to show the albums. That’s unacceptable!

The Investigation

Thanks to Christian Hergert we have a beautiful and super useful Sysprof app! After running Music under Sysprof, I got this:

Sysprof result of GNOME Music
Sysprof result of GNOME Music

Clearly, there’s an area where Music hits the CPU (the area that is selected in the picture above). And, check it out, in this area, the biggest offenders were libjpeg, libpixman and libavcodec. After digging the code, there it was.

The performance issue was caused by the Album Art loading code.

The Solution

Looking at the code, I made a simple experiement: tried to see how many parallel lookups (i.e. asynchronous calls) Music was performing.

The number is shocking: Music was running almost 1200 asynchronous operations in parallel.

These operations would be fired almost at the same time, would load Zeus knows how many album covers, and return almost at the same time. Precisely when these lookups finished, Music had that performance hit.

The solution, however, was quite simple: limit the number of active lookups, and queue them if needed. But, limit to what? 64 parallel lookups? Or perhaps 32?

I needed data.

The Research

DISCLAIMER: I know very well that the information below is not scientific data, nor a robust benchmark. It’s just a simple comparison.

I decided to try out a few lookup limits, and see what works best. I have a huge collection, big enough to squeeze Music. I’m on an i7 with 8GB of RAM, 7200RPM spinning hard drive.

It was measured (i) the time it took for the album list to show, (ii) the time for all album covers to be loaded, and (iii) a quick score I made up on the fly. All of them are of the type lower is better. I ran each limit 10 times, and used the average of the results.

Time comparison
Comparison of various lookup limits

The “No Limits” columns represent what Music does now. It takes a long time to show up, but the album covers are visible almost immediately after.

First conclusion: limiting the number of lookups always performs better than not. That said, the problem was just a matter of finding the optimal value.

After some trial and error, I found that 24 is an excellent limit.

The Result

In general, the initial loading of albums with the performance improvement is around 73% faster than without it. That’s quite a gain!

But words cannot express the satisfaction of seeing this:



GNOME Music: the road to 3.24

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

GNOME Music 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.

The future of GNOME Music

GNOME Music is an app that I particularly fell in love. Not because it worked perfectly (it didn’t, at all), nor because it’s fast to the last bit (it isn’t, at all), neither because it’s written in a programming language that I love (i.e. C. And no, it isn’t).

So why the hell did I invest my free time, energy and resources on it? If we look on how it is right now, it makes no sense. So for my dog’s sake, why?

Simply because I want to push GNOME forward.

I saw a very rough, embryonic prototype of what could be a good app. I saw bottlenecks all around, things to fix, tasks to complete. I saw pretty good mockups available. All the ingredients were there, we just needed a little bit of love. Working on challenging apps almost always ends up pushing the entire plataform forward.

To add value to this discussion, and for you guys to understand the future of GNOME Music, we must see the history of this app first.

Long ago…

There was an app called GNOME Music. It was written as a quick prototype in JavaScript. Then, another version of the same app was written in Python, and this snaky version of the app was more complete than the other.

The Python version was made the official one.

And yet, the pythonic Music was also a quick prototype.

I’m not particularly against quick prototypes. It’s just that the methods to maintain prototypes are radically different from the methods to maintain apps on the long run. Prototypes are meant to be rapidly developed and showcase a certain functionality, right? GNOME Music, however, is part of the extended GNOME plataform – this implies maintaining it for thousands of users during many years.

Features were being added to Music in such a way that the code was getting messier and messier. That sucks.

Back to the Future

All this trip to the past has serious implications on how GNOME Music codebase looks like now. At the GNOME Core Apps Hackfest, we had the chance to sit down, analyse the code and sketch out what we need to do.

Sad news: most of this work consists of fixing and reorganizing what we have now, so in the future we can still read Music’s code and work on it (instead of sitting down and crying every time we have to deal with it, which is basically what used to happen a few months ago).

If I’m to draw how Music’s codebase is organized right now, it’d look like this:

Music codebase as it looks right now

Basically, everything is spread all around the entire codebase. Based on that, here is our current, actionable list of tasks on how to fix that (the names are not final):

  • All the data will be encapsulated by a new backend class
  • A new concept of “data sources” will beintroduced
    • Data source is an interface for code that provides data
    • Data sources provide:
      • Albums
      • Artists
      • Playlists
      • Search results
    • The current sources will implement this interface
      • Grilo will be a data source
      • Tracker will be another data source
  • Only one singleton class will exist, the Backend class
    • The Backend manages:
      • The Playlists object
      • Data sources
      • The Player
      • Album art cache
      • MPRIS
  • The UI only communicates with the backend

tl; dr: we’re splitting UI from backend work and adding a layer to abstract data sources. This is how it should look like, after the plan is implemented:

Next architecture of GNOME Music


We probably may be overloading the Backend class (suggestions?) but this new architecture will give us some more flexibility to implement new data providers, sync online accounts data, and whatever else we need.

I already started working on this move with the Playlists code. You can check it out here. It needs review and, of course, testing, but the prototype is there to show how we can move on.

And the Sun starts to shine again on Music land.

Looking forward GNOME 3.22

The old GNOME mantra:

The best GNOME release is the next GNOME release.

is still true! Between backend reworks, Summer of Code projects and spontaneous contributions from awsome random contributors, here are the things that I’m looking forward with GNOME 3.22 release.


Let’s face it: Nautilus is heading towards a bright future and it’s getting in a very good shape – and the community that is growing around it is absolutely gorgeous. Obviously, this is not random; Carlos Soriano is working very hard to make it happen.

This leads not only to fun IRC chats, but tons of contributions. Nautilus’ codebase had its style unified, making it very nice for newcomers to send their patches. After a huge work on Nautilus’ internals, things are in a better shape now and new features are popping up. If you want a more complete list of Nautilus improvements, check Carlos’ blog post about it. Below, the ones that caught my attention.

Batch rename

I didn’t notice how a batch rename tool could simplify one’s life. I personally wasn’t confident this would be useful, but now I can’t live without it! Thanks to Alex Pandelea, we can do things like this now:

The new batch rename dialog

Integrated compressed files

Another detail that required lots of improvements on how Nautilus works is the integration of compressed files. This is the kind of thing that gives Nautilus a kudo for the attention to details. Having progress report in the Nautilus progress popover and a built-in way to create compressed files makes me feel like Nautilus cares about me 🙂 Thanks Razvan!

compress window.png
Dialog to compress a set of files (picture made by Carlos)
Progress of the compression in the popover (picture made by Carlos)


GNOME Calendar

This cycle I focused my efforts at GNOME Calendar. I already wrote about it multiple times, but in short, Calendar received:



In one phrase: I can use Music now. My music collection is considerable (over 9000 individual songs) and GNOME Music simply couldn’t handle it.

Let me be crystal clear: Tracker is fast as hell. GNOME Music was slow to death. Retrieving the list of songs from Tracker takes about 0.25 second, putting the songs into a window and presenting it used to take ~85 seconds. Yes, that’s right, 340x slower.

Fortunately, this is fixed and will be distributed with GNOME Music 3.22 🙂



This new app is surprising me. A lot. I was trying to play Spyro 3 – Year of the dragon for months, without success. Then I tried GNOME Games – without success too. But at least, I could report my issues to Adrien, and what a supportive guy he is! With his help, we were able to debug my failures and, surprise!, he fixed it right after.

Not only it automagically discovers my games, it also searches for nice covers (thanks to Bastien Nocera’s Grilo work)

And now, after a journey through different PS1 emulators, I can play Spyro again. I could only get it working using Games from Flatpak’s nightly builds – but hey, it works, that’s what matters.

Good old time, huh?

Yay! That’s very promosing! (Although I wonder how much  it will impact my productivity :P)


Thanks to the amazing team that leads the development of Gtk+, it keeps receiving a flow of new features, improvements and fixes so fast that it’s hard to track. This round, I was able to add a small feature, the CSS background-blend-mode property support. It definitely isn’t a big thing, but I learned a lot throughout the whole process and I plan to work on more CSS3 features like filters, blend groups and others (and finally give Lapo all the tools he wants to create his crazy themes).

But wait! The greatest thing that Gtk+ will receive in 3.24 (or rather, 4.0 if I understood the new release scheme correctly) is the Gtk+ Scene Graph (aka GSK), thanks to Emmanuele. I’m looking forward using it in a future release!

Not everything is perfect…

Some things didn’t make for this release. I’m particularly sad about GNOME Control Center, which received a new UI but won’t switch to it because not all panels got ready in time. Also, Nautilus’ actionbar wasn’t good enough too – we weren’t satisfied with the end result, and decided it needs more research and love.

Basically, everything I touched outside GNOME Calendar. Sorry, folks!

… but we’ll get there!

So now it’s time to start planning the next cycle – this time, I want to try something new and decide some features based only on community input. I’ll run pools and decide the priorities with that, ask around and really try to get the community involved in the whole process. Stay tuned!

I’d like to thank my employer Endless for allowing me to work on GNOME – it’s awsome that I can do what I love to do as part of my job. Thanks, Endless!

banner down

GNOME Music is fast again

Yo GNOMErs! It’s been a while, huh?

Yesterday I was with a very strong headache, and I couldn’t sleep. So I decided to listen to some classical music and see if I could relax a little bit. What a great chance to try GNOME Music again!

Well, it wasn’t such a please. My music collection is large, literally over 9000, and Music took a f*cking minute to be ready. No. No no no no.

I was in a suboptimal health state, but oh boy that’s not acceptable. So, in another sleep-deprived night, here’s what happened: