On 29. 4. 2013 Linus Walleij wrote:
> 2013/4/26 Matěj Laitl <ma...@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
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
