GSoC Proposal: Statistics synchronization for pluggable devices and Last.fm

[Matěj Laitl]

On 21. 3. 2012 Bart Cerneels wrote:
> On Wed, Mar 21, 2012 at 00:06, Matěj Laitl <matej at laitl.cz> wrote:
> > Project Goals
> > ========
> > This project will implement:
> >  * track statistics synchronization between Amarok collections that
> > support
> > statistics; these are currently Local Collection and iPod Collection, but
> > the framework will be general
> >  * Last.fm scrobbling from pluggable media players that support statistics
> > (iPods, currently) using the general framework from previous point
> >  * ability to synchronize labels from Amarok to Last.fm
> >  * ability to synchronize play counts, first & last played date from
> > Last.fm to Amarok collections (other way around is already implemented by
> > scrobbling) * GUI dialogue for performing the synchronization/resolving
> > conflicts
> > 
> > Implementation
> > =========
> > Speaking about Last.fm integration, Last.fm provides rather nice RESTful
> > API [5] a subset of which is already used through liblastfm [6] library
> > in Amarok to submit (scrobble) currently played songs. I plan to reuse
> > this library and Amarok code dealing with it; the Last.fm API is powerful
> > enough to support all claimed features. There is already even Last.fm
> > on-line service Collection, but it focuses on playing Last.fm radio
> > streams and doesn't handle individual tracks. In order to implement
> > actual synchronization with Last.fm, user's Last.fm Library (that
> > contains relevant track data) can be represented as a new (invisible)
> > Collection or as special case in synchronizer, I have yet to decide this
> > design choice.
> 
> I very much see the need for statistics syncing between iPod and SQL
> and similar. But I strongly object to a Collection for last.fm, even a
> hidden one. It's  corrupting the architecture (Last.fm does not
> provide us distinct playable tracks, hence can not be a real
> Collection) and further complicates the codebase with various special
> cases. We've been suffering a similar mistake with Services already
> and want to avoid making it again at all cost.
> 
> If all you really need for synchronization from last.fm to a
> Collection is metadata and a QueryMaker, I don't see the need for a
> Last.fm Collection, QueryMaker, etc. In order to keep it sane you'll
> have to execute the sync from the last.fm service anyway and have a
> config to select which Collections are synced (SQL as default). From
> SQL to last.fm is already implemented with scrobbling.

When giving it more thought, I must acknowledge that creating a fake 
Collection would be a bad idea. Instead, and thanks to suggestions by Markey, 
Sam & Christoph, Last.fm access could be accomplished through some kind of a 
scrobbling service abstraction, for example:

class ScrobblingService
{
	// mandatory:
	virtual void scrobble( TrackMetaData track, QDateTime time = now() ) = 0;

	// optional, constrained by API Last.fm provides [1] and performace:
	virtual QStringList userArtists();  // ambiguity doesn't matter here
	virtual QMultiMap<TrackMetaData, QDateTime> artistScrobbles( QString artist 
);  // this seems to be the only way to get track first & last played datetime
 
	virtual QStringList trackLabels( TrackMetaData track );
	virtual void setTrackLabels( TreackMetaData track, QStringList labels );

	virtual int trackRating( TrackMetaData track );
	virtual void setTrackRating( TrackMetaData track, int rating );
}

The calls are are possibly long-running, so the interface should be either 
asynchronous (thus more complex) or blocking-but designed to be run from a 
non-gui thread (which I would prefer).

> Very good proposal in any case and I'm confident you can pull it off.

Oh, thanks for review and encouraging! I will update the implementation part 
of the proposal; Also, I will reformulate it a bit to make clear that the 
synchronization with on-line scrobbling services will not be Last.fm-specific. 
(but this GSoC will still implement just the Last.fm backend)

	Matěj

[1] http://www.last.fm/api/intro