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 wrote: > On Thu, Jun 3, 2010 at 4:10 PM, Felipe Contreras > 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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
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 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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: FINALLY ON MY HANDS !!!
Thanks Paul. Its kind of strange that in Regional Settings it gives the options kind of like Languages. Coming from Ubuntu I was expecting something like South America => Argentina => Buenos Aires. Here is UTC -3. And the only offers for "Latin America" were Some states in Mexico which are all -5 -6 etc. Anyways, Updating now, lets see if I can get the latest kernel and soft. On Thu, Jun 3, 2010 at 7:48 PM, Paul Hartman > wrote: > On Thu, Jun 3, 2010 at 5:23 PM, Francisco Diaz Trepat - gmail > wrote: > > Hello guys: > > Finally I got my N900. > > I have a question on Regional Settings. > > I want my phone in English, but my time-zone/location to be in Argentina, > > where I live currently. > > I couldn't do it yet. Any Ideas? > > Hi Francisco, > > Congratulations and welcome. :) > > In Settings, Lanugage & Region, you can set Language and Regional > settings independently. > > In Settings, Date & Time, if you disable "Update automatically" you > will then be presented with options to set your time zone and > date/time. If you enable "Update automatically" it will use the date > and time from your cellular network provider, I believe. > > Hope that helps & have fun! > ___ > maemo-users mailing list > maemo-users@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-users > ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: FINALLY ON MY HANDS !!!
On Thu, Jun 3, 2010 at 5:23 PM, Francisco Diaz Trepat - gmail wrote: > Hello guys: > Finally I got my N900. > I have a question on Regional Settings. > I want my phone in English, but my time-zone/location to be in Argentina, > where I live currently. > I couldn't do it yet. Any Ideas? Hi Francisco, Congratulations and welcome. :) In Settings, Lanugage & Region, you can set Language and Regional settings independently. In Settings, Date & Time, if you disable "Update automatically" you will then be presented with options to set your time zone and date/time. If you enable "Update automatically" it will use the date and time from your cellular network provider, I believe. Hope that helps & have fun! ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
FINALLY ON MY HANDS !!!
Hello guys: Finally I got my N900. I have a question on Regional Settings. I want my phone in English, but my time-zone/location to be in Argentina, where I live currently. I couldn't do it yet. Any Ideas? Please send me comments on getting good packages. I'am a computer programmer and want to develop all I can in my N900. Cheers, very very happy, f(t) ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Internet packet connection
Hi, Am Donnerstag, den 03.06.2010, 16:52 +0200 schrieb Alejandro López: > some time ago I installed fMMS which created a new internet packet > connection called MMS. Then I removed fMMS but the connection was not > deleted. When I tried to manually remove this connection, I found that > the "Delete" button (I'm guessing the name as I use it in Spanish) is > disabled, so I have no way to remove it. > > Does anybody know how can I remove this unwanted connection? See https://bugs.maemo.org/show_bug.cgi?id=8188#c8 andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Internet packet connection
Hi, some time ago I installed fMMS which created a new internet packet connection called MMS. Then I removed fMMS but the connection was not deleted. When I tried to manually remove this connection, I found that the "Delete" button (I'm guessing the name as I use it in Spanish) is disabled, so I have no way to remove it. Does anybody know how can I remove this unwanted connection? Thanks, Alejandro. ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:15 AM, Felipe Contreras wrote: > On Thu, Jun 3, 2010 at 3:57 AM, Kevin Neely > wrote: >> That sounds great. Is there a place to place a suggestion, other than >> filing a bug? My recommendation would be to also (perhaps optionally) >> ignore podcasts. > > Not really. Perhaps it would make sense to create a mailing list. For > now I think maemo-devel would be ok. Apparently the maemo-scrobbler discussion is hurting the sensibilities of mafw-lastfm developers (whomever they might be). So I've created a new mailing list: https://groups.google.com/group/libscrobbler You are welcome to discuss feature requests there, both for Maemo, and other systems. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
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 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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
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 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 cons
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 comment
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 wrote: > > On Thu, 3 Jun 2010 03:46:25 +0300, Felipe Contreras > 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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
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 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 hold
