I am currently working on a resume functionality for mopidy, when the power is interrupted or a different album is played in between, intended mainly for audiobooks. For this I need the album, index and current second.
It works fine when playing a MP3 folder or album from Spotify, I can find the folder/album via core.playback.get_current_track. But some “albums” on Spotify are actually just “playlists”. After been added, is there a way to figure out which playlist was added? Currently I only get a different album for every track.
Example: spotify:playlist:37i9dQZF1DXbMYUPb05hjJ
Are there events fired which include the playlist name? Or will the frontend like mpc or iris do individual resolution of each track and add every track manually, so the playlist name is never passed through mopidy?
Hello,
mopidy does not know of the current playlist. I have started implementing such a functionality in the mowecl frontend, but it is still limited:
you have to save the current tracklist manually
only the current track is saved, not the seek time inside the track
I guess 2. should be easy enough to implement. I also have written most of the code to automatically sync the current tracklist/current track with a given bookmark, but I have not enabled it yet.
For now all the logic is handled client side, but it could also be interesting to have a backend extension handle part of it.
As sapristi said, Mopidy doesn’t know this information. The tracklist state consists entirely of tracks. If a playlist added to the tracklist then it’s just used to lookup the tracks that need to be added, then it is discarded. We could look at adding the idea of a current playlist to our internal tracklist state. We’d have to make some decisions about what happens when you start adding extra tracks to a loaded playlist, I guess the current playlist info is erased at this point.
I like the idea, it would help my project: keep the playlist name somewhere and just discard it if the tracklist is changed beyond.
I guess it would require an extension to be more aware when adding something, like when it’s the first or last track of a playlist. Or just send the playlist name along (optional) with every add, that would be even easier.
You’re right, it requires playlists to be a more fundamental part of the API, far more than they are now (pretty much just dumb lists of tracks). It’s a large change so adding the functionality in your web frontend is probably the best choice for now.
To make the functionality reusable across projects, it could be implemented as a backend extension, with the following features:
provide http route to play a given tracklist/playlist, along with syncing the playback state as long as the tracklist does not change
provide an http route to resume a synced tracklist
I think it would be way more usable if it allowed syncing any tracklist, not only playlists. So, from a frontend point of view, you could for example:
have a button to play a given album/playlist/whatever and start syncing
have a button to sync the current tracklist (along with giving a name to the synced “playlist”)
The backend could also provide the saved “playlists” as playlists in mopidy (enabling access through the mopidy core API), although resuming from synced state would require using the extension http API (thus needing a client aware of this specific extension).
The trick to this would be ensuring support for a variety of playlist types and sources. Perhaps a solution (similar to what I devised for Mopidy-Iris) is to have an extra TlTrack variable origin that contains a URI of the resource from which it came. This also serves nicely to support albums and artists as well as playlists.
As far as the resuming, some further thought would be needed especially when a given track URI may appear more than once in its origin. Or when the origin has changed since tracks were added to the queue (ie if a playlist had more tracks added).
So resuming would mean “fetch the tracks from origin, and resume”. This would indeed be nice to support playlists that are subject to change (especially in spotify I guess). But as you say, this could be troublesome.
What I had in mind was simply to store a list of tracks, as well as current index (no more issues, but the source is now static). This also allows a client to add tracks from any source (it just has to collect the track uris beforehand).
I think both views are interesting and can coexist in a single extension without much issue.
I like the line of thought, just have an easy and non-breaking solution working for simple albums and playlists. My resume functionality could then just use the get_current_track album/playlist, index and get_time_position
Frontend:
-user wants to play uri “spotify:playlist:37i9dQZF1DXbMYUPb05hjJ”
-lookup all tracks in backend
-add all tracks to tracklist, each with optional parameter “origin”: “spotify:playlist:37i9dQZF1DXbMYUPb05hjJ”
Mopidy Core:
-have an origin variable for tracklist
-when optional origin is included in add-track do:
#set origin on first add to tracklist
if tracklist is empty:
tracklist.origin = origin
else:
#clear origin when changed
if tracklist.origin != origin:
tracklist.origin = null
-return origin with tracklist and get_current_track
My project is a RFID-based music/audiobook player. Right now it’s running with an external script, I am currently cleaning up the code and trying to make an extension (maybe multiple) out of it.
My script saves position for the playing album every 10 seconds (album/folder, index, sec). When triggered with a RFID card it first checks if it has a saved position for the album and then resumes. If you tap again within 10 seconds it starts from beginning.
