On Thu, Jun 3, 2010 at 2:30 PM, Claudio Saavedra <csaavedra@xxxxxxxxxx> wrote: > On Thu, 2010-06-03 at 12:39 +0300, Felipe Contreras wrote: > >> Ah, I didn't reply: >> >> > 1. No now-playing notification >> >> Not a blocker IMO. > > That's *your* opinion. For me, moving to a library that causes loss of > functionality is a no-go unless there are very good reasons to do it, > which was not the case, IMO. Fine. Take the malevolent dictator approach of maintaining. Have you considered asking your users? For me it's very simple: mafw-lastfm: last.fm: scrobble: yes, now playing: yes libre.fm: scrobble: no, now playing: no maemo-scrobbler: last.fm: scrobble: yes, now playing: no libre.fm: scrobble: yes, now playing: no I think most users would agree that scrobbling is by far #1 use-case of a scrobbler. Moreover, we are talking about a mobile device, that can be disconnected from the Internet a good portion of the day, this whole time "now playing" wouldn't work, and even after connecting to a network, there can be a delay up to 2 hours before the handshake to the service is established. If that was not enough, "now playing" is a feature that users would barely notice (it's just a hint on certain pages of the web interface). So, considering this, first, I would implement network connection detection, and only then "now playing" makes sense. But I don't see from which point of view multi-scrobbling is lower priority than "now playing". >> 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. > > Not really. A very recently scrobbled track will be displayed as "Just > played". The only way to display a track as "now playing" is through the > now playing notification. Right, what a huge loss of functionality. >> > 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. > > Well, it makes a huge difference to know when a problem doesn't exist > anymore. You could have said this back then when I commented it, but it > seems you were expecting me to follow your progress or dig into your > code just because you deserve it. As I already explained many times: THERE IS NO ISSUE; never was. libscrobble works fine in both scrobbling modes; I didn't make any change; the change was done in the client: maemo-scrobbler which is irrelevant for mafw-lastfm. If you had actually read the patches I sent for libscrobble support, you would have seen that. >> > 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. > > But *you* are not the average user, so please excuse me for not > following your needs to set my priorities. After all, you've shown > enough skills to supply for your needs yourself :) So you discriminate certain kinds of users? See http://bugs.libre.fm/wiki/clients, there are many clients that support multi-scrobbling. Certainly they must think that it's important somehow. >> So, mafw-lastfm provides at best 50% of what I need (more like 40%); >> that's not acceptable. > > Not acceptable for *you*. It's perfectly fine if you disagree on what's > necessary or not for a piece of software, just please don't come to me > telling me what I need to focus on just because something doesn't work > as you expect it. It's not about me; you have 0% support for libre.fm users. >> > 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. > > Do you really want to go into this sort of non-constructive debate? I > don't. And I obviously meant that I fixed all issues known. And that no > new issues have arose since then. No, I was just highlighting the possibility that there still are issues there. And to prevent further debate: my best guess is that mafw-lastfm has more bug potential in this area (I would have to re-review the code). Since I know both code-bases, I guess my opinion is worth at least considering, you can disagree, no need to continue arguing. >> > 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. > > That's, once again, *your* opinion. I'll kindly ask you to please stop > pretending I should treat it specially, just because you can write some > code. You want some arguments? 1) The Nokia N900 is a *mobile* device, so there are quite likely many connection options, and chances are very, very high that at least *one* of the connections doesn't need a proxy. The #1 use case is of course scrobbling, and if the user can scrobble when connected to a non-proxied connection, the use case is fulfilled. Therefore, proxy support is not a "must", bit a "would be nice". 2) libre.fm users have currently now way at all to scrobble, not to mention last.fm+libre.fm users. I thought that was obvious, but apparently it's not. So multi-scrobble > proxy. You might disagree, but that's *your* opinion. What about other users? >> > 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. > > Yes, "perhaps" a lot of things. What is your goal with this speculative > arguing? If it wasn't clear: the point is that there are many things that can go wrong in new code. I have been testing persistent storage for several months now without a single problem. The code in libscrobbler is simple and efficient, as it's one of the core features, it would have been very easy for you to collaborate on this, but instead you went for the risky way. >> 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. > > Proxy support is a feature that is not debatable (meaning, no one would > argue whether it's needed or not). I just did. Proxy support is not high priority. > Not scrobbling videos is debatable. > Therefore I decided to implement first what's non debatable, waiting for > more input in other stuff before moving. I think pretty much everyone agrees that last.fm/libre.fm is for music, you are the only one arguing against that. Besides, this feature was no trouble at all (unlike proxy support), that's why I decided to do it right before I released 1.0. >> > 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. > > Well, I didn't look further because features I considered important were > missing, and I said so. If you knew that I was overlooking something you > could have pointed it out. Just staying silent is not gonna make me > realize that I'm missing something. Keep in mind that, in the end, if > you wanted to convince me to use your code you need to make an effort in > communicating as well, not only in coding. No, I'm not interested on convincing you of using my code. I wanted to offer a good solution for all kinds of users (including me), in theory you should be interested in that as well, *your* users were the ones that suggested me to collaborate; the effort was on your side as well. >> Maybe the problem is miss-communication, or whatever > > Yes, I believe the problem is miscommunication, but by now (and I'm also > taking into consideration your reply to Menno Jansz to say this) you're > turning it into a rampage because I didn't do things as you expected. > >> 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 have absolutely no problem with you sharing what you have created with > other people. But if you come to the mailing list of a competing project > and start spreading half-truths about it, start telling its developers > what should they work on, and moreover disrespecting their work, then > don't expect people to be willing to collaborate with you. I hope you > can understand this. Fine. I'll drop the mafw-lastfm mailing list from the CC from now on. Although I don't think that would have changed anything since apart from you, I'm the second biggest contributor, and the only one left is Xavier, which has half my commits. >> > 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. > > For someone who is not showing good manners at all in the way you refer > to others' work, it's a bit surprising that you expect them from others. Perhaps we have a different definition of respect. To me, sending patches to fix problems is a sign of respecting a project. Maybe you took it the other way around. If you think my code is crap: by all means, send me patches to fix it... Why would my sensibilities would be hurt if somebody is improving my code? Anyway, my priorities for next are: network detection, then now playing, then proxy support. I'm not sure how much it will take me, but definitely not five months. Patches are welcome. Cheers. -- Felipe Contreras _______________________________________________ maemo-users mailing list maemo-users@xxxxxxxxx https://lists.maemo.org/mailman/listinfo/maemo-users
