Why Stream Backend returns only one track

General
1

Hi everyone,
is there a reason why Stream Backend returns only the first URI found in external playlist?
I would expect to get all tracks from playlist as for e.g. mopidy-youtube or as Mopidy-M3u does for local m3u playlists.

Is there any plugin returning all tracks from external playlists or should I implement it by myself?

What’s the preferred way? To create new backend plugin or send pull request updating Stream Backend?

Thanks for your answers.

2

is there a reason why Stream Backend returns only the first URI found in external playlist?
I would expect to get all tracks from playlist as for e.g. mopidy-youtube or as Mopidy-M3u does for local m3u playlists.

Because the Stream backend is designed for playing audio streams and (unfortunately) sometimes has to deal with playlist files in order to resolve the URIs for those stream. It is not designed to extract the contents of random playlist files stored on web servers. You give Mopidy-Stream the URI for a stream and it gives you back a single playable Track representing it. When Mopidy-Stream encounters a playlist file it’s always in the context of discovering a playable URI for that stream. The URIs found in any playlist(s) are all considered to provide the same stream (although maybe at different bitrates etc) and there may be multiple layers of nested playlists along the way but it’s only ever interested in the first playable URI, the rest is discarded. Anything it finds that’s either not a playlist or not playable by GStreamer is ignored.

The Stream backend does not implement a PlaylistsProvider like Mopidy-M3U. And Mopidy-M3U does not implement a LibraryProvider. They are designed to solve different problems.

Is there any plugin returning all tracks from external playlists

If you are talking about arbitrary m3u/pls/asx playlist files which are not stored on the local filesystem, then no. If you are talking about m3u playlists found within the configured static playlists_dir (which could be a file share, for example), then Mpoidy-M3U does that; I don’t think that’s what you want but I’m just trying to clarify the current situation.

  • You could technically implement PlaylistsProvider.lookup() for the Mopidy-Stream. This could be made to do what you want except the URIs it returns could be anything; they could be File Spotify, Youtube, etc. URIs. It would work but it makes no sense that this lives in Mopidy-Stream other than because Mopidy-Stream normally handles the ‘http’ protocol.

  • Considering what Mopidy-Stream is specifically designed for, I don’t think changing its LibraryProvider.lookup() to return tracks for all URIs it finds in playlists is what we want.

  • You could implement LibraryProvider.lookup() for Mopidy-M3U but then you are limited to just the m3u format. Note that you’d also have to pass in m3u:http://foo.com/bar.m3u URIs.

Another thing to consider with LibraryProvider.lookup() options is that it might not practically provide what you want as I am not sure how many frontends call it.

If you did create your own backend extension it would need its own URI scheme other than http (since that’s normally used by Mopidy-Stream). If you went with something like playlist: you’d have to pass in URIs of the form playlist:http://foo.com/bar.m3u. Would this backend deal with playlist files accessed over just HTTP or other protocols too e.g. ftp, nfs, webdav etc?

I am not sure exactly what you have in mind and I don’t have a good answer for you but hopefully this explanation helps.

3

Thanks. It helps me understand it a lot.