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
