This wasn’t happening on previous versions, when audio is not playing (paused/stopped) once I slide the player notification to close, it shouldn’t come back again unless after playing an audio again, but the player notification is always returning… I have been forced to kill the application process in order to completely remove it but the issue is always there whenever I use the app again… This is so frustrating… Please fix it
Logs:
Upload description: I think it didn’t asked me a description when uploading the logs
Additional information:
Reproduction steps:
I haven’t found a pattern on when exactly that happens, it seems to be randomly
Not the case, this happens “randomly” even when not having the bluetooth enabled nor having anything plugged to the jack…
Even before replying this, happened again, and I only left a playlist on spotify using the speaker…
I’m pretty sure this wasn’t happening at all on previous versions (and I haven’t received any OS updates), as far as I remember the issue started 2 versions back
Sorry I didn’t specify that before, I just tried to not mention any N previous versions as I’m not 100% sure on how many versions back, I just thought that way you could remember something relevant you could have implemented and that help for you to figure out from there.
The only change I can think of is that the option to save state is now enforced so if the app is killed then started again and you had a queue it’s restored.
So previously if you did not have that option on, there’s nothing restored on app start so no notification.
About the previous versions, I mentioned 2 because I’m taking as reference that I first decided to simply wait for an update to see if you would figure it out by yourself or being reported by someone else, then after noticing a new update and tried it I noticed the issue was still there, what I don’t remember well is if you pushed more than one update in a short period of time before I created my account here and report it, hope this reference helps.
I literally didn’t touch the app when the issue began, so no use at that moment, no queued songs nor a setting change at all, I just updated the app normally and when decided to use it I noticed this issue.
The app is started not by you but the OS, the settings I mention have been removed if you changed it a very long time ago then it’s value can be changed.
So if previously when the app was killed by the OS and you restarted the app there’s was no queue restored and now there is, it’s the reason of the change.
It’s not because of not reading your messages properly but because of a combination of not understanding properly what you refer, and probably a bit of my English comprehension.
Can you please elaborate on that in more technical details?
I know the OS can restart an app but I don’t get why this should be an issue if the app should save a state if the user dismissed/closed the player and wait till an audio is played again to show that player notification again, plus as I said this wasn’t happening before and also I have configured the app to ensure to keep active in background, also there’s no other app from stock or additional setting to kill apps in background, since I have configured my device properly using the dontkillmyapp.com guides.
So if that would be the case the “solution” (more like workaround) would be to restore that configuration, just maybe as an opt-out so other users would still get the current UX of the playback being restored.
However, in any case from a logical and programming perspective and in a general point of view, if you would have a persistent boolean flag that could tell if the player notification was previously closed by the user or not (which would reset to default state to show it as soon as an audio is played), that could be a condition on whether to display the notification on each app restart.
But again, it also sounds weird to me that the actual app is being completely killed by the OS, I just don’t think would be the case because of my settings.
Btw, I only use the app with WebDav, not local music, not sure if that would be relevant for you to figure out what could be happening.
Hmm, that was a disappointing answer for me… Specially since I love this app because from many I tried was the best option for WebDav plus being highly customizable, that’s why I decided to purchase it in first place…
I don’t want to reduce the notification priority, that would impact the proper functionality and my UX.
Basically you are leaving this for me to deal with it somehow…that’s what makes me feel kind od unwell since it was working perfect for me before…
And regarding stopping the playback as you said I don’t even know how to do that, I just see a play/pause control, I don’t see an option to completely stop or clear the playback…
I mean, but in any case it’s something that should be fixed from the app side.
If we would keep logical and really looking to fix the problem, at least we both could tell that the fix should be from the app side, controlling whatever scenario is causing this, simply because the OS can’t be starting this particular app only, in that case the OS would be doing that with the rest as well, and I have others music players which also restores the playback and none of those nor any other app is behaving that way, with this issue, so this really should be fixed from the app side somehow, if other music players handles that in some way, even when the playback is restored this other app can as well.
It’s not something that should be really left to the OS to handle, but to figure out how to make the app more stable by handling those kind of conditions/scenarios.
So my point is that the proper focus/perspective from you as the developer of this app should be on how to avoid this notification to reappear even when the OS restarts the app and playback is being restored (instead of focusing that the solution would be to avoid the app to get restarted), just like every other app I have handles that in some way or another, making those apps stable in that aspect.
Not having that scenario controlled/handled on the app itself, translates on being an unstable app causing that issue and bad UX.
Let me know if you need more logs, but please, please…fix this issue
For the record Symfonium is one of the rare app being up to date on Google recommendations about media playback and restoration and everything.
So despite you not liking this behavior this is the proper one according to the recommendations specially on modern Android.
And yes it’s controlled by the OS because it should to properly handle wearos, Android Auto, …
So I get it your need is important and I should find a workaround to your device starting the app as it seems finding the cause is not the proper solution…
Probably will clear the queue on notification dismiss, but really take time to think about all the users and Android versions.
I understand the app could be using the up-to-date best Google recommendations, but sometimes those given alignments in better recommendations only focus on most modern OS updates/devices, not taking much consideration in other cases, so sometimes for better compatibility is better to have fallback implementations for those other cases.
I really appreciate you will think on the best solution for this issue, thank you, I keep looking forward to next updates, I really love this app and how highly customizable it is.
