Sometimes when I’m not using the app for an extended period of time (like overnight) Android 12 will stop the app (even though I have it set to “Do not optimize”). In that case I usually have to go into last played albums, select the appropriate album, and then hit the resume button. Would it be possible to have a “Resume Queue” button somewhere on the homescreen, possibly at the bottom where the mini-player lives when something is playing?
1 Like
Thinking more about this, I think this would be more generally useful as a “Continue Playlist” row similar to the just introduced “Continue Song Listening” row. “Continue Queue” would then be the first playlist on the list with other recent playlists following it.
You can put the last played row at the top and that albums will always be the first one.
There’s no time when the app is killed to save the queue, the OS system provided does not allow saving infinite data.
So this basically resume as always keep the player state or not, I’ve discussed that in another thread already but due to the nature of Symfonium (multi provider multi player) most of the time the context have changed after the app was killed and restarted, you can be listening your Kodi on your UPnP receiver and restart the app in your car to play local music locally. The previous queue now makes no sense in the new current context and Symfonium can’t know so would try to connect to Kodi and UPnP and if you press play would get tons of errors.
Hi Tolriq,
That boat may have sailed, but after using the app more, I find myself missing this feature quite a lot.
My workflow (no idea how weird or common !) is I’m building “temporary playlist” (i.e. a queue really) of albums based on current mood by adding albums (“add to queue”), and my queue stays on loop for “some time” until I get bored and start the process over again (“play album” to erase the queue, then “add to queue” until satisfied).
I am using that “last album” played as kind of workaround, but it often actually only keeps the actual latest album, and not the whole queue (if Android killed the app, which happens more often that not, despite my best efforts in nursing Samsung settings).
Other workaround would be I guess for me to create an actual “myQueue”, and manually fill it, erase it, re-fill, re-erase, etc. I didn’t play with that enough yet, so not sure how “painful” (it’s all relative obviously) it would be on a daily basis.
I also checked that it seems there’s no option for “Continue Playlist listing” in the Overview interface options, meaning I need to add “Playlists” in the Library tab, and play from there (but it doesn’t seem to keep where I was in my playlist and restarts from 1st track).
Everything related to queue management is done using 1 tap (from album screen), and is really straightforward. Trying to emulate such behaviour by using actual playlists take way more taps, and cannot replicate it exactly.
It seems to me that keeping the “queue” state in app storage, and (re)load it when app reopens would be a fairly clean solution to address this (which I thought was fairly standard feature of music apps). I know you mentioned that you mentioned in another thread why you didn’t want to do that, but couldn’t find that thread, so sorry if I’m beating a dead horse.
Sorry, that’s a long text, and I had a long day at work, so not sure all is clear; if not happy to explain further, just let me know. 
You can add the playlist button as a shortcut button and there should be a resume button on the playlist to resume where you left.
To explain again: The thing is that Symfonium is not a simple local music music player. It’s a multi provider multi players application. So the context have a lot of chance to not match at all when you restart the application. If you are playing some Kodi content on your Chromecast then pause.
When you restart the app on your car connected to Android Auto this won’t really do what you expect, specially if your Kodi content is not available offline and you want to play your local music instead.
There’s also some technical issues due to the fact that Symfonium support complex dynamic playlists containing 100 000 or more songs without issues, but that you can also modify those and then they are not possible to save and restore.
Anyway I still need to think about some possible workaround for the simple cases, but I also need to evaluate the support impact of any non 100% solution.
Thanks for the answer.
Got it for the resume, thanks a lot ! At least I can perform my workflow, even if it takes more taps.
Understood about the context, I think I get it (although my usage is indeed much simpler, so I may not grasp all the subtleties).
So what I understand is that a context is a pair {source, destination}, e.g. {subsonic, chromecast}.
Maybe the queue could be persisted per context, to work across the changes (of context) ?
Then when the app loads, reload the queue for that particular {source, destination}, if it doesn’t exist do nothing, and keep empty queue.
Or perhaps simpler, but maybe less nice for multi context people, when app loads check current context versus last context which was persisted, if same load the queue from persistence, otherwise, do nothing (and leave queue empty).
Not sure if that helps, I imagine you probably don’t need my input to think about such designs, but anyways…
A playlist / queue can have content from multiple different providers so that’s not really a solution.
But it’s frequently requested, so even if I still have no solution for now, I’ll try to provide something at some point to simplify things for the simpler use cases
1 Like
Wow, quick answering ! Sorry, I’m getting to the end of my ideas ! xD
Just to make sure I understand the issue : what you want to avoid is a queue containing songs from source1 (which is only accessible on a given LAN), then user goes out of home, source1 is not accessible anymore, and therefore queue is useless, right ? Then is the issue about UX (why display a queue to interact with which won’t be playable), or actually some other technical issue ?
If this is the issue, I’m guessing playlists would have same issue : if that user manually loads a playlist from source1, while being out of home (to keep this simple stupid example), same thing would happen ?
Could whichever mechanism you applied there to protect from this situation be extended to queue ?
How other applications (different situation than yours, agreed though, as more often than not they are not multi source) deal with such situation is just skip over a song which is not accessible. Which, to be honest, is not great UX, but at least kinda straightforward about what’s happening.
Then there’s the “nuclear” option of when app loads, ping all the sources to see which ones are up, then when reading the queue content from persistence, filter out songs which belong to unreachable sources (can maybe even leave users in control via some small pop up like “last playing queue has 23 / 78 songs which can’t be played”, then few tap button options “clear queue” “remove 23 and play” “keep all”)
Again not sure if that helps, but I’m an IT guy, and design solutions for a living (though not a UX person, and very different domain), so I enjoy proposing stuff, maybe it can help…
It’s UX yes, current queue can be content from 3 media providers playing on Chromecast.
When you connect later your phone to your car in Android Auto trying to play non accessible media to a non accessible player does not really work.
Skipping songs with a queue of 15 000 items if the user press play then forget will just kill the battery. Currently playback stops and queue is cleared after 5 errors it’s a security. But in that case it would kill the user queue before he may have realized that he wanted to keep it for later with no way to save it now.
Removing songs automatically also means that the state that he left is no more the state when he comes back. It’s a half working solution.
Then there’s the case of the guy who want a queue at home and a queue when out of home and all the other cases.
And the main point: the support this triggers when something does not do what the user think it should do.
Playlists are filterable, so if you enable the only connected provider filter, it’s applied to the playlist content.
PS: In my previous life I was system architect, VMware and Citrix certified I have also a few history about IT and designing solutions in other domains 
Agreed, it’s not great. But fact that queue is cleared, well, as it’s not persisted, it would most likely already be cleared anyways.
Can’t agree more with these 2 indeed !
Anyways, thanks for the discussion, hope you manage to find some elegant way to tackle this eventually, but I’ll be using the app nonetheless, it’s really awesome!
And well done on the new life haha
Hello,
Just a bump to say I’m affecting by the same thing. I realize that it’s because it’s a complex player, however I’m only a “basic” user as I only have a local library. But even for this use case, it seems that you offer the most complete package.
I sent earlier two logs (including one that made the app crash, just before or after sending it, I can’t know? Maybe it’s because I turned off debug mode just before sending it?), just in case it’s useful.
I can confirm my queue disappears after a long period of inactivity (e.g. next morning after sleeping) or if I update the app. What’s frustrating is that all my other queues are perfectly saved, it’s the only the current one which is not. Maybe you could add an option for people only having local music, or for people willing to take the “risk”.
Otherwise, I indeed simply resume the album I was playing, which is a decent workaround, although a bit less practical (and not satisfying if my queue consists in more than an album).
I did a screen record of the issue but I don’t think you’ll need it since you’re aware of this behavior.
Don’t disable the option Save Now Playing state and the queue will be saved 
Thanks for your very quick answer, but it is enabled…
Then open a proper issue don’t post in a 2 years old feature request.