elisa-developers team mailing list archive

[Michał Sawicz <michal@xxxxxxxxxx>]

Dnia 2010-02-23, wto o godzinie 00:21 +0100, Olivier Tilloy pisze:
> On this point, I should add that we should be extra careful when 
> designing this playlist thing. A major annoyance to me in most media 
> players is that playlists are flat and contain only one type of media 
> (tracks). Enqueuing a whole album is easy (usually a one-click 
> operation), but if for some reason you decide that you don't want to 
> listen to this album anymore, you have to select all the tracks of
> the 
> album to remove them from the playlist. That's of course very tied to 
> the way I listen to music (by albums, very rarely by isolated
> tracks). 
> Albums (and similarly TV show seasons and photo albums) should be 
> first-class citizens in a playlist. That's especially important if we 
> are to provide a powerful playlist system to be used easily with a 
> remote control. 

Yes! I'm all for that. Also, we need a way to have a list of
alternatives (i.e. radio streams do that) that will be tried in sequence
and only one of them will play.

Also, as I mentioned somewhere before, there should only be one player,
that would behave differently based on type of the media played. No more
player_{audio,video,picture,...} please. We need to be able to have
mixed playlists.

And the player needs to try and parse any playlist that comes its way. I
think intercepting any "can't play text/html" errors from gstreamer,
getting the data and adding a 'children' entries to current playlist
would be a way to go.

-- 
Cheers
Michał (Saviq) Sawicz

Attachment: signature.asc
Description: To jest część wiadomości podpisana cyfrowo