[Libmtp-discuss] My GSoC Proposal: MTP Collection rewrite with emphasis on Android device support (for Amarok)

[Matěj Laitl]

On 29. 4. 2013 Linus Walleij wrote:
> 2013/4/26 Matěj Laitl <matej at laitl.cz>:
> > Philipp Schmidt wrote:
> > > While such a daemon will probably not be ready in time for GSoC creating
> > > the Backend in such a way that adding support for synchronous or
> > > preferably asynchronous DBus access would be a very good thing.
> > 
> > I absolutely agree. Even before I knew about this, the plan was to have
> > *all* LIBMTP_*() calls (or rather groups with a handful of libmtp calls)
> > wrapped in ThreadWeaver::Jobs, for technical reasons (some libmtp calls
> > may block for some time -> need to have them threaded -> libmtp doesn't
> > say anything about thread-safety AFAICS -> need to serialize access to it
> > (per device) -> all libmtp calls may then block on lock acquisition ->
> > all libmtp calls must be threaded).
> 
> libmtp has per-device reentrance, so you can make calls to several devices
> as a state struct is instatiated per-device, and the rest of the code should
> be stateless.

Thanks for clearing this up - I assumed this would be the case.

> > One question may come to attentive reader's mind: why the implementation
> > doesn't involve kio-mtp?[6] It is because kio-mtp doesn't use the track
> > libmtp API (rather it uses the file API) - with track API we can query
> > metadata like sample rate or artist without having to download the file
> > at all.
> 
> Actually I've been wondering how the Android MTP stack and the
> Samsung MTP stack handles metadata.
> 
> It seems to me like you can indeed in most cases query tracks for
> metadata over MTP, but when sending metadata it seems to be
> ignored on some devices, and the proper way to get that in place
> is to have tags in the files.

Thanks for the insight. I think we can do it like in iPod collection - when 
metadata should be changed, we update both MTP metadata and actual tags in the 
file. This is easy for tracks newly transferred to the device, a bit more 
tricky for already-on-device tracks. But we can update MTP metadata right away 
and start a download-update-upload background job.

Which leads to a question: I don't see a method in libmtp to "atomically 
replace MTP file identified by this id with these contents". What's the 
recommended approach here? Upload a new file (perhaps with exactly same name, 
which seems to be allowed) and then remove the old file?

On a related note: is there a hope for at least some (Android?) MTP devices to 
support (and update) attributes like Rating, UseCount, SkipCount, 
LastAccessed, EffectiveRating?

Regards,
		Matěj