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