Last night after our first day of hacking a group of intrepid developers had tapas.

We ate way too much and followed with some great ice-cream. Try the dulce de leche.

As most of our event destinations have been within walking distance, we figured we could also walk to the Collabora sponsored party.

Map: check.
GPS: check.
Location close: check.
Sugar induced enthusiasm: check.

It soon became obvious that walking to the golf course wasn’t as simple as we’d first hoped. We had to jump a few highway barriers.

And we clambered along dirt shoulders.

We played frogger with Spanish traffic, and then decided it was time to head back to find a taxi.

We made it and went straight the the bar where the fun was flowing.

Danimo and Chani in serious conversation.

And Thiago decided to recite some shakespeare to us.

And Markey was eyeing off the bar.

One of the most challenging parts of the transition to Amarok 2 was refactoring the innards of the application to make it more scalable, robust and flexible for future improvements. In many ways, this was one of the biggest technical problems of the 1.4 series — it did not scale well to new features.

Following the release of Amarok 2.0, we received mixed reviews from critics and users alike. Many writers praised the user interface overhaul and infrastructure changes, such as Ryan Paul in his article over at Ars Technica:

“After extensive testing, I’m convinced that Amarok 2 is a major improvement.”

Jeremy LaCroix of linux.com reported a fair review and noted many aspects of Amarok 2.0 that left much improvement to be desired. As a team, we’ve concentrated on many of the concerns that have been raised in reviews and in forum posts by evaluating importance and relative cost of implementation. Examples of requests which we have brought back for the 2.1 release of Amarok include: track queueing, replay gain support, playlist searching and playlist layouts.

We were well aware that with the release of Amarok 2.0, it would be impossible to match the feature set precedent that had been set so high by us in previous releases. To put it simply, we felt that Amarok as a project would have been detrimentally affected by indefinitely waiting to reach feature parity with the 1.4 releases. We were forced to take a stand and simply tell ourselves to wait to implement them. Trying to incorporate the features that are the most useful and important is a difficult task when there are often twelve different responses between five people in a discussion — one man’s garbage is another man’s treasure. That said, we did elect to remove some features from Amarok entirely – mainly for technical reasons (multiple database support for example), some for lack of developer resources (moodbar), and also some for usability reasons (such as tabular playlist design – remember, we’re the experts!).

Initially, the responses to the announcements of dropping features was exactly what we expected — there would be outcry. We expected this for a number of reasons: only the disgruntled speak up, and most readers wouldn’t initially understand how they could adapt to new paradigms. We dealt with this by trying the best we could to deal with the fallout by responding to each individual complaint or worry, but obviously we couldn’t get to all of them (and some were not worth wasting time on). I feel that we’ve managed the community quite well, and that the community has been good to us too by mostly understanding our position and being patient with the developments. Honest communication through blogs of missing features that would return was appreciated by users, and we’ve done our best to bring back the most requested for 2.1.

Many users have decided to stick with Amarok 1.4 for the time being until they see a better set of features implemented. And quite frankly, that’s okay with us. On the otherside, there are users who are keen to try out newer development features but are uncomfortable messing with their system compiling unstable development versions. Neon, our nightly build package service has been praised and exceptionally useful to give users cutting edge builds with no hassle.

Finally, it seems to us that most of our users have noticed the rough edges of the graphics which are being used in the application (specifically the context view). We realise that this does need some work and are trying hard to work with artists develop some great visuals. Also we’ve tried to improve the usability and performance of the context view by providing only a single containment rather than four, and better widgets to use.

If you’re interested in seeing a tour of some of the new (and revisited) features which are coming to Amarok 2.1, take a look at this great overview.

Recently I began using QtCreator to try and do some development on Amarok. During my day job as a Java developer I get to work with tools like Intellij, which is a great IDE when you can put aside the problems of Java GUI apps on Linux. For a long time I’ve been using vim for my KDE development which has been more than sufficient, but lately I’m craving some of that productivity win that a fully fledged IDE can give.

Today I’ll show you how you can set up your KDE application in Qt Creator and use it’s interactive debugging to enhance your development speed. I’ll assume that you have an existing KDE project and you’re using Qt Creator 1.1, and I’m not going to do any whining about bugs and that rubbish.

