[ANN] Scrobbler for Maemo 2.0; now with love support
Hi, It’s time for the second release of scrobbler for Maemo featuring support to mark tracks as “loved”. There have been many improvements over the 1.0 release: * Support to “love” tracks * Detect network connectivity * Proxy support * Support for Now-Playing Also, I had to rename it from maemo-scrobbler to Scrobbler for Maemo due to trademark issues, It’s now pushed to Maemo extras-testing, where you can test and vote up. Grab it while it's hot :) http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/maemo-scrobbler/2.0-1/ All you have to do is add the Hildon Desktop widget next to the media player one (if you want the love functionality). Cheers. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: [ANN] Scrobbler for Maemo 2.0; now with love support
On Mon, Jul 12, 2010 at 4:30 PM, Uwe Kaminski ju...@ju-key.de wrote: thank you very much for your great work! Thanks for the positive feedback :) Am 12.07.2010 11:12, schrieb Felipe Contreras: It’s time for the second release of scrobbler for Maemo featuring support to mark tracks as “loved”. There have been many improvements over the 1.0 release: * Support to “love” tracks hm... AFAIK libre.fm does not support this feature or at least I'm unable to get information about loved tracks in their web interface. Nope, libre.fm's UI doesn't support it, but AFAIK the server is storing the information. Or at least it doesn't complain we send the data. This feature is implemented as desktop widget. I can turn it on and off and I see feedback (background colour is changing) but nothing else. How does it work? When the song finishes (or you click next), the information is submitted (if the button is on), and the button goes back to normal. However, if there's a problem with the connection, then the submission is stored in a queue. When the connection starts working again, all queued loved songs are submitted. * Detect network connectivity * Proxy support * Support for Now-Playing This seems to work well with libre.fm. :) Do you think that it is possible to put these notes to the change log part of the packages? I've put the new features in the special Maemo field, so the notes should be appearing. However, I only mentioned the love feature; not sure if I can put multiple lines there. -- 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 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-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 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
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-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 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-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 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-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 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-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
[ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Hi, maemo-scrobbler is a scrobbler application (last.fm/libre.fm) for the Nokia N900 that listens for events coming from the official media player app through MAFW. You can configure your accounts through the control panel. The inspiration (and some code) comes from mafw-lastfm which does basically the same thing, but lacks some features. For more on mafw-lastfm see below. Compared to mafw-lastfm, maemo-scrobbler has: 1) Support for multi-scrobbling (both last.fm and libre.fm at the same time) Includes a song queue per service. 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. 3) Permanent storage The song queue is not lost, even on crashes, device reboots, or software updates. 4) Video clips are ignored Small feature, but important. In other words: maemo-scrobbler Just Works™ ;) It's now on extras testing, please give it a try and vote up: http://maemo.org/packages/view/maemo-scrobbler/ For more info and the source code, check github: http://wiki.github.com/felipec/maemo-scrobbler/ == mafw-lastfm == 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. 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. 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). Cheers. [1] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-January/26.html [2] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-January/62.html [3] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-February/68.html -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: [mafw-lastfm-devel] mafw-lastfm 0.0.4 (Last.fm scrobbler for the N900)
On Fri, Apr 23, 2010 at 2:24 PM, Dawid Lorenz a...@adl.pl wrote: On 23 April 2010 11:53, Petteri pett...@gmail.com wrote: Cool! Personally I only find one problem; videos are also scrobbled. This is indeed a major drawback. Any changes of dropping video support or at least making it optional? I'd also suggest adding following features: 1) Some sort of indication of (un)successful last.fm account connection within user/pass dialog. 2) Ability to define folders with only music that gets scrobbled. At the moment, podcasts fired off into media player via gPodder are also scrobbled, which isn't ideal. +1 on these two. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: [mafw-lastfm-devel] mafw-lastfm 0.0.4 (Last.fm scrobbler for the N900)
On Mon, Apr 19, 2010 at 3:18 PM, Claudio Saavedra csaave...@igalia.com wrote: mafw-lastfm is a last.fm scrobbler for maemo devices using the Media Application Framework, like the N900. With it, you can scrobble your listening habits to the last.fm Internet radio site. This is the first package[1] I have promoted to extras-testing, since I consider it mature enough for normal users. Please give it a go and vote it accordingly. Cool! Personally I only find one problem; videos are also scrobbled. Also, I wonder what's the plan regarding libscrobbler. Cheers. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: ?Ogg Vorbis support hw-accelerated
On Thu, Feb 11, 2010 at 2:08 PM, Gunter Ohrner g.ohr...@post.rwth-aachen.de wrote: I'll have to check whether ffvorbis is already used in the current ogg- support- or extra-codec-packages available at maemo.org, or does anyone here already know for a chance? Not AFAIK, I think Tuomas wanted a few features in gst-av[1] before going that way. I haven't had time to work on that. [1] http://github.com/felipec/gst-av -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: gst-launch and openmax
On Tue, Jan 26, 2010 at 11:26 PM, Aldon Hynes aldon.hy...@orient-lodge.com wrote: So, I've been reading about a lot of fun things that I could do with my N900, if I can just figure out how... In particular, I'm interested in exploring what I could do with the camera. For example, I would love to set up a script to create high dynamic range (HDR) photographs. It seems like the best way to do this is to write a script that would take three pictures in a row, with exposer setting of +2, 0 and -2. It seems like gstreamer might give me that ability. So, I've started looking at it. However the examples for taking pictures via gstreamer talk about using omx_jpegenc, the OpenMax jpeg encoder. However, I don't have that installed on my N900 and I can't figure out how to get it installed. Is anyone using this that could give me some hints? Beyond that, the idea of Kite Aerial Photography, which also uses gstreamer and omx_jpegenc looks especially interesting. Anyone tried anything like that, or have other interesting photography ideas? omx_jpegenc was dropped in favor of dspjpegenc. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: N900 battery duration
On Wed, Nov 25, 2009 at 6:54 PM, Tuomas Kulve tuo...@kulve.fi wrote: Tuomas Kulve wrote: I repeated three runs with ffvorbis and got a bit over three hours more battery life with the headset connected compared to my earlier ffvorbis tests without the headset. And now I repeated the test runs with Flac. The battery lasted roughly 1.5 hours longer than while playing MP3. Xiph's FLAC decoder? -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: N900 battery duration
On Fri, Oct 16, 2009 at 10:18 PM, Andrea Grandi a.gra...@gmail.com wrote: Hi, 2009/10/16 Andrew Flegg and...@bleb.org: What widgets do you have on the desktop? RSS? Facebook? Foreca? I've Facebook, Calendar, Forecast and two shortcut to start Phone and Contacts. Try removing the third party ones: facebook and forecast. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: videos on n810
On Tue, Mar 10, 2009 at 8:54 PM, Olavo Junior sky...@gmail.com wrote: hi, which video format is better for n810 (avi, mpg, ...) ? I have a N95, but our videos (mpg4) don't play in n810, sound ok, but images is too slow How to I convert .mp4 to maemo better format with linux? All that is explained here: http://maemo.org/development/documentation/manuals/3-x/transcoding_how-to/ -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: New proud owner
On Fri, Feb 13, 2009 at 8:40 PM, Donavyn dona...@gmail.com wrote: Hello everyone, as stated above I'm a new proud owner of a Nokia N810. So as a newbie I have a few questions to ask so please be gentle. =) 1.) How can I change the name of my tablet from its default? I can't remember right now, just browse the option, perhaps bluetooth? 2.) When I am connected to my wireless router at nome, can I access shared directories? For example, I'd love to be able to access multimedia shared on our file server. Yes, the device has samba, so you can see windows shares. 3.) When I receive my SD card in 3-7 days, is there an easy way to move downloaded content to it, and can I easily change 'folders' to access them from the desktop? When you plug the usb cable the device will act as a usb stick, and the mmc would appear as one partition. Cheers. -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Projects Nokia should support (yours?)
On Sat, Nov 1, 2008 at 4:40 AM, Zeeshan Ali (Khattak) [EMAIL PROTECTED] wrote: Hi! On Mon, Oct 27, 2008 at 10:35 AM, Fred [EMAIL PROTECTED] wrote: Would VLC (http://www.videolan.org) be a good client ? There was a port for Maemo but it was underpowered. It has the capacity to be embedded and could be a very good all-purpose (all-codec) media player ... Perhaps this is one of the days when VLC developers regret the decision to not synchronize/collaborate with GStreamer when GStreamer was there? Since Nokia supports GStreamer for very obvious (to the maemo community) reasons, supporting a competitor project wouldn't be a very wise idea. Like supporting both Qt and GTK+? -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
Re: Projects Nokia should support (yours?)
On Sat, Nov 1, 2008 at 10:59 PM, Zeeshan Ali (Khattak) [EMAIL PROTECTED] wrote: Hi! Agreed, we have officially supported GStreamer and the excellent mplayer which can be wrapped if someone wants a (different) gui. VLC certainly doesn't classify as a killer app bearing these in mind IMHO. You missed my entire point. :) mplayer is also a competitor of GStreamer and afaik it is NOT officially supported by Nokia. MPlayer is a great application no doubt but so is VLC (afaik much more portable even) and therefore unfortunately faces the same fate. Something with more mileage, though still not really a killer app, would be working on optimisation of the backend libs that all three media players use (therefore any media player would benefit). But this will have to wait until we see what the hardware is capable of really. Which backend libs all three apps use? I think GStreamer is the perfect backend that all multimedia applications should be using if they are very serious about targeting Maemo. OTOH! I understand their reasons for not going for GStreamer since this will require a huge amount of work and also throwing off a huge amount of investment both MPlayer and VLC have put into their own stacks. GStreamer is not as lightweight as FFmpeg for example. I can see why MPlayer and VLC developers wouldn't want to use it as a backend. As a framework it's great though. The backends that Simon talks about are the ones that most projects share: libmad, libvorbis, x264 (which VLC guys started), etc. But must of the codec support comes from FFmpeg (both gst and vlc use it), and I don't see, for example, GStreamer developers optimizing the codecs for ARM as the FFmpeg guys are doing. But this is of course in the open source arena, when doing products you can't just use FFmpeg due to licensing issues. That's why GStreamer is more attractive to companies since it's extensible and proprietary modules can be developed. Android is following a completely different approach. It's providing the codecs themselves[1] in an Apache licence, so the open source community can compile and improve them, but companies can also include them in their products paying the licence fees, and contribute without granting patents. Also, Google is providing the codecs with OpenMAX IL interface, so GStreamer can already make use of them through gst-openmax [2]. In a similar fashion GStreamer can use proprietary DSP accelerated codecs through the OpenMAX IL interface. Anyway, coming back to the subject; I don't have a media player that suit my needs in the Maemo devices, so VLC looks like a nice alternative. But eventually, as Simon points out, it's more important to work on the backends that the different players can reuse, otherwise performance will be bad. [1] http://android.git.kernel.org/?p=platform/external/opencore.git [2] http://www.freedesktop.org/wiki/GstOpenMAX -- Felipe Contreras ___ maemo-users mailing list maemo-users@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-users
