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

Felipe Contreras felipe.contreras at gmail.com
Mon Jan 4 00:33:54 EET 2010


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.

>>  and I managed
>> to do it once I realized that:
>>  * the credentials file was in the wrong place (and the problem was
>> silently ignored)
>
> This is because at some point we moved the credentials file to ~/.osso/
> without adding any checks to see whether the file is in other location.
> I thought of not doing this simply because mafw-lastfm was still in a
> very early stage when it was done (and still is, of course).

Yeah, but I think it should abort when it doesn't find the
credentials. There's no point in running if it's not going to do
anything.

When I started it manually on my PR device I had to add printfs
everywhere just to find out what was the problem.

Anyway, what's wrong with the fd standard? (.config)

>>  * 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 :)

>>  * If the album field was missing, the track was dropped ("b=(NULL)")
>
> I hadn't seen this, it used to work afair.

Edit the ID3 tags of a clip and remove the album (most of my songs are
this way). It won't be scrobbled properly.

>> Unfortunately by the time I got it somewhat working the code was
>> completely different and I didn't feel it would be easy to make it
>> fulfill my needs.
>>
>> So I wrote a simple library, independent of mafw, which has the features I need:
>
> A bit of background:
>
> By the time I started writing mafw-lastfm, I looked at the alternatives
> to avoid rewriting the audioscrobbler protocol client code, once again.
> Unfortunately, I didn't find anything suitable, and that's the reason
> why the protocol client is implemented in the daemon. Of course, it is
> far from ready -- in its current state is more a proof of concept.
>
> Something like libscrobble is probably what I was looking for, so it's
> good that you started it.
>
>>  * persistent cache
>>  * multi-scrobbling support
>>  * improved error handling
>
> These look like great things to have.
>
>>  * 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.

>> A feature still not there is support for "now playing", which I'm not
>> so interested in, but probably should not be that difficult to add.
>
> This is trivial, so it shouldn't be a problem to add it. The code is
> right there in mafw-lastfm.

Indeed, it's trivial, but I didn't bother to do it.

>> And then I wrote a mafw-scrobbler app so that I could use it on my
>> N900, but it's not exercising all the features of the library yet.
>>
>> I haven't announced this publicly yet, nor is there any proper
>> packaging, or even a README (which will probably include thanks to
>> mafw-lastfm for reference and inspiration). I thought it was better to
>> share this here to see what you guys say.
>>
>> Any thoughts?
>
> I think that:
>
> - having the client side protocol implementation in a library is a great
> idea -- there's no need to have it in the application side. Other
> GNOME/GLib applications will probably benefit from this library.

Exactly. I might end up using it for epris[1] on my desktop ;)

> - quite a lot of people are already using mafw-lastfm. I'd prefer to
> drop the buggy scrobbling client implementation I have and start working
> in libscrobble and migrate mafw-lastfm to use it, than to see another
> identical project rise.

Excellent! If you take a look at mafw-scrobbler you would see that's
not so difficult to do.

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

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

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 :)

Cheers.

[1] http://code.google.com/p/epris/

-- 
Felipe Contreras


More information about the mafw-lastfm-devel mailing list