Python3 backend is not returning images #111
Comments
|
The old album image code was removed for Mopidy 3 compatibility in e4efb79 The new method, via a get_images() method of the library provider, is usable but less convenient. It seems to require either a second request to SoundCloud to get info on the track again, or caching. There is already a cache which caches some function results. You're probably not going to get Mopidy API decisions reconsidered by suggesting that here. Edit: Proposed fix at dreamlayers@5320324 |
dreamlayers
added a commit
to dreamlayers/mopidy-soundcloud
that referenced
this issue
Jan 12, 2020
Previously, track images were provided via album images. That is obsolete in Mopidy 3, and was removed in e4efb79. This uses the new LibraryProvider get_images() API to provide images. The same SoundCloud API request used to lookup() a track also provides the image URL. These requests are now cached via _get_track_data(). Like in the previous implementation, user avatar is used if there is no track image.
|
Was there any work on this? |
|
If someone wants to take that proposed fix, give it a test and submit a PR, we can merge it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before Python3, when I searched soundcloud via the MPD interface I would always get an X-AlbumImage field with an image URL that I could display. Since Python3, that field is no longer there.
Images are pretty important for SoundCloud and other backends (eg Youtube) where it's generally not possible to find images online using something like Last.FM or Musicbrainz.
I seem to recall that images were being moved internally to a new API, but I'd like to ask for that decision to be reconsidered, as what was there before worked perfectly.
The text was updated successfully, but these errors were encountered: