Re: non-free section pointing to PR1.0 repos.
just FYI: Niels has just corrected this issue. It should be pointing to the PR1.2 repos now. Thanks Niels. Regards -krk969 (Ram) - Original Message - From: Robin Burchell Sent: 06/02/10 11:47 PM To: Ram Kurvakat Subject: Re: non-free section pointing to PR1.0 repos. Thanks for sending this Ram. I've been too busy to follow it up since I found out about it. On Wed, Jun 2, 2010 at 11:32 PM, Ram Kurvakat rkma...@gmx.com wrote: Niels, Ive sent you a mail about this already, please ignore it posted it here again so it helps everybody. the non-free section seems to be pointing to PR1.0 repos still. Is this known and somebody already working on it ? Perhaps Ive missed to see a mail or two. Not able to promote anything on this past few days. I presume it's just promotion that is affected, but all the same, it would be nice to have this resolved. (I'd love to not use non-free, but I really don't have the time to learn how to fix my packaging at the moment...) Ram (krk969) Best, Robin Burchell mob: +447702671419 msn: m...@viroteck.net irc: w00t @ irc.freenode.net twr: http://twitter.com/w00teh lac: http://identi.ca/w00t ___ 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
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: Displaying thumbnails in listbox gives garbage value
Hi Daniil, Thanks for the code snippet. It really served my purpose. ___ 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: Qt Autorotation
On Thu, 2010-06-03 at 00:39 +0200, ext Felipe Crochik wrote: Hi, It seems to me that this is an unintended positive side effect instead of a planned requirement. I pass the mainwindow pointer to my dialog constructors and this should set the parent. By reading the documentation setParent should be quite useless in this scenario because I would be changing the parent to the exact same one assigned previously. I believe it just happens to work because setParent will hide the just created dialog and then when you call exec or show it will probably trigger the window manager recognizing this window as part of an autorotation application and adjusting it accordingly. Yes, the WM makes sure that transient dialogs inherit portrait properties from the parent (meaning the window they are transient for). Of course, you could also put the window properties to the dialog window itself to have the same effect with a system-modal (non-transient) dialog. -Kimmo Regardless, it was a good catch. It will probably help saving a bunch of useless lines of code trying to remedy this issue and hopefully on a new release it will be fixed so we don't need to artificially reset the parent to make the manager adjust the window. I would say that it is probably worth reporting this as a bug on the qt/nokia web site. Have you reported it? Thanks for updating us on your findings Felipe -Original Message- From: Stefanos Harhalakis [mailto:v...@v13.gr] Sent: Wednesday, June 02, 2010 6:08 PM To: Felipe Crochik Cc: maemo-developers@maemo.org; Luca Donaggio Subject: Re: Qt Autorotation Hello, On Thursday 27 of May 2010, Felipe Crochik wrote: Luca, I ran into the same issue - the new windows always start on landscape - and used the same workaround - checked the screen resolution and when taller set the portrait attribute. And yes, I believe you are right, setting the I had the same problem but it proved to be my fault. If you are using QDialogs like me then you only have to be sure that you're setting the main window (the one with the portrait mode support) as the parent window. This will give nice portrait support and QDialogs will start in the proper condition. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Autorotation
Hello, On Thursday 03 of June 2010, Kimmo Hämäläinen wrote: Yes, the WM makes sure that transient dialogs inherit portrait properties from the parent (meaning the window they are transient for). Of course, you could also put the window properties to the dialog window itself to have the same effect with a system-modal (non-transient) dialog. I believe you misunderstood the problem: The original problem was that new windows would not respect the current state. If you create a new dialog and set it to auto-rotate, the new dialog will show up in landscape mode even if the display was in portrait mode. It is a common problem that affects pop-up dialogs. It can be bypassed by setting a parent window and Felipe explained why. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Autorotation
On Thu, 2010-06-03 at 14:47 +0200, ext Stefanos Harhalakis wrote: Hello, On Thursday 03 of June 2010, Kimmo Hämäläinen wrote: Yes, the WM makes sure that transient dialogs inherit portrait properties from the parent (meaning the window they are transient for). Of course, you could also put the window properties to the dialog window itself to have the same effect with a system-modal (non-transient) dialog. I believe you misunderstood the problem: The original problem was that new windows would not respect the current state. If you create a new dialog and set it to auto-rotate, the new dialog will show Do you set the rotation property before showing the dialog or after? If you set it before showing it, it sounds like hildon-desktop bug then... up in landscape mode even if the display was in portrait mode. It is a common problem that affects pop-up dialogs. It can be bypassed by setting a parent window and Felipe explained why. There should not be a difference. If there is, it's a bug... -Kimmo ___ 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 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: [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:15 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jun 3, 2010 at 3:57 AM, Kevin Neely ktne...@astroturfgarden.com 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-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
I smell a bug, but dunno where to file it
It's 8:37am here in Kamloops, BC (-8 UTC). My Nokia Messaging is set to download e-mails everyday from 8:00 to 23:59. Yesterday I played a radio station for 1 minute then stopped it and left Media Player there. This morning, before 8:00, I tried to tell Modest to download e-mail even though it was earlier than 8:00 by clicking on the SendReceive, but nothing happened (I guess as expected?). 8:00 passed and no e-mails. Note , however, this is probably not N900 fault as my landlord connection is not working very well with my N900 as after a few minutes I can't browse the web or use Internet (albeit it's connected to his WiFi). So, probably, Modest tried, but couldn't connect (but didn't say anything, it silently failed and even said latest refresh 8:01. Anyway, these are not the issue I wanted to write. I leave home at 8:05 and arrive in the office 10 minutes later (small town :)). I start to work and don't touch the phone. The N900 knows there's a WiFi it can connect to and I told him to check every 30 mins. At 8:37am the N900 plays music... without me telling it anything at all. It just starts playing music. I get hold of it, try to understand from where the music comes from and notice it's Media Player playing the radio station I was playing yesterday. At the same time I see Modest now downloading e-mails and the notifications popping up. I guess, some event must have been fired related to the Internet becoming available and Modest checked it's watch and noticed it's time to download e-mails as I kindly asked it to. But the Media Player? Why it started? Is it a Media Player issue? Should I file this bug under Media Player? or is it more a System bug? -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: I smell a bug, but dunno where to file it
On 3 June 2010 16:46, Aniello Del Sorbo ani...@gmail.com wrote: I guess, some event must have been fired related to the Internet becoming available and Modest checked it's watch and noticed it's time to download e-mails as I kindly asked it to. But the Media Player? Why it started? Is it a Media Player issue? Should I file this bug under Media Player? or is it more a System bug? You really must have Twitter overloaded ;) See my reply: http://twitter.com/adlorenz/status/15333794167 Don't know if that's exactly the case, as this bug is in regards to music resuming after a phone call, but might be related... -- Dawid 'evad' Lorenz * http://adl.pl null://google 'no evil' mail has taken away my random signatures ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: I smell a bug, but dunno where to file it
On 3 June 2010 09:23, Dawid Lorenz a...@adl.pl wrote: On 3 June 2010 16:46, Aniello Del Sorbo ani...@gmail.com wrote: I guess, some event must have been fired related to the Internet becoming available and Modest checked it's watch and noticed it's time to download e-mails as I kindly asked it to. But the Media Player? Why it started? Is it a Media Player issue? Should I file this bug under Media Player? or is it more a System bug? You really must have Twitter overloaded ;) See my reply: http://twitter.com/adlorenz/status/15333794167 Don't know if that's exactly the case, as this bug is in regards to music resuming after a phone call, but might be related... Yeah, weird I didn't get your Tweet ... But it looks different. The cause maybe the same, but mine is surely unrelated to calls. Didn't have any calls for one or two days now.. -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: I smell a bug, but dunno where to file it
On 3 June 2010 09:31, Aniello Del Sorbo ani...@gmail.com wrote: On 3 June 2010 09:23, Dawid Lorenz a...@adl.pl wrote: On 3 June 2010 16:46, Aniello Del Sorbo ani...@gmail.com wrote: I guess, some event must have been fired related to the Internet becoming available and Modest checked it's watch and noticed it's time to download e-mails as I kindly asked it to. But the Media Player? Why it started? Is it a Media Player issue? Should I file this bug under Media Player? or is it more a System bug? You really must have Twitter overloaded ;) See my reply: http://twitter.com/adlorenz/status/15333794167 Don't know if that's exactly the case, as this bug is in regards to music resuming after a phone call, but might be related... Yeah, weird I didn't get your Tweet ... But it looks different. The cause maybe the same, but mine is surely unrelated to calls. Didn't have any calls for one or two days now.. Anyway, filed a bug under Media Player: https://bugs.maemo.org/show_bug.cgi?id=10536 -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo-launcher, Diablo and stderr
Hi, some time ago I activated maemo-launcher in Conboy and just noticed, that on my N810/Diablo device I don't get debug output if I start it from the terminal. If I compile it with deactivated maemo-launcher it will display output inside the terminal. Also the N900/Fremantle version outputs its debug output just fine. Even with enabled maemo-launcher. Does anyone have a clue why that's happening? Or similar experience? Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-launcher, Diablo and stderr
Try launching through maemo-invoker. Regards: Bundyo - Original message - Hi, some time ago I activated maemo-launcher in Conboy and just noticed, that on my N810/Diablo device I don't get debug output if I start it from the terminal. If I compile it with deactivated maemo-launcher it will display output inside the terminal. Also the N900/Fremantle version outputs its debug output just fine. Even with enabled maemo-launcher. Does anyone have a clue why that's happening? Or similar experience? Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-launcher, Diablo and stderr
On Thu, 2010-06-03 at 21:02 +0300, Kamen Bundev wrote: Try launching through maemo-invoker. Thanks, but I do that. /usr/bin/conboy is a soft link to /usr/bin/maemo-invoker. The real binary is /usr/bin/conboy.launch. Or do you mean something else? Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-launcher, Diablo and stderr
Oh, my bad, maemo-summoner was the console output enabled one. Regards: Bundyo On Thu, Jun 3, 2010 at 9:07 PM, Cornelius Hald h...@icandy.de wrote: On Thu, 2010-06-03 at 21:02 +0300, Kamen Bundev wrote: Try launching through maemo-invoker. Thanks, but I do that. /usr/bin/conboy is a soft link to /usr/bin/maemo-invoker. The real binary is /usr/bin/conboy.launch. Or do you mean something else? Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-launcher, Diablo and stderr
Ah brilliant :) maemo-summoner conboy.launch works beautifully. Thanks a lot Kamen! Conny On Thu, 2010-06-03 at 21:11 +0300, Kamen Bundev wrote: Oh, my bad, maemo-summoner was the console output enabled one. Regards: Bundyo On Thu, Jun 3, 2010 at 9:07 PM, Cornelius Hald h...@icandy.de wrote: On Thu, 2010-06-03 at 21:02 +0300, Kamen Bundev wrote: Try launching through maemo-invoker. Thanks, but I do that. /usr/bin/conboy is a soft link to /usr/bin/maemo-invoker. The real binary is /usr/bin/conboy.launch. Or do you mean something else? Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Alternate Line Service (ALS) support
Hey Pekka On Tue, Jun 1, 2010 at 6:13 PM, Pekka Pessi pekka.pe...@nokia.com wrote: On Sun, 2010-05-30 at 14:07 +0200, ext Christopher Intemann wrote: On Fri, May 28, 2010 at 2:05 PM, Pekka Pessi pekka.pe...@nokia.com wrote: You can test what the command dbus-send --system --type=method_call --print-reply=True \ --dest=com.nokia.csd.SS /com/nokia/csd/ss \ com.nokia.csd.SS.CheckDivert string:21 string:89 returns. If it does not return error com.nokia.csd.SS.Error.TeleServiceNotProvisioned: Tele service not provisioned you can try to redirect calls to your line 1 number with command dbus-send --system --type=method_call --print-reply=True \ --dest=com.nokia.csd.SS /com/nokia/csd/ss \ com.nokia.csd.SS.RegisterDivert string:21 string:89 \ string:line1-number-here uint32:0 Wow, thanks, thats at least a beginning! So USSD codes are the only thing that works on line 2, Don't know about USSD - of course you can try dbus-send --system --type=method_call --print-reply=True \ --dest=com.nokia.csd.SS /com/nokia/csd/ss \ com.nokia.csd.SS.USSD.Command string:'*#21**89#' string: and see what you get for response. That does not work. However, it does not seem to work for line 1 either, therefore it might also be a limitation by the provider. Call-UI does not recognize the non-standard basic service number (89) used for ALS, so you can not enter the code directly on call ui. So, if the basic service number was also used as beacon for outgoing line2 calls, would it also be possible to use it in connection with the com.nokia.csd.Call method to invoke outgoing calls on the second line? By the way, how can I unregister/cancel diverts on the second line? There does not seem to be a CancelDivert method, and the method DivertCancel does not accept basic service numbers as arguments (at least, I couldn't figure out how I could assign them). or is there any way to switch to the second line for outgoing calls as well? It would also be great if it was possible to set a different ring tone for incoming line 2 calls... The modem does not support ALS line 2, it would have required special modem firmware. With the current modem firware, you can only divert line 2 calls to line 1. This is a bit weired since most Nokia devices DO support ALS. Is there any good reason for not supplying an ALS-capable firmware? Thanks in advance! Chris ___ 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
