Handling failing connections

[kevinrenskers]

If you loose network connection mid-stream, audjustable sends AudioPlayerInternalStateError to the delegate. This is perfect, it means I can fall back to other streams.

On the other hand, if you try to connect to a stream while you already don't have network connection (as opposed to loosing it mid-stream) then we do NOT get AudioPlayerInternalStateError, instead we're stuck in AudioPlayerInternalStateWaitingForData forever.

I would guess that connecting to the stream should just fail immediately? And send the appropriate error?

[kevinrenskers]

I've created a sample project showing the problem: https://github.com/kevinrenskers/AudjustableTest

As you can see in the viewcontroller, I have multiple datasources, when a source fails I want to fail over to the next one. When I kill the internet connection while playing datasource one, it doesn't fail over, it doesn't reach the end ("Reached last stream"). Instead it's forever stuck in AudioPlayerInternalStateWaitingForData.

[DarthNerdus]

@kevinrenskers Just curious if you ever devised a workaround to address this?

[kevinrenskers]

Nope :(

[tumtumtum]

Not sure why I didn't notice this issue before. I'll look into it soon.

[tumtumtum]

I believe this is now fixed?

[kevinrenskers]

Not really. I do sometimes get the AudioPlayerErrorDataNotFound when starting a stream when there's no internet, but not always. Sometimes it's still stuck in AudioPlayerInternalStateWaitingForData.

Also, when you loose the internet connection in the middle of the stream, you do get a AudioPlayerInternalStateError (via audioPlayer:internalStateChanged:), but NOT the AudioPlayerErrorDataNotFound (via audioPlayer:didEncounterError:). Not sure why an internal error isn't also made public?

Now my delegate has to implement both methods and listen to both error codes (AudioPlayerInternalStateError and AudioPlayerErrorDataNotFound) and handle fallbacks for both. Strange.

And like I said, the AudioPlayerErrorDataNotFound is not reliable, attempting to start a stream with no internet still often results in the audio player waiting forever.

I've updated the example app to use StreamingKit. If you could just play around with it, kill your internet connection at random times during/before a stream, you'll see the inconsistencies.

[tumtumtum]

Things are a bit complicated because of the async/gapless nature of the player. audioPlayerDidEncounterError is not a great callback because errors need to be associated with a specific queue item. It's currently only used for "critical" errors (like unable to allocate memory for the AudioQueue buffers etc) rather than errors related to playback. I'll have a think about how better to support error conditions.

[kojilab]

Is there a way to see if it's a networking problem using the library or should we just capture the error and then maybe see if there's a connection? Thanks

[alexfoxy]

@tumtumtum Did you work out a way to notify the user that there's no internet connection when they start playback?