I have discovered the following problem:

• call player.playItem() wait until it is playing

Stopped -> Buffering
Buffering -> Playing

• lock phone
• pause stream Playing -> Paused
• wait some time
• try to play again

Paused -> Playing
Playing -> Buffering

It will stay in buffering, but does not play audio.

I think this is a problem with AVPlayer, because resume() looks like this:

    public func resume() {
        player?.play()
        state = .Playing
    }

player.play() is not enough to recover the stream because I think AVPlayer cuts the connection very fast when the phone is locked. This behaviour does not happen when the phone is not locked.

I realised calling player.playItem() instead of player.resume() does actually work from lockscreen.

I do not know what's the best way to address this issue. The player seems to "realize" that it has to start buffering as it moves into .Buffering immediately. However it does not handle the case that AVPlayer does not actually start playing.

This issue has been observed in a tvOS app, I don't know if it is the case in iOS too.

While playing an audio item you disable the WiFi to test a reconnect scenario, the player's state doesn't change (is still Playing). Therefore, when Reachabilty detects that there is Internet connection again and performs the retrying, the method returns at the beginning, assuming that the audio is still being played.

We were having some issues with the code not seeking exactly when we needed exact seeking (toleranceBefore: kCMTimeZero, toleranceAfter: kCMTimeZero) because the player?.seekToTime(_:toleranceBefore:toleranceAfter:) was hidden away in a few conditional calls and never reached when we needed exact seeking. This appears to fix it while preserving your existing performance enhancements for when exact seeking is not crucial.

Playback is getting paused automatically without any interruptions or any actions. The network connectivity is good and the playback has to be manually resumed by hitting play again.

Observed this happening with recent updates.

I'm not sure if this is issue with the file I have, but I tried to host a MP3 file remotely with all the ID3 information on it. I'm also not sure if I need to do something for the player to pull that information, but I don't see that being pulled and the observer getting fired.

Can you please direct me in right path?

Thanks in advance.

Currently seeking on a livestream crashes playback (nothing to hear anymore, no real code crash) if you seek to a time out of the seekable range. Therefore I added a range check to the seek method call.

I also added seekToLive() and seekToStart() as helpers. They are used by the default seek method if the time to seek to is out of range.

Currently seekToLive() seeks to the latest seekable posistion in the data stream minus 5 seconds of buffer time. The 5 seconds are quite randomly picked and should be changed to a the value of the buffer configuration which might be added in a future release.

I think it is not easy to track audioItem index outside of the AudioPlayer

because you have public function to use the index for removing audioItem, so it is necessary to know the index of the audioItem.

    removeItemAtIndex(index: Int)

so I think the queuedItems should be at least public read from outside. And it is good for developer to show users what items are in the queue.

Thanks!

This fixes #66

• Receiving audio interruptions from un-resumable sources like Spotify and YouTube would leave the player in a very bad state with the pausedForInterruption flag set indefinitely.
• pausedForInterruption is now reset on resume, currentItem set, and on any interruptionEnded callback, whether it has the shouldResume option or not.

@delannoyk this commit I need feedback on, am I correct that the check on pausedForInterruption flag is unnecessary in shouldResumePlaying?

Hi! Playing with a UISlider and the seek to time operation, I thought that having a callback when it has ended was a good idea, and as Apple already provides this functionality in AVPlayer, adding it to AudioPlayer has been easy.

I'm trying to stream audio from a server and your player has been a great blessing in that direction. It used to work great before I tried to implement a singleton. Now, when the singleton works, the player takes a long time to start... say about 30 seconds. I noticed in this duration, the control centre receives audio and stops many times (about 14) before finally deciding to play the audio. So it will start the timeline (only in the control centre) and go up to 4-6 seconds then collapse to 0 only to again repeat this ... till it finally plays.

Is there a solution to this?

This PR is an implementation of what is discussed in #61. The goal here is to define at runtime - and before an item is played - if an AudioItem should be played or not.

This allows the original request to disable remote items when WiFi connection is down, but also allows other use cases.

Here's the todo list:

• [x] Added a delegate method to check if an item is playable or not
• [x] Use that method in AudioItemQueue to return the correct values in nextItem(), hasNextItem, previousItem() and hasPreviousItem.
• [x] Verify the implementation with new unit tests.

Background Task 128 ("Called by KDEAudioPlayer, from $sSo13UIApplicationC19beginBackgroundTask17expirationHandlerSo012UIBackgroundD10IdentifierayycSg_tFTO"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

After playing the last audio, the player goes into Stopped mode and does not turn on anymore. for example, reached the last audio and after the end the last audio will automatically skip to the beginning and if you need to start it again.

How can i do this?