Building an audio streaming app using just_audio and audio_service. It uses an HLS url stream to get the audio. When audio is playing and the device is locked the controls will show on the lock screen and work properly using play/pause. However if the audio is paused for around a minute or longer the play button is tapped the lock screen controls will turn grey. I'll then open the app and try tapping play in the view and the Audio processing state will change to idle and nothing else happens.
I'm wonder if it has to do with the HLS stream at all. The amount of time that the player has to be paused before it "breaks" varies, but does seem to be consistent with the amount of audio that has buffered. So play/pause works fine if the amount of time the audio has been paused is less than the buffered amount, but if it passes then I encounter this issue.
As far as I can tell, nothing useful is logged at the time the audio player stops working, nor when tapping play/pause while in this state. I've tried to see if the OS kills the audio player maybe so I could re-init, but that doesn't seem to be the case either.
Figured this out, however, I'm not sure it's best solution.
One part is the provider for our HLS url for the live stream was able to increase the session timeout from 45 seconds to 5 minutes. There doesn't seem to be any negative behavior in doing this. It somehow prevents the background controls from breaking (greying out) when the audio has been paused for more then a minute (this varies and doesn't seem directly related to the session timeout, so maybe some magic iOS is doing too, who knows).
The other part is when a user locks their device and interacts with the background player something breaks to the point where if they go back into the app and try to switch the audio source something fails deep in the audio player. To "fix" this, when switching from the live stream to a non-HLS url I am now calling dispose on the audio player in the handler then re-initializing it.
This has solved my problem, but I think a better solution exists. For my specific case, using the SwitchAudioHandler may be that better solution, but I haven't had the time to try it.