Bug 1125 - osso-media-server dbus api
: osso-media-server dbus api
Status: RESOLVED FIXED
Product: Multimedia
MAFW
: unspecified
: All All
: High enhancement with 1 vote (vote)
: 5.0-alpha-pre2
Assigned To: unassigned
: mafw-bugs
:
:
:
: 1649 1674
  Show dependency tree
 
Reported: 2007-03-07 09:55 UTC by Kemal Hadimli
Modified: 2009-03-02 13:42 UTC (History)
5 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Kemal Hadimli (reporter) 2007-03-07 09:55:09 UTC
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 
currently playing.

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 
cellular call.
Comment 1 Jake Kunnari 2007-03-13 11:25:05 UTC
Quim Gil added to CC-field
Comment 2 Kemal Hadimli (reporter) 2007-07-09 03:08:03 UTC
Update: As of now, reading media position and current playing media title (not
artist) is possible. But unfortunately that's all.
Comment 3 Quim Gil nokia 2009-01-08 16:40:44 UTC
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
soon-ish.
Comment 4 Quim Gil nokia 2009-01-08 17:52:16 UTC
There seems to be some overlapping with Bug 1674 (Allow external programs to
retreive currently playing song information)
Comment 5 Kemal Hadimli (reporter) 2009-01-08 18:11:02 UTC
Some of the functionality is/could be there, especially for reading status of
the media server, but detailed public documentation is nonexistant.
Comment 6 Andre Klapper maemo.org 2009-02-13 03:16:19 UTC
Kemal:
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!
Comment 7 Iago Toral 2009-02-13 09:19:29 UTC
(In reply to comment #6)
> Kemal:
> 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.
Comment 8 Quim Gil nokia 2009-02-13 09:28:34 UTC
So is this a FIXED in Fremantle?
Comment 9 Iago Toral 2009-02-13 09:45:28 UTC
(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.
Comment 10 Quim Gil nokia 2009-02-13 09:54:05 UTC
Thanks!