[mafw-lastfm-devel] New projects: libscrobble and mafw-scrobbler

Claudio Saavedra csaavedra at igalia.com
Mon Jan 4 08:05:11 EET 2010


El lun, 04-01-2010 a las 00:33 +0200, Felipe Contreras escribió:
> On Sun, Jan 3, 2010 at 11:40 PM, Claudio Saavedra <csaavedra at igalia.com> wrote:
> > El dom, 03-01-2010 a las 02:53 +0200, Felipe Contreras escribió:
> >> I spend a lot of time trying to get mafw-lastfm working,
> >
> > It's a pity you spent so much time. You could have contacted me any
> > time..
> 
> By a lot of time I meant more than one full day. Considering it was
> supposed to be working for end-users, to me that's a lot of time.

I wouldn't consider it ready for end-users, that's why it's in
extras-devel only :)

> 
> >>  and I managed
> >> to do it once I realized that:
> >>  * the credentials file was in the wrong place (and the problem was
> >> silently ignored)
> >
> Anyway, what's wrong with the fd standard? (.config)

As you probably know, anything inside ~/.osso will be backed up and
restored by the backup application for free. That's the main reason to
have moved it there -- allowing users to back up their credentials when
backing up the device settings.

> 
> >>  * mafw wasn't setting the duration properly (I had to do it with
> >> "metadata-changed")
> >
> > This is a known bug in mafw that was fixed and released in the firmware
> > that Nokia included with the N900. Some other (even later) versions of
> > mafw are affected though (nb-143299, if you know what I mean).
> 
> I see. I worry that we would be depending on certain mafw versions
> because of this silly bug. So I think we should rely on the API that
> we know has always been working correctly (the one MP uses). That's
> what I do on mafw-scrobbler and the code is actually simpler :)

I don't really know what MP does, since it's proprietary, but it's good
to know that there's a different way to make it work.

> >>  * playback independent (submit songs each 10 minutes)
> >
> > I am not so sure about this. A lot of people (me included) want to see
> > their scrobbles happening immediately as the song finishes playing, and
> > not being flushed at fixed intervals.
> 
> That is a feature of the library. It doesn't mean the client *has* to
> submit them at that interval... the client can choose 10 seconds, or
> the full track length if it so wishes.

Does this mean that it always set a timeout? I think this is not such a
great idea (the less timeouts, the better for battery life).  I have
code in my local repository that removes this timeout and simply
"flushes" the scrobbling queue on track change. In practice, this means
that the previously played song is scrobbled when the next track starts
playing, together with any other tracks that, for whatever reason, were
not scrobbled previously.

I haven't committed this yet, because I haven't been doing much in the
code since mafw broke on me (out of frustration with Nokia), and wanted
to test it a bit more before.

> > - from your description, the only concern I have is about the fixed
> > intervals scrobble flushing. If we can instead allow for immediate
> > scrobbling, then I'd say that libscrobble is the way to go.
> 
> I don't really care much, I just know that battery life depends a lot
> on how much you use the network, so I designed the library to allow
> different intervals without hassle.
> 
> In practice however, I notice a lot of BADSESSION from the server,
> even when I use 1 min intervals... maybe they expect clients to send
> the scrobbles after each song... or maybe BADSESSION just happens a
> lot regardless.

afair, there shouldn't be much BADSESSION's at all, unless you are
scrobbling with another player at the same time. Sending the tracks each
10 minutes shouldn't be a reason for a BADSESSION.


> 
> > - As someone else already said, having two scrobblers available for any
> > maemo device is going to create more confusion than anything. I'd really
> > prefer to work together on offering one good alternative.
> 
> I agree, which is the reason I sent this mail :)
> 
> I prefer the name mafw-scrobbler because some people might use it for
> libre.fm instead. But I don't really care much.

Me neither. If there's a sane migration path we can rename mafw-lastfm
to mafw-scrobbler. Not sure how to proceed with the mailing list, the
archives and the garage project. Everything else should be simple to do.

> 
> I hope you find some time to check libscrobbler and reply with your
> comments. The whole thing (libscrobbler+mafw-scrobbler) is 830 lines
> of code so shouldn't be a big burden :)

Sure, I'll look at it when I find some time.

Claudio


More information about the mafw-lastfm-devel mailing list