Player becomes unresponsive after failure to play track. about swiftaudio HOT 9 CLOSED

@jorgenhenrichsen, I have taken another stab at this. I think I have resolved the issues with the AVAudioSession.

After the failure happens, the session category needs to be set again for some reason. Otherwise it behaves like it is set to default (i think).

Here is my updated attempt: curiousdustin@6a06eba

This time, I have included modifications to your example app, so you can test it out if you like.

Again, I have not created a PR because I have a hunch there will be a better way to go about this.

from swiftaudio.

Thanks for the detailed report!
Will look into this when I have time ✅

from swiftaudio.

Thanks for implementing a fix! I’ll try to test it out sometime this week. 😁

from swiftaudio.

Also I just realized my quick attempt at a fix seems to break the lock screen controls. So yeah, looking for someone with more knowledge on this to implement a better fix.

from swiftaudio.

The busted lock screen issue appears to be related to the AVAudioSession category getting messed up. I'm not sure if it is something I'm doing wrong, or if the session also needs to be reset somehow when a failure like this occurs.

If I add logging of the category in AVPlayerWrapper like this:

func player(statusDidChange status: AVPlayer.Status) {
	switch status {

	case .readyToPlay:
		print(".readyToPlay category:")
		print(AVAudioSession.sharedInstance().category)
		...
		break

	case .failed:
		print(".failed category:")
		print(AVAudioSession.sharedInstance().category)
		...
		break
	}
}

I get the following output on successful tracks:

.readyToPlay category:
AVAudioSessionCategory(_rawValue: AVAudioSessionCategoryPlayback)

I get this on the failed track:

.readyToPlay category:
2019-04-24 16:38:15.555249-0600 pinna[1152:732947] [avas] AVAudioSessionUtilities.h:112:GetProperty: AudioSessionGetProperty ('acat') failed with error: '!ini'
2019-04-24 16:38:15.555266-0600 pinna[1152:732947] [avas] AVAudioSessionUtilities.h:127:GetProperty_DefaultToZero: AudioSessionGetProperty ('acat') failed with error: '!ini'
2019-04-24 16:38:15.555273-0600 pinna[1152:732947] [avas] AVAudioSession.mm:830:-[AVAudioSession category]: No valid string for category: 0
AVAudioSessionCategory(_rawValue: )
.failed category:
2019-04-24 16:38:15.559898-0600 pinna[1152:732947] [avas] AVAudioSessionUtilities.h:112:GetProperty: AudioSessionGetProperty ('acat') failed with error: '!ini'
2019-04-24 16:38:15.559933-0600 pinna[1152:732947] [avas] AVAudioSessionUtilities.h:127:GetProperty_DefaultToZero: AudioSessionGetProperty ('acat') failed with error: '!ini'
2019-04-24 16:38:15.559951-0600 pinna[1152:732947] [avas] AVAudioSession.mm:830:-[AVAudioSession category]: No valid string for category: 0
AVAudioSessionCategory(_rawValue: )

To confirm, when it fails, it does report the change to both .readyToPlay and then .failed.

from swiftaudio.

The symptoms after this are that locking the device, or backgrounding the app, pause playback. When resuming the app, playback continues. Also the lock screen controls are unresponsive.

So it seems like it is defaulting to a different category.

from swiftaudio.

I tested with your failing track, but it does not fail for me? What it does however is freezing the UI for 10-15 seconds before eventually playing normally, which i suspect comes from the fact that the asset is not loaded async. I will try to play the track on #51 to see if it freezes there as well.
I tried your branch and the track did not fail for me there either, but froze the UI completely for a while before starting playback.

You are correct, the AVPlayer should be switched out after it has failed. I am considering on wether switching out the AVPlayer, or just the whole AVPlayerWrapper is the best approach. I am a bit busy these days, but will eventually come around to these issues.

from swiftaudio.

Are you testing on device? The track eventually plays for me on simulator but fails on device.

Also I did notice that the async related changes in #51 , do make it so that the track does not completely fail. However, as you said, either way, the player DOES need to gracefully recover from a failure IF it does happen somehow.

This ticket is more about recovering from a failure than avoiding this specific failure from this specific track.

from swiftaudio.

Ah, I tested on simulator.
Yeah, I get that it was not about the specific track, but about recovering from failure in general 👍

from swiftaudio.