Audio stopped playing after 17.5.1 IOS update

[Levi-Teixeira]

Describe the Bug I have an audio reproduction app and the tracks suddently stoped playing on Ios after the last 17.5.1 update. There are no immediate logs of error concerning the reproduction, but a long time after hitting the play button tho, I get this log on the console: tcp_input [C69.1.1:3] flags=[R] seq=2659539961, ack=0, win=0 state=LAST_ACK rcv_nxt=2659539961, snd_una=2641334348

Is anyone experiencing anything like this? Android works fine.

Steps To Reproduce

1. Open the app
2. Reproduce any kind of audio

Environment Info: "react-native-track-player": "^4.1.1", Error occurs both on the real device and simulator, but sometimes the Iphone 15 Pro Max simulator works fine. IOS 17.5.1

[gmach]

This is a real blocker for our project release. Bumping this up.

[jyeharry]

My workplace is experiencing similar issues with our audio app.

• Audio stops after roughly an hour.
• Only seems to affect iOS.
• Doesn't seem to affect a colleague who's on iOS 17.4.1.

[anthonyhienvu-nine]

I am also experiencing this issue on iPhone SE iOS v17.5.1. Live stream audio automatically stops after roughly an hour. Doesn't seem to affect android or iOS versions less than 17.5.1.

[puckey]

Have any of you made sure this issue is specific to react-native-track-player?

[jyeharry]

I haven’t been able to confirm, I’m still in the process of narrowing it down. But in that process we saw this issue and considering my colleague is on iOS 17.4.1 and is unaffected by the issue we’re experiencing I thought I’d add weight to this theory.

[Levi-Teixeira]

Have any of you made sure this issue is specific to react-native-track-player?

Trust, me. I've done several hours of debbuging and recently I was able to actualy get an error message from await TrackPlayer.getState();

// {"error": {"code": "ios_track_unplayable", "message": "The track could not be played"}, "state": "error"} AND // {"error": {"code": "ios_failed_to_load_resource", "message": "Failed to load resource"}, "state": "error"}

[Levi-Teixeira]

Now, what i've noticed is that although it does works sometimes, the error always happens when the State of the player gets stuck on {"state": "loading"} or {"state": "buffering"} never being {"state": "ready"} unlikely what happens when running the android version of our app.

[gmach]

@Levi-Teixeira Are you playing a HLS livestream ending in .m3u8 also?

[Levi-Teixeira]

@gmach No. Good old .mp3 tracks.

[lovegaoshi]

can u monitor network activity at when error happened? i mean if the audio stops ~1hr it sounds like a background problem? does ios 17.5.1 introduce some kind of background limitation or resource optimization patch in their logs? or if a track consistently stops/errors can u post the link? disclaimer tho i dont use mac/ios at all.

[Levi-Teixeira]

Guys, I don't know if this will apply to everybody but I figured it out what was the issue.

At a high level, it appears that some Apple devices now request media using a byte range request. A typical byte range request will return a 206 Partial Content when this occurs. However, according to the RFC/HTTP spec, a web server can also return a 200 response code to a byte range request as well.

If a file is cached, the web server I was requesting would return a 206. However if a file is not cached, it would sometimes return a 200.

Previously, Apple devices would accept this 200 response without issue. However, it appears that Apple may have changed this in a recent update, and now requires a 206 response when the device makes a byte range requeset.

We updated the web server CDN configuration to support returning 206 responses for files that are not cached.