Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new playlists API #1075

Merged
merged 12 commits into from
Mar 23, 2015
Merged

Add new playlists API #1075

merged 12 commits into from
Mar 23, 2015

Conversation

jodal
Copy link
Member

@jodal jodal commented Mar 22, 2015

Fixes #1057

@jodal jodal added this to the v1.0 - Audio cleanup 1 milestone Mar 22, 2015
@jodal jodal force-pushed the feature/new-playlists-api branch from 483ddf5 to d37bd62 Compare March 22, 2015 23:44
"""
futures = [
b.playlists.as_list()
for b in self.backends.with_playlists.values()]
results = pykka.get_all(futures)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we bother with catching the potential not implemented exceptions from this in core?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, only M3U and Spotify implement a playlists provider, so for 1.0 migration it's not a huge issue.

More long term, making core more robust to halfdone/stupid/evil backends might be worth doing, but comes further down the list than making core more robust to halfdone/stupid/evil clients.

@adamcik
Copy link
Member

adamcik commented Mar 23, 2015

Not a 100% sure about the names, but I think we need to keep going forward and then have @tkem, @kingosticks and potentially other client authors give this a go to verify if we are on the right track or not.

@tkem
Copy link
Member

tkem commented Mar 23, 2015

@adamcik: agreed ;-)

adamcik added a commit that referenced this pull request Mar 23, 2015
@adamcik adamcik merged commit dd0c86f into mopidy:develop Mar 23, 2015
@jodal jodal removed the 2 - Working label Mar 23, 2015
@jodal jodal deleted the feature/new-playlists-api branch March 23, 2015 21:37
@tkem
Copy link
Member

tkem commented Mar 24, 2015

Doing some initial prototyping for Mopidy-Mobile, I find that I really like playlists.as_list (I was only using the "Ref" part of Playlist anyway, anticipating things to come), but at least for now, I have little use for playlists.get_items. Reasons for the latter are:

a) The mid-term goal is to provide for "real" playlist editing. Now, as long as the "write" part of the playlists API is based on Playlist models, I'll rather get the full Playlists in the first place.

b) Having only Refs makes it somewhat awkward to add playlist items to the tracklist. I can either pass URIs to tracklist.add, or make up Track objects with name and uri.

I guess passing URIs is fine for 99% of all playlist items (and the more sensible thing to do), since metadata will be retrieved using library.lookup or extracted via gstreamer for streams, except for streams or local files (e.g. WAV) that haven't been tagged appropriately. In this case, when converting playlist items to Tracks, you at least have the name property to show up. I also find that for radio streams it takes a while for the tags to be picked up, so the initial/fake name is quite useful.

To handle b) it might also be possible for Mopidy-Mobile to check for stream items based on URI scheme (i.e. "file://", "http://", etc.), and "make up" a Track with URI and name to pass to tracklist.add, and for all other schemes only pass the URI. This also makes me wonder how to handle a future source field for playlist items, at least for M3U...

However, there's no need to delay this any further. Both methods seem to work as expected, I just wanted to share my thoughts on this after some initial "hands-on" experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add new read-only playlist API to core and backend
3 participants