[mpris] Playlist extension

[Zeeshan Ali (Khattak)]

On Thu, Nov 4, 2010 at 5:18 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Thu, Nov 4, 2010 at 10:04 AM, Zeeshan Ali (Khattak) <zeenix at gmail.com> wrote:
>> Hi,
>>
>> On Mon, Nov 1, 2010 at 3:53 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
>>> On Monday 01 November 2010 15:35:36 Zeeshan Ali wrote:
>>>>    How about re-using an existing spec for this:
>>>> http://live.gnome.org/Rygel/MediaServer2Spec . This is already
>>>> implemented by gnome-dvb-daemon, pulse-audio (stab Lennart for not
>>>> caring to update to v2), rygel-grilo and rhythmbox. Yes, I know it
>>>> seems very much UPnP-specific but if you read carefully its really
>>>> very generic.
>>>
>>> It could be used, but it is geared towards exposing a media library, with the
>>> associated complexity.  For the use cases we have in mind (geared around
>>> showing a short "example" list of playlists that can be played, and optionally
>>> all the playlsits), it is complete overkill.
>>
>>  Sorry but that is not true. This spec was originally created by
>> Lennart for exposing PulseAudio streams on UPnP network. There are
>> only 2 containers he exposed and each container usually had < 2 items
>> in them. Most of the metadata in the spec is optional so you can have
>> a very simple/slim implementation if that is your need.
>>
>>> There is also the issue of dynamic playlists, for example, which (in Amarok,
>>> at least) don't even have tracks until you start playing them.
>>
>>  Nothing in D-Bus specs stops you from creating D-Bus objects
>> on-demand. Also, you don't need to tie-up the life-cycle of the
>> playlist and its associated D-Bus object.
>>
>>>  Representing
>>> them as a MediaContainer2 would be odd.
>>
>>  I don't know the internals of Amarok to say anything about that so I
>> believe you but IMHO some odd code in one media player would still be
>> better than re-inventing the wheel.
>
> Ok you make a good point. If we can use this API to just show a list
> of playlists without items, then it could be used.

   You could use it for that purpose, yes! But whats the use-case?

> And having less
> D-Bus APIs is a noble goal.
>
> What about an additional method to allow you to pick a playlist to play?

   This is purely for 'serving' media, not playback. MPRIS2 should be
doing that part. We can do it like this:

1. I add another possible value for
'org.gnome.UPnP.MediaObject2.Type': container.playlist

2. MPRIS2 could provide a simple method (PlayContainer) that takes
service name and path of a MediaContainer object and plays all items
under that container.

3. Live happily ever after :)

   #2 doesn't require #1 but I guess it could be useful for UIs to
know if a container is a playlist or not.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

P.S. I'm sorry for the "UPnP" prefix in there. It was supposed to be
removed in v2 of the spec but I somehow forgot to remove it and now I
would hate to modify this spec once more only to solve such a
theoretical issue.