[Feature] Save the queue on exit
Closed this issue · 4 comments
The Subsonic API has savePlayQueue and loadPlayQueue endpoints, which cause servers to persist the play queue for each user.
It would be useful if, upon exit, stmps called savePlayQueue if the queue is non-empty; and call loadPlayQueue and populate the queue when it starts up. This would allow users to exit stmps and not lose their queue, nor require them to save the queue as a playlist to retain it. I suggest this be an automatic operation, not something users have to remember to do.
The possible objection is if users intentionally maintain different queues on different devices while logged in with the same user IDs. If we do this automatically, exiting stmps would overwrite the users' queues on other devices. My solution to this is to have this be a configurable feature, and have it disabled by default. If the user wants this functionality, they can set "auto_save_queue = true" in the config. We could also consider having periodic automatic saves (every 30s, or whatnot) to rescue queues in case of crashes of the app, or the windowing environment, or the OS. stmps has been remarkably stable, but it might save someone some grief at some point.
Not sure that this is a good idea, after some discussion with the OpenSubsonic API people. If we can't get a way of clearing the saved queue, and if I can't figure out how to get the darned seeking working on initial load, then maybe we label this as "won't fix" and revisit it if things change.
Wow, that's swift! Nice effort getting this fixed!
I'll get it into gonic and then make the changes to this branch. I also think I'll make this feature configurably enabled; do you think it should be disabled by default?
To re-iterate, the stated purpose of the API was to allow users to move between clients without losing their play queue. E.g., I'm listening on stmps on my computer, and switch to Ultrasonic on my phone, and pick up where I left off. I can also see use for it during reboots and such; users can exit stmps and come back to their queue.
However, there are two big "ifs" here:
- Clients have to support
/loadQueue, and I don't have a good idea how common this is. If stmps is one of the few clients that support it, that leaves only the "exit and restart stmps" use case. Is it worth the code just for that? - I really can't get
seek()to work. It works fine when the song is playing, but I suspect it requires mpv to actually start playing (vs, us just sending it the command to start) before it can seek. You can absolutely not seek on a song when libmpv is stopped, and callingplay()and then immediatelyseek()I think is too fast and doesn't let libmpv get into a state where seeking is possible.
The second point really bothers me. I think we're at a point where we have to call play, wait a bit or loop on an IsPlaying() positive response, and then call seek. This would have the consequence of starting stmps automatically playing when started (if there's stuff loaded into the queue); and either we call Stop() immediately after Seek(), and the user gets an audio burp, or we let it run -- neither of which I like. An alternative is some gymnastics where we:
- Load the queue. If there's stuff in it,
- Capture the volume level
- Set the volume level to 0
- Start playing
- Wait until we're sure libmpv is actually playing
- Perform the seek
- Pause the playing
- Restore the audio
And at this point, my whole instinct is to nope out of this feature.
What would save it is if you can find a way to start with an empty queue, put something in it and successfully seek to some point without audio output artifacts, and leave the state in pause. I've been unsuccessful in all my attempts.
Without seeking, the whole "save state and restore" becomes less useful; combined with the question of "how many clients actually implement /loadQueue, and it all feels like bloat. I suppose I could go back to a user-triggered "load-queue-and-play" manual trigger. That'd sidestep all of these issues -- except I still need to figure out how to call play and then immediately seek successfully, but that may be a simple issue of a time.Sleep() to let the scheduler have time to context switch to the libmpv thread to start that.