Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Claudio,

On Thu, Jun 3, 2010 at 6:48 AM, Claudio Saavedra <csaavedra@xxxxxxxxxx> wrote:
> On Thu, 2010-06-03 at 03:46 +0300, Felipe Contreras wrote:
>
>> We are now in June and I haven't heard anything.
>
> This is just not true. To your inquire back in April, this is what I
> replied:
>
> https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-April/000077.html
>
> I thought you'd follow up with what I commented as the two main reasons
> why I didn't consider libscrobble at that point yet, but since you
> didn't I just continued fixing issues in my code as time allowed.

Ah, I didn't reply:

> 1. No now-playing notification

Not a blocker IMO. In fact at least last.fm seems to understand just
fine that the last scrobbled song is "Now Playing" due to the
timestamp. So I fail to see what functionality users will miss.

> 2. No scrobbling right after the track has finished.

I'm not sure what that means, but if it's related to the fact that I
decided to scrobble songs each 10 minutes. First, I told you that it's
not a limitation of libscroble, it's up to the client
(maemo-scrobbler/mafw-lastfm) to call sr_session_submit() when it sees
fit[1]. And second, I changed maemo-scrobbled back in January to do
what you wanted[2]. Also, in the pathches for libscrobble I sent I
called sr_session_submit() right after metadata_callback(). Therefore,
as I mentioned, there's no change.

The patch is small, so it's easy to see what's happening:
https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-February/000070.html

So essentially the only drawback was support for "Now Playing", which
is not important to me (if even needed), but it's easy to implement,
you could have done so easily.

>> 1) Support for multi-scrobbling (both last.fm and libre.fm at the same time)
>>    Includes a song queue per service.
>
> I haven't worked on this yet, because I was fixing other issues that
> were more important. I list them below, even when I am sure that you
> know already.

Yes, and I don't agree with the priorities. To me, as a user, I don't
care if I cannot scrobble from certain proxified connections to
last.fm, because even if I do, it would only be to last.fm.

So, mafw-lastfm provides at best 50% of what I need (more like 40%);
that's not acceptable.

>> 2) Improved song queue handling
>>    Since internally it uses libscrobble (which is independent of MAFW),
>>    the important code can be easily tested on desktop sw, and it has
>>    been done so… throughly.
>>    It doesn’t matter how flaky your network is, or that the servers are
>>    down, the songs will be submitted.
>
> I have fixed all the issues with the network handling for at least a
> month now (these were released in 0.0.5).

Well, that's easy to say. I would need to review the code to even be
slightly confident that that's true. And of course, even if I don't
see any problems... that's not a guarantee that _all_ the problems are
fixed.

> I also implemented support for
> scrobbling behind proxies[1], which is in a branch in gitorious waiting
> to get some testing from users.

Yes, as I said before, I don't think that's important.

>> 3) Permanent storage
>>    The song queue is not lost, even on crashes, device reboots, or
>>    software updates.
>
> I have also implemented permanent storage during last week and it's
> working fine. I am planning to do a release including this during this
> week, but I was waiting for some translations to come in first [2].

Perhaps it's working fine, or perhaps it has issues with UTF-8, or
perhaps (quite likely) it's implemented in a non-extensible way which
would require many changes once multi-scrobbling is supported. I can
tell you from experience that the latter is quite likely.

In any case, you _knew_ libscrobbler supported this, and yet, instead
of adding the missing features to libscrobbler, you decided to
implement this yourself.

>> 4) Video clips are ignored
>>    Small feature, but important.
>
> In the same email I link above, I replied to you that I wasn't against
> implementing this if there was broader interest from users. Since I
> didn't get much more feedback on this regard it was low in my
> priorities.

Well, I saw many more users asking for this than proxy support.

>> [...]
>> Then I brought up all the problems to the mailing list [1], and I tried to
>> contribute to mafw-lastfm [2], some trivial patches got in, but the
>> important ones [3] did not. That was back in February, and at that
>> point Claudio (the maintainer) decided to wait until a stable release
>> (0.0.4), which was done in April. We are now in June and I haven't heard
>> anything.
>
> Well, as I said already, I told you clearly what were my concerns
> regarding libscrobble. Instead of following up on the discussion, you
> preferred to go your own way and implement yet another scrobbler. Good
> on you.

I already had implemented my own scrobbler in January. I have waited
and waited in the hopes that we could work together in mafw-lastfm.
Five months holding back my sw is just too much.

>> So I decided to implement the missing pieces and provide what IMO is
>> supperior software (at the very least it does what I need, and hopefully
>> you would like it too).
>
> I don't how to take this. Unfortunately, I was waiting for your feedback
> on my comments. I apologize if you were expecting something different.

Yes, I forgot to reply to your last mail. However, it's clear you
didn't even took a look at libscrobble, as you yourself mentioned, and
as you didn't know   that some drawbacks where not there. It's also
clear to me that you were not seriously considering it since you
started fixing your queue problems (already done in libscrobbler), and
implementing permanent storage. Not to mention the fact that you
didn't reply to my patches to merge libscrobbler, or provide any
feedback at all related to the API or implementation.

Maybe the problem is miss-communication, or whatever, as a user, I
want those features NOW, so I have been running maemo-scrobbler
manually. I don't see why not share it with other people.

> I don't know if it was necessary for you to go your own way and
> implement your own scrobbler, but in the end it's up to you. In a normal
> case I'd be glad to see alternative software, because competition is
> healthy, but in this case I find it a bit ridiculous – it's such a small
> software that it barely makes sense to offer people two different ones
> that in the end will obviously do the same. But that's your way, and
> you're free to do it.

Yes, I agree, it's ridiculous that we can't have a single project.
However, the _only_ problem you have mentioned about maemo-scrobbler
is the lack of "Now Playing" support. I don't think it's important, in
fact I don't think it makes *any* difference, but if you do, you could
have spent a few hours trying to implement it in my libscrobble.
Considering the amount of time I spent in your code, I would have
considered that good manners.

In any case, I'm much happier with the code-base/architecture of
maemo-scrobbler/libscrobbler, so I would rather add the features
mafw-lastfm has that users want (not sure what those are, actually),
rather than try to deal with mafw-lastfm (I believe I did too much of
that already).

Usual disclaimer: I'm don't have any hard feelings, I just like to
express my concerns loudly and clearly.

Cheers.

[1] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-January/000032.html
[2] http://github.com/felipec/maemo-scrobbler/commit/01c91b84c5c13be090b348518ce20461af691578

-- 
Felipe Contreras
_______________________________________________
maemo-users mailing list
maemo-users@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]    

  Powered by Linux