I'd like to play mp3 URLs that does HTTP 302 redirect initially (e.g. for authentication) and then returns the audio file with HTTP 200. I was able to play such URL on Android device, however, I couldn't play it on iOS simulator. I have not tested real iOS device yet. Does TrackPlayer handle redirects of the audio source? I am not able to provide any example URLs at the moment that does a redirect for confidentiality.
I've checked Expo's AV library and that can play such URL on both Android and iOS device, FYI (However, Expo can't play HLS on iOS. They said they'll release it in the next release, though: https://github.com/expo/expo/issues/1187)
I've tested on iPhone 7/iOS 11.2.1 and I confirmed I couldn't play an mp3 file with 302 redirect with TrackPlayer.
Such 300s redirect is common for Brightcove video/audio, for example, and a player needs to be able to handle it to play the audio from the URL.
Looking forward to hearing some updates on this. 300s responses are common with podcasts which may go from one server to another CDN.
I did some testing and I think redirects _are_ working.
We are using SoundCloud hosted MP3s. Typical URI reference is feeds.soundcloud.com/stream/filename.mp3. This redirects to the SoundCloud CDN cf-media.sndcdn.com/hash.
Two things happened for me:
1) I realized that I had not added an App Transport Security Layer Exception Domain for the SoundCloud CDN domain (I had for the main app domain, but not the CDN).
2) I added a mimeType to the track objects when populating Track Player. In the case of MP3 it is audio/mpeg.
After doing both of these things audio successfully plays for me.
I haven't had any issued with 302 redirects. The problem you're probably running into as @callmetwan stated is the App Transport Security policy. If it isn't set to AllowAbitraryLoads iOS will deny the connection.
However, Apple is almost certainly not going to allow your app into the store with AllowAbitraryLoads set to true. So you either need to whitelist specific domains or route your download traffic through an https server.
In addition, I discovered today that ExoPlayer in Android doesnt
automatically redirect HTTP to HTTPS unless you explicitly set it to do so.
I didn鈥檛 have time to explore exactly how to do this but a quick Google
search should give more info.
Redirects from HTTP -> HTTPS or vice-versa are definitely not working on Android. This is a known configuration requirement for ExoPlayer:
https://google.github.io/ExoPlayer/faqs.html#why-do-some-streams-fail-with-http-response-code-301-or-302
I also found a solution explaining what needs to be done and took a stab at it, but I am not a Java developer and think I likely misconfigured something:
https://stackoverflow.com/questions/41517440/exoplayer2-how-can-i-make-a-http-301-redirect-work
@Guichaguri It seems like this is relatively simple to do, what do you think?
Small typo on my part!
I did a bit of testing and verified redirects now work for me!
Pull request opened:
https://github.com/react-native-kit/react-native-track-player/pull/160
Closed by #160
To be clear for the next person that stumbles into this thread I'm specifically talking about iOS as was flagged as the issue in the OP.
I was able to play such URL on Android device, however, I couldn't play it on iOS simulator
Good call @phil-andrews, I'll add my own summary for the next person that has to deal with this.
If you aren't able to get tracks to play and you think it may be related to URLs or redirects, be sure to double check you have added Domain Exceptions correctly in the App Transport Security section of your info.plist. Apple by default only allows iOS devices to make HTTPS requests. If you want to make an HTTP request you have to specifically add a Domain Exception. This StackOverflow post has more info. Note that if the redirect is to a different domain you will need to add an exception for that domain as well (very common when redirecting from a static link to a CDN). Additionally, you may see information on turning App Transport Security off entirely. Apple will reject your app store submission if you do this. Take the time to add the Domain Exceptions!
Track Player has build preferences for Android, allowing it to be configured to use one of two players: the native player or ExoPlayer. The docs have more info on these build preferences. ExoPlayer follows 300 redirects by default except in the case of redirection between HTTP/HTTPS or vice-versa. Pull request #160 resolves this issue, enabling redirects between HTTPS/HTTP automatically. If this issue is still troubling you double check to see if this request made it into master yet (which the repo's NPM module pulls from). If you need this resolved immediately and it isn't in master try pulling from the dev branch, just know that everything in there may not be quite ready for primetime.
Good luck!
Most helpful comment
Good call @phil-andrews, I'll add my own summary for the next person that has to deal with this.
iOS Issue
If you aren't able to get tracks to play and you think it may be related to URLs or redirects, be sure to double check you have added Domain Exceptions correctly in the App Transport Security section of your info.plist. Apple by default only allows iOS devices to make HTTPS requests. If you want to make an HTTP request you have to specifically add a Domain Exception. This StackOverflow post has more info. Note that if the redirect is to a different domain you will need to add an exception for that domain as well (very common when redirecting from a static link to a CDN). Additionally, you may see information on turning App Transport Security off entirely. Apple will reject your app store submission if you do this. Take the time to add the Domain Exceptions!
Android issue
Track Player has build preferences for Android, allowing it to be configured to use one of two players: the native player or ExoPlayer. The docs have more info on these build preferences. ExoPlayer follows 300 redirects by default except in the case of redirection between HTTP/HTTPS or vice-versa. Pull request #160 resolves this issue, enabling redirects between HTTPS/HTTP automatically. If this issue is still troubling you double check to see if this request made it into master yet (which the repo's NPM module pulls from). If you need this resolved immediately and it isn't in master try pulling from the dev branch, just know that everything in there may not be quite ready for primetime.
Good luck!