Tuesday, 24 September 2013

Amarok MTP (Android) GSoC: Final Report

Ahoy, it is the time of the year again. The Google Summer of Code has just ended and here I come with the final report, joining my fellow Amarok GSoC student Konrad Zemek with his excellent posting.

Newer MTP device configuration dialog
Before I sum things up, let me quickly mention what I've done the very last week. In short, it was full of little features and polishing.

What I've done this week:
  • Fixed small glitches in playlist tooltips (properly escape HTML markup) and in MemoryMeta (show non-compilation albums with empty album artist).
  • Implemented reading of the device folder structure, showing the actual track path as its location (the format is compatible with kio-mtp):
  • Implemented better fall-back when we fail to read device's storage entries (mostly because the Android device has its screen locker). It turns out that (at least Samsung's MTP stack) only blocks storage listing, but happily lists all the files and other entries. So we exploit that and infer storage ids from them. :-)
  • Added support for specifying the Music folder, the folder where new music is put into. I was trying a handful of approaches how to make this editable by user and ended up with an editable combo box that shows root items and provider nice completion for all folders. I had to implement full QAbstractItemModel of MTP folder because of this, but it was fun. ;-)
  • Finally added option to show only tracks under the Music folder. This is handy in order not to pick up misc music files like ringtones.
Problems I've faced:
  • KCompletion is weird and subclassing it to my liking seems impossible because few methods are virtual and other ones use private d-pointer extensively. Fortunately QCompleter is much nicer and works (pretty well) even with a hierarchic model.
  • MTP folder/storage model is weird. There are storages (e.g. Internal memory vs. SD card) and folders, so in order to remember "put things here" you have to save either storage or folder id and whether it is a storage or a folder. I guess this is because it was designed by Microsoft...

Wrapping up

Let's see if the goals outlined in the initial project proposal have been met:
  • Complete MTP Collection rewrite that removes the dependency on deprecated MediaDevice framework: Check
  • Actual communication with the device is strictly asynchronous (threaded) in order not to block the UI: Check
  • Zero-configuration device detection and enumeration, plug & play: Check
  • Enumeration of tracks on the device along with their metadata: Check
  • Playback of tracks stored on devices with on-demand background loading: Check
  • Ability to transfer tracks out of and to MTP devices, with possibility to transcode: Check
  • Full playlist management (for devices that support them): No, see below

Future work

  • The problem with playlists is that the ones created in the most popular music player on Androids, the Google Play Music, aren't visible through the MTP API. It needs further investigation whether and how these could be accessed. In short-term I'll try to add support for traditional playlists, but I'll need external testers for that.
  • I haven't touched the album API at all, because my device (S III Mini with Android 4.2) happily ignores it and shows albums correctly without it. It might be however needed for proper album support on older devices. If it turns out this is the case during user testing, I'll add support for it.
  • Ability to specify custom file naming when uploading music would be nice.
  • Album art. My device displays album art embedded in file tags and I plan to add generic support to embed these to our transcoding/copying framework, but we could make use of the MTP thumbnail API.
My current plan is to add the last round of features and to do some final polishing, then submit a review request. As soon as the work is merged into master I'll request testing here. You can of course (and are encouraged to) test my work right away by checking out gsoc branch of my personal Amarok clone repository.


  1. Interesting insight on KCompletion and QCompleter. As I regularly check on the progress of KF5 epics, I am now wondering how to feed back such knowledge to take advantage of it in the future. This could fit into the "Cleaning up kdelibs" epic, doesn't it?

    Sorry for being off-topic ;)

  2. Very, *very* nice work. I'll test it as soon as possible with a nexus 4 and nexus 7.

  3. Yeah, cleanup opportunities with KF5 came to my mind too when looking at KCompletion. The mindset seems to be to try to deduplicate KDE "copies" of Qt classes by contributing the added functionality to Qt (5.1, 5.2...). This seems to be the case with KCompletion: http://community.kde.org/Frameworks/Epics/Contributions_to_Qt5_for_KF5.1

    On the other hand http://community.kde.org/Frameworks/Epics/KDEUI_Crumble#KCompletion_.28DONE.29 mentions the KCompletion will become its own library with KComboBox & friends. I'm a bit confused here

  4. Great, Bart, thanks for it, and also thanks for testing of the initial version. This one should give better errors in case of some problem. I do usually run amarok as:
    amarok -d --nofork 2>&1 | egrep -iC6 'mtp'
    to get only relevant debugging.

  5. Any chance to get Iphone support on this?

  6. iPhones, iPods & iPads are already supported very well since Amarok 2.7, with one gotcha: we can only support those models that libgpod does: http://gtkpod.org/wiki/Home

    This unfortunately does not include the latest models. The reason is that Apple proactively makes it extremely hard for open-source developers to work with their devices.

  7. it seems ios7 has broken something, now its stuck at the "trust this computer" dialog on my iphone 5

  8. Did you actually visit the link I provided?

  9. yep it seems libimobiledevice was broken with ios7, fix coming soon...