Firstly, you’ll need to open a project. It’s as easy as File > Open and then find your CMakeLists.txt file. Your project should be parsed and opened. While we’re at it, let’s make sure that our compilation is optimised to use all of our computational power. Visit the Projects tab, select Amarok and under Build Steps add -j5 (or similar) to the additional arguments input.

Now let’s get straight to the debugging. Back in the Projects tab, find the Run Settings panel and add –nofork as an argument. This tells the application to run without forking so we can attach to the process without worrying about magic foo computer stuff. I’d also recommend enabling the debugging helper which can be turned on in the settings window (under debugging).

Press F5 to start the debugging the application. Either before or during, or after the application has started up, set breakpoints in the application by clicking on a margin in a source file. You’ll see a little red icon display.

When you hit a breakpoint, the application will stop as it waits for the debugger. Here’s where using the interactive debugger wins over using gdb directly. You can easily see objects in the stack and navigate between callers. You can easily switch between thread dumps, and view local variables. You can set watches and not have to worry about remembering all the fiddly commands and what you are and aren’t watching. Stepping over and into functions is a breeze with the keyboard shortcuts (F10 and F11 to step over and into respectively).

This quick guide should hopefully be applicable to any KDE app, not just Amarok. I’ll let you discover the intricacies of using gdb as a debugging tool from within the IDE.

Here’s the problem. Any returned GdkPixbuf objects from libgpod when called from within Amarok are invalid — they’re either garbled junk, null, glib asserts, or libgpod throws an assertion claiming something or other:

(process:26875): GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `src != NULL' failed
(process:26875): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(process:16782): CRITICAL **: unpack_UYVY: assertion `width * height * 2 == bytes_len' failed

The most bizarre part of it is that the exact same code works perfectly when called from within one of libgpod’s unit tests, and artwork retrieval works fine in gtkpod.

A few things I know for sure:

1. There is only one version of libgpod installed (0.7.0), self compiled with gdkpixbuf support
2. Gtkpod was also self compiled against libgpod 0.7.0
3. The libgpod guys have been very involved but can’t provide any answers
4. Both gtkpod and Amarok link to the same versions of libgpod and gdk:
   $> ldd /usr/lib/kde4/libamarok_collection-ipodcollection.so
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4
$> ldd `which gtkpod`
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
libgpod.so.4 => /usr/lib/libgpod.so.4

5. Could it be a race condition somewhere? Perhaps, but as I see it, the code is only ever called from the Qt GUI thread.

Here’s the snippet of code: http://pastie.org/415144

Can anyone provide any insight to this problem? I’m going bananas trying to solve it.

Update: Problem solved folks! Turned out to be a misuse of the libgpod api – calling itdb_device_read_sysinfo() kills the artwork structs which have been already initialised. The blame game lies equally on Amarok (for incorrect usage) and libgpod (for poor documentation and unexpected results). Good news is that the grand folks upstream at libgpod have been notified and they’ll be improving their API and docs.

Amarok 2 is really gearing up to become a great piece of software. We are all are frantically trying to find any time we can steal from our busy schedules of work, study, and good-times to put some of that extra special attention to detail and polish on the application.

This week I finalised the third revision of an importer tool to recover your beloved statistics, scores, ratings, lyrics and album art from an Amarok 1.4 installation. After a rather draining and involved process starting off with Ruby, moving to QtScript (javascript) I finally cut my losses and have implemented an extendible framework directly in the application with c++. You’ll be able to retrieve your stats from any of sqlite, mysql or psql database backends. Throw in a wizard, some multi-threaded goodness and an output logger, and we’ve got a snazzy new tool for your convenience.

I put a bit of extra effort in on the side to make sure that the tool won’t go to the land of bit heaven after the release of Amarok 2.0, and incorporated a pretty nifty infrastructure to allow implementations of arbitrary importers. I’m thinking iTunes, Rhythmbox, Banshee, WMP, Winamp et al. If you’re looking for easy entry into KDE development ask me how to write an importer.

There have also been a plethora of other significant updates to Amarok, such as:

• Totally reworked play list subsystems which respects groupings, dragging, extended selections, viewport updates, styles.
• The status bar, it works!
• Locale aware sorting in the collection browser. No more unintuitive placement of your Åwesome ḿusic ṱitles.
• More reliable lyrics retrievals.
• Snazzy new icons.

Stay tuned for Amarok 2 beta 3 which we’ll have out in the wild very shortly.

We’ve made a rather large change with the removal of SQLite as our database backend, opting instead for the MySQL-embedded platform. As I know that many users might not be able to rationalise this change, allow me to explain. MySQL-embedded provides users with the performance boost of a standalone server without actually needing to run the server and without needing to bother with the rather complex procedures of intialising a database, users and permissions. It was also important for us to only support one database backend as we were constantly plagued with problems across different databases. Using MySQL-embedded will thus make it very easy for us to support standalone MySQL servers (in the future) for those that already have these services running, or may want to share databases over a network.

Notable mentions include improved scripting support, the return of lyric fetching and incremental scanner support. It’s important to remember that Amarok 2.0 will not be at feature parity with 1.4 as most of the code base has been rewritten. Many of the features that are not present have simply not been reimplemented due to lack of developer time, or we are unable to complete due to current technical limitations (such as equalisers, visualisations, replay gain).

We hope you enjoy this release.

The Amarok project has started it’s annual fundraiser campaign Roktober. We’re hoping to raise a staggering €10,000 – for server costs, developer hardware, travel costs, expo and trade show exhibitions, developer meetings.

For every €10 you donate, you’ll go into a draw to win an iaudio7. This year we have two grand prizes and we will also give t-shirts to 4 second chance winners.

Also, please digg it.

I do believe that my recommendations very much match the mainstream of the opinions of the key people in Linux multimedia and desktop audio. Of course I don’t nearly know everyone of the key hackers in Linux multimedia. But I do know most of those who are actively interested in collaboration, whose projects have a lot mindshare and who attend the conferences that matter for Linux desktop audio.

Lennart forgets that Amarok is definitely a contender for the most popular music player on desktop Linux today. It possibly has the most mindshare of any Linux music player project. Remember that a long time ago, Amarok supported aRts, xine, GStreamer and helix. Now we can take advantage of not needing to care about a specific implementation for an audio output device by using Phonon.

Lennart again:

“Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)”

This implies that a developer should only use Phonon if and only if the developer is targeting a KDE application. Frankly, this reasoning is not very well formed and is shameful. Perhaps what Lennart meant to say belongs along the lines of “Developers using the KDE development libraries might want to use Phonon”.

Amarok is a perfect example of an application which uses the KDE development libraries, but is not tied into the KDE plasma workspace. A grand portion of GNOME users pro actively install Amarok on their system because it is their preferred application for listening to music. Time to pick up the slack and get with the times.

The Grote Markt in Mechelen (HDR).

The HDR which I’ve posted here proves that you can indeed create impressive shots only using free software, as long as you have a little perseverance and know how. Maybe Uga’s blogs will get there eventually .

The rest of the images are on flickr.

I’ll start by saying that l think we had very productive week, getting lots of design and development done towards our goals for Amarok 2.0. We focused heavily on critiqueing the user interfaces of the major components in our GUI: the playlist, context view and each of our sidebar browsers. In between hacking hours, Mark, Leo and myself hosted design and release-breaking-issue sessions. These have provided valuable direction and motivation to all of our developers, so you can look forward to some exciting progress as we gear up to an imminent beta (and eventually final) release!

We also brainstormed a number of post 2.0 ideas such as interface adjustments to enhance your application experience, including, but not withstanding, mobile and embedded devices. Yes, that’s right folks, before too long (hopefully) you’ll be able to run Amarok on your favourite (maybe) small form factor device. The main use case would be for remote collections and streaming, but we’re not going to shut out users who like carrying 8GB of music on memory cards.

All this talk of small form factor devices is making me drool over my N810 as I write this. Some observations: all this very slow and awkward typing makes me much more coherent; leeching off random wireless to blog has never been easier; and, the inbuilt GPS has already proven invaluable to the Amarok crew as we used it to find our restaurant when we got lost cycling through the mid-west of Belgium. Note: never cycle 15km immediately after eating a huge meal, and never let Casey on a bicycle.

Finally, a big thanks to all that made Akademy so great: the organisers, the participants, the speakers, the boffers, the paparazzi, and all the people that were responsible for either brewing, frying or coating things in sugar.