maemo.org Bugzilla – Bug 1125
osso-media-server dbus api
Last modified: 2009-03-02 13:42:00 UTC
You need to
before you can comment on or make changes to this bug.
Provide a two-way dbus api for osso-media-server. To get things played via the
server, query/set the volume and play status, and also to query what's
Uses would be:
- Common API for all the media/music players that are currently being developed
- A now playing applet in desktop
- A possible audioscrobbler/last.fm plugin to submit what's been playing to web
- Integrate volume control and play/pause with the VoIP client(s) to get the
music to stop, when you get a call.
- Even integrate with a BT profile and get the music to stop when you get a
Quim Gil added to CC-field
Update: As of now, reading media position and current playing media title (not
artist) is possible. But unfortunately that's all.
I wonder how well this enhancement request will be covered by the new Media
Application Framework in Fremantle (open source). We plan to release it
There seems to be some overlapping with Bug 1674 (Allow external programs to
retreive currently playing song information)
Some of the functionality is/could be there, especially for reading status of
the media server, but detailed public documentation is nonexistant.
Now that MAFW is available in Fremantle pre-alpha2 it would be great to get
some updated feedback about what is still needed from your point of view.
Thanks in advance!
(In reply to comment #6)
> Now that MAFW is available in Fremantle pre-alpha2 it would be great to get
> some updated feedback about what is still needed from your point of view.
> Thanks in advance!
FYI: this can be done in MAFW by connecting to the signals emitted by the
renderer (mafw-gst-renderer), all information that gstreamer is able to
extract from the current media is provided to interested applications this way.
So is this a FIXED in Fremantle?
(In reply to comment #8)
> So is this a FIXED in Fremantle?
Yes. Interested applications can:
* connect to the metadata-changed signal emitted by the renderer when
gstreamer extracts metadata information from the item being played. This would
work if applications connect to this signal *before* the information is
extracted by gstreamer, otherwise they will not get any signal.
* The application could also ask for the object identifier of the item being
played in the renderer and then ask MAFW to resolve metadata for that item (for
example using tracker if this media is stored locally). This second approach
would only work if the item has been provided by a mafw-source, not if the item
is a random URI (for example an internet stream opened from a browser),
although the latter case could be implemented as well I guess.