Lookup track metadata for MPD load and listplaylistinfo by kingosticks · Pull Request #1621 · mopidy/mopidy

kingosticks · 2017-05-17T17:11:34Z

This is the fix for #1511 that I forgot to submit.

Tests currently fail due to #1619.

adamcik · 2017-06-14T21:06:58Z

mopidy/mpd/protocol/stored_playlists.py


+def _lookup_playlist(context, name):
+    uri = context.lookup_playlist_uri_from_name(name)
+    playlist = uri is not None and context.core.playlists.lookup(uri).get()


Would it be cleaner to spread this across normal ifs statements instead of statement and ...?

I think this is OK and the same line is used throughout the file.

adamcik · 2017-06-14T21:08:39Z

mopidy/mpd/protocol/stored_playlists.py

+        raise exceptions.MpdNoExistError('No such playlist')
+    track_uris = [track.uri for track in playlist.tracks]
+    tracks_map = context.core.library.lookup(uris=track_uris).get()
+    tracks = [track for u in track_uris for track in tracks_map[u]]


Not a huge fan of these nested for loops like this, I tend to get confused about which one is the inner one.

kingosticks · 2017-06-16T00:54:34Z

I'm really glad you prompted to me to take another look at this. I'd managed to mess up load: it didn't need to lookup the tracks since I was already getting that for free with tracklist.add(uris=track_uris). And as part of refactoring everything to use my new _get_playlist helper I discovered a bug and lack of testing in the cases where core.playlists.save fails. I just hacked in a mechanism to force DummyPlaylistsProvider.save to fail (it's late), maybe some mocking is better? I'm all ears to a cleaner solution.

adamcik · 2017-06-24T21:41:57Z

mopidy/mpd/protocol/stored_playlists.py

+    playlist = None
+    uri = context.lookup_playlist_uri_from_name(name)
+    if uri:
+        playlist = context.core.playlists.lookup(uri).get()


Should we be using mopidy.core.PlaylistsController.get_items to reduce how much we lookup?

Feel free to postpone this for this PR.

I'm not doing the full track lookups in here anymore, these are just refs since other than for listplaylistinfo that's all we ever want.

core.playlist.lookup() returns a Playlist object with full Track objects in its Playlist.tracks field. The core playlist API seems to be missing a way to get a playlist Ref with just the name of the playlist other than using core.playlist.as_list() and filtering the returned playlist Refs by URI yourself. We should consider making an equivalent of core.playlist.lookup() to get a playlist Ref.

I see nothing wrong in the implementation of _get_playlist() in this PR. It makes nothing worse and reduces a bunch of duplication. Improving the core playlists API can come later.

👍

I am completely confused regarding my original reply. I have no idea why I thought I was getting Refs from core.PlaylistsController.lookup(). @adamcik your suggestion of core.PlaylistsController.get_items() seems much better and I can only assume that's what I thought I was getting from lookup()! But then that doesn't fit with what I've done here since some of these routines do need the full Track objects and some don't. And this change makes listplaylistinfo lookup the Tracks twice which is a bit weird.

adamcik · 2017-06-24T21:45:08Z

mopidy/mpd/protocol/stored_playlists.py

-
-    with warnings.catch_warnings():
-        warnings.filterwarnings('ignore', 'tracklist.add.*"tracks".*')
-        context.core.tracklist.add(playlist.tracks[playlist_slice]).get()


We might as well keep adding the track ignoring warnings if we are looking up the playlist in a way which gets full tracks. Unless we switch to just getting refs like the comment above mentions.

I don't understand. My track_uris here are Track Refs. Wasn't the intent here to catch deprecation warnings? Which are not longer being emitted since I'm using the uris parameter instead of tracks?

The track variable here is actually full Track objects, but I guess the point of this PR is to do a new lookup of the tracks on load and listplaylistinfo in case the backend doesn't provided complete information in the returned Track objects.

👍

jodal · 2017-06-25T19:33:00Z

mopidy/mpd/protocol/stored_playlists.py

+    uri = context.lookup_playlist_uri_from_name(name)
+    if uri:
+        playlist = context.core.playlists.lookup(uri).get()
+    if must_exist and not playlist:


s/not playlist/playlist is None/, so you don't error on empty playlists (in a future where Playlist might implement a container ABC).

kingosticks · 2018-04-10T19:39:19Z

What can I do to finish this off?

jodal · 2018-04-14T23:04:30Z

tests/mpd/protocol/test_stored_playlists.py

            "dummy:c",
            self.backend.playlists.get_items('dummy:a1').get()[0].uri)

+    def test_playlistmove_save_falis(self):


s/falis/fails/

jodal · 2018-04-14T23:04:41Z

tests/mpd/protocol/test_stored_playlists.py

+        self.assertEqual(1, len(tracks))
+        self.assertEqual('dummy:a', tracks[0].uri)
+        self.assertEqual('Track A', tracks[0].name)
+        self.assertEqual(5000, tracks[0].length)


I'd flip the arguments on the previous four lines.

jodal · 2018-04-14T23:10:39Z

mopidy/mpd/protocol/stored_playlists.py

+    playlist = None
+    uri = context.lookup_playlist_uri_from_name(name)
+    if uri:
+        playlist = context.core.playlists.lookup(uri).get()


core.playlist.lookup() returns a Playlist object with full Track objects in its Playlist.tracks field. The core playlist API seems to be missing a way to get a playlist Ref with just the name of the playlist other than using core.playlist.as_list() and filtering the returned playlist Refs by URI yourself. We should consider making an equivalent of core.playlist.lookup() to get a playlist Ref.

I see nothing wrong in the implementation of _get_playlist() in this PR. It makes nothing worse and reduces a bunch of duplication. Improving the core playlists API can come later.

👍

jodal · 2018-04-14T23:16:51Z

mopidy/mpd/protocol/stored_playlists.py

-
-    with warnings.catch_warnings():
-        warnings.filterwarnings('ignore', 'tracklist.add.*"tracks".*')
-        context.core.tracklist.add(playlist.tracks[playlist_slice]).get()


The track variable here is actually full Track objects, but I guess the point of this PR is to do a new lookup of the tracks on load and listplaylistinfo in case the backend doesn't provided complete information in the returned Track objects.

👍

jodal · 2018-04-14T23:18:06Z

Also, please add a changelog entry.

. Includes tests and refactored all playlist lookups to use helper.

…ilure tests.

kingosticks · 2018-04-15T20:22:57Z

Addressed comments, except the warning thing, I'm not sure what makes sense there.

adamcik approved these changes Jun 14, 2017

View reviewed changes

kingosticks force-pushed the fix/mpd-load-tracklist-metadata branch from a4a1c4f to e23c2e7 Compare June 16, 2017 00:39

adamcik approved these changes Jun 24, 2017

View reviewed changes

jodal reviewed Jun 25, 2017

View reviewed changes

kingosticks mentioned this pull request Sep 13, 2017

No tracklist metadata when using MPD load with M3U playlists #1511

Closed

jodal assigned kingosticks Mar 31, 2018

jodal added A-mpd labels Mar 31, 2018

jodal added this to the v2.2 milestone Apr 9, 2018

jodal approved these changes Apr 14, 2018

View reviewed changes

nsteel and others added 3 commits April 15, 2018 21:19

MPD's load and listplaylistinfo lookup track metadata. Fixes mopidy#1511

52a90a5

. Includes tests and refactored all playlist lookups to use helper.

Updated playlistclear to use playlist lookup helper and added save fa…

627684e

…ilure tests.

Explicitly check for None (core playlists API future proofing).

e87599a

kingosticks force-pushed the fix/mpd-load-tracklist-metadata branch from 08303bf to e87599a Compare April 15, 2018 20:22

jodal merged commit 2cb7993 into mopidy:develop Apr 19, 2018

kingosticks mentioned this pull request May 9, 2018

Mopidy-File: display tag info instead of filename in browsing #1674

Closed

kingosticks mentioned this pull request Jul 20, 2019

Playlists stopped working mopidy/mopidy-spotify#182

Closed

Conversation

kingosticks commented May 17, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kingosticks commented Jun 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kingosticks Jun 27, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jodal Jun 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kingosticks commented Apr 10, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jodal commented Apr 14, 2018

Uh oh!

kingosticks commented Apr 15, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kingosticks commented Jun 16, 2017 •

edited

Loading

kingosticks Jun 27, 2017 •

edited

Loading

jodal Jun 25, 2017 •

edited

Loading