Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Hi Claudio, On Thu, Jun 3, 2010 at 6:48 AM, Claudio Saavedra csaave...@igalia.com 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/77.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/70.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
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 10:55 AM, Menno Jansz me...@jansz.com wrote: On Thu, 3 Jun 2010 03:46:25 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: In other words: maemo-scrobbler Just Works™ ;) mafw-lastfm just works too... Good for you. Perhaps din't noticed the problems fixed in 0.0.5 (Do not lose cached tracks after returning from offline.) and 0.0.6 (Plug a very nasty leak.), or perhaps you just don't care. These problems were never present in maemo-scrobbler, even from Day 1 (before being public), because I decided to start from a platform-independent library that was easy to test without a real client. So I wrote scripts to generate fake playlists and try different scenarios in a systematic manner from my desktop. The testing included memory leaks detection with valgrind, and resource profiling with OProfile. All this things are very difficult/impossible to do when you are working directly on the device through MAFW. Only when libscrobbler was working perfectly from my desktop did I try to write a MAFW client. Initially I tried to improve mfaw-lastfm, but I noticed so many problems that I decided to start from scratch, and soon I had all the functionality I wanted. Whilst it's your prerogative to re-invent the wheel, as a happy user I feel I should point out that it does seem you are belittling Claudio's effort with the tone of your email. I'm not reinventing the wheel. Nobody (including mafw-lastfm) is providing a platform-independent, simple, well-tested, freedesktop-friendly scrobbling library. This library can be used on GNOME, Xfce, Meego, any music player, or an independent D-Bus service. So now that we have such a library, perhaps it would make sense to use it in Maemo? I tried that with mafw-lastfm, didn't stick, so now I'm trying with maemo-scrobbler. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
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. 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. 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. 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, 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. 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. 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. 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? UTF-8 is working fine, since I soup_uri_escape() tracks' data before serializing it. If changes are required to support multiscrobbling, then changes will be made then, I fail to see what's your point here, other than to speculate for the sake of doing it. 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). 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 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
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 2:30 PM, Claudio Saavedra csaave...@igalia.com 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
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 03, 2010 at 04:10:28PM +0300, Felipe Contreras wrote: 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 [...] now playing is a feature that users would barely notice Well, that's a respectable opinion, but I for one consider it one of the most basic features of any Last.fm client. And not that I have anything against Libre.fm (quite the contrary), but I'd say that at this moment it is the lack of Libre.fm support the feature that most users won't notice. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:41 PM, Alberto Garcia agar...@igalia.com wrote: On Thu, Jun 03, 2010 at 04:10:28PM +0300, Felipe Contreras wrote: 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 [...] now playing is a feature that users would barely notice Well, that's a respectable opinion, but I for one consider it one of the most basic features of any Last.fm client. Well, basic, yes, but important? Can you live with the web interface showing just listened vs now playing? Or, what would you rather have a) rock-solid queue handling, or b) support for now-playing? In a mobile device I think a) is more important, but in a desktop I think b) is probably the case. Besides, I believe the best mafw-lastfm can do right now is; if you are disconnected for two hours, when you are connected back, you don't have now-playing until two hours pass. I would not consider that top-notch support for now-playing. So, I don't think loosing that _temporarily_ in favor of a more generic library with other benefits (IMHO better suited for mobile) is a bad trade-off. In any case, I filed an issue for that... you are welcome to vote up: http://github.com/felipec/maemo-scrobbler/issues#issue/1 And not that I have anything against Libre.fm (quite the contrary), but I'd say that at this moment it is the lack of Libre.fm support the feature that most users won't notice. Yes, but we agree that there must be some users out there, right? (otherwise other clients would probably not have implemented multi-scrobbling). Now, would you rather keep a feature that's not essential to the majority of users, and probably quite marginal, than providing support for libre.fm users, who can do nothing at all? IOW; taking a bit from the majority, to give a lot to the minority. I think not doing that is egotistical. Anyway, it's probably not worth discussing more. I decided not to provide now-support and concentrate on multi-scrobbling for v1.0, but I will do so soon. Feedback is appreciated if you feel this is an important feature, specially in the form of votes in the issue tracker. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:10 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 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. In fact, I just released maemo-scrobbler 1.1-1 with all those 3 features: * Add support to detect network connections * Add support for Now-Playing * Add proxy support I tested by setting up a proxy, playing some stuff (now-playing works), then switch to a non-proxied connection, play more stuff (now-playing still works), then go offline, wait a few minutes, go back online, play more stuff (now-playing still works). This is the last one to mafw-lastfm ml... for real :p Enjoy! -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Fri, Jun 4, 2010 at 5:22 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jun 3, 2010 at 4:10 PM, Felipe Contreras felipe.contre...@gmail.com wrote: 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. In fact, I just released maemo-scrobbler 1.1-1 with all those 3 features: * Add support to detect network connections * Add support for Now-Playing * Add proxy support I tested by setting up a proxy, playing some stuff (now-playing works), then switch to a non-proxied connection, play more stuff (now-playing still works), then go offline, wait a few minutes, go back online, play more stuff (now-playing still works). This is the last one to mafw-lastfm ml... for real :p Oh, and I forgot to mention that quite a bit of code chunks come from the work from Claudio. It would have taken me much longer to find all that information myself. Thanks! -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Felipe, Allow me to reply starting from one of your last your statements: 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/77.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. 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. 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). I also implemented support for scrobbling behind proxies[1], which is in a branch in gitorious waiting to get some testing from users. 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]. 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. [...] 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. 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. 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. Claudio [1] https://bugs.maemo.org/show_bug.cgi?id=9966 [2] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-June/000106.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
