On Mon, Feb 28, 2011 at 7:15 PM, Zhou, Ting Z <[email protected]> wrote: > Tracker is the store used in meego core for metadata mining and capture. > Unfortunately, some upstream meego netbook applications didn't use tracker. > If you don't need tracker in netbook, the workaround is to backup the > tracker daemon start up files. > su; > mkdir -p ~/backup > mv /etc/xdg/autostart/tracker-* ~/backup > reboot
Since Tracker is part of the 1.2 sharing framework ( http://gitorious.org/meego-sharing-framework ), I do not want to disable it -- I need to figure out how to write apps that work alongside it and other aspects of MeeGo 1.2's infrastructure. It's more likely I'll avoid dependence on banshee, which doesn't seem to fit MeeGo 1.2 and future releases very well; seems more of a holdover from the Moblin and MeeGo 1.0 days. In particular, although highly functional, banshee has significant redundancies and overlaps with 'tracker', and as a result, non-integration with sharing framework; finally the gnome-based interface that will be difficult to rework into a Qt/QML/touch based world. What needs thinking through is why the folllowing tracker-using features are only part of the handset, when a netbook or tablet (or even IVI) will need to "share", index, geolocate, and tag media too, using these same features: https://bugs.meego.com/show_bug.cgi?id=8180 Feature 8180 - [FEA] Share: Web Upload Engine https://bugs.meego.com/show_bug.cgi?id=8181 Feature 8181 - [FEA] Transfer UI: Common transfer management https://bugs.meego.com/show_bug.cgi?id=8179 [FEA] Share UI: Unified entry point to select a destination (note: "The framework of which share-ui is part of is targeting Core. However, it will have extensions for specific UXes.") ((Similar questions arise for other areas such as 'contact management'" http://developer.qt.nokia.com/forums/viewthread/2166 -- "I noticed that the “people” (handset) and the “contacts” (netbook) application store data in different places. The default backend seems to be “tracker” and it did not get data from any of the two applications.")) My main issue with tracker is that it needs to provide a means of controlling when it runs. On the handset, my understanding is that this should be the purview of the "policy framework" -- which again requires some post 1.2-release "integration phase" work to evolve a rule-set to handle such situations. (See http://code.google.com/p/ytd-meego/wiki/CitizenJournalismWithYoutubeDirectForMeego#MeeGo_Policy_Framework ). ... For my media usage, I setup the system MIME types (out of 'nautilus') to send all external media requests to 'smplayer' . Therefore, Banshee only starts (and remains resident until reboot) only if I explicitly want to use it -- but if all I want is to hear or see media associated with a web-link or existing file on the filesystem -- then I don't need banshee, nor do I want it constantly updating itself if other apps manipulate files in the directories it is watching. Now, after installing Qt-based http://smplayer.sourceforge.net/ and http://www.mplayerhq.hu and various free and nonfree codecs from Fedora/RPMFusion, I have a much lighter-weight media player that does exactly what I need -- play all kinds of media commonly found on the internet (AVI/FLV/MP3/M4A etc) as well as playlists (*.pls, *.m3u) of media. Thanks to the presence of http://www.ffmpeg.org/ and libavformat (from RPMFusion Fedora Repo) and additional installation of MeeGo gst-plugins-flumpegdemux package, I can now live-stream any kind of podcast out of gpodder whereas before, if banshee was the media player, it was unable to stream from most sites (MP3 not supported out of box, AVI not supported, FLV not supported, M4A not supported ...) -- all in all, the current solution does not provide a good "out of box" experience for people that just expect things to from the "network" to work on something that presumes to call itself a "netbook". Furthermore, with 'smplayer', I can kill it when I'm done, and start a new one whenever I need it since it's very lightweight and has a narrow focus of being a simple GUI wrapper for the widely used and heavily debugged media player: mplayer . FInally, because the media player is simply an app and not integrated into the desktop or needing to "play music in the background" I don't need to go find some special panel to change songs, alter volume, etc. It's exactly where I'd expect it to be -- the application/window making sound or playing video. And if I want background music then I just move a different window app to the foreground. I know how to navigate to the sound-playing window quickly since it gives me the exact same interface I expect to all my apps. -- and I know what to click to kill the sound in a hurry, turn it down, or cue up a different track. Any inter-app "integration" can be handled via dbus notifications, e.g. to have media player signal the calling app when done, give a current position/cue-point, etc. For example: http://wiki.gpodder.org/wiki/Media_Player_D-Bus_API A more usable result is achieved via a QML front-end to the tracker metadata that's already part of the system infrastructure. Which is exactly what Intel's tablet UX does to creeate a nice "flickable" interface. Between this, and issues with connmand, I'm now beginning to understand why I saw the Handset UX underneath Intel's tablet UX.... Others seem to have repurposed handset media players to the IVI UX -- perhaps something like the following would be a better basis for ongoing Netbook work ? http://meego.gitorious.com/~tripzero/meego-handset-ux/tripzeros-meego-handset-music-ivi or http://gitorious.org/iviapps/ivimusic > As to the problem that banshee doesn't exit once started, it is a design > issue. The concerns may be that we need music played background, and the > startup of banshee is a little time-consuming. But If I use the media player just like any other app on the desktop -- as opposed to something specially integrated into the UX -- then I'm in charge of starting it up, or shutting it down when I'm done with it. It's certainly an acceptable "user model" these days to expect "users" to understand that if a system is running out of resources or acting sluggish, they can kill off apps they're not using. Also people may want to use different players for different media, or have specific players associated with certain kinds of audio hardware. Or have a special "HD audio" player for playing back bluray disks, HD content, or multichannel audio. In my example of plugging in 'smplayer' as MeeGo's media player, I can now use the netbook or an "all in one" for "home entertainment" and be able to playback AC3/DTS multichannel digital sound over SPDIF or over an HDMI audio interface .... That would be quite difficult to configure out of banshee hardwired for analog 2-channel sound via pulseaudio to the default ALSA device. -- Niels http://nielsmayer.com PS: by basing the core playing functionality on open source media player like mplayer and codecs like ffmpeg/libavformat you automatically get support for all the latest and greatest stuff that people just expect to be supported: For example the latest release supports "VP8 decoding, H.264 bug fixes and speedups, unencrypted Blu-ray support. Network streams can now be played through FFmpeg, there has been quite a bit of subtitle work and Ogg and Matroska demuxer defaults were switched to libavformat." _______________________________________________ MeeGo-community mailing list [email protected] http://lists.meego.com/listinfo/meego-community http://wiki.meego.com/Mailing_list_guidelines
