Expo AV loadAsync never rejects if a file fails to load

[jefflieb-wavy]

Summary

Howdy! I am having the same issue described in #18627. If Audio.Sound's loadAsync method is given a uri for a file which does not exist or can't be played, it never rejects.

I'm only working in iOS, so I'm not sure if this is true for Android or web. I'm seeing it in both sdk version 46 and 47.

I tried the snack in the linked issue, and the reject does not occur on my simulator or when I run through an iOS device in the snack using the Tap to Play. Real devices also have this issue.

What platform(s) does this occur on?

iOS

Environment

  expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 12.6.1
      Shell: 5.8.1 - /bin/zsh
    Binaries:
      Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
      Yarn: 1.22.19 - ~/.nvm/versions/node/v16.18.0/bin/yarn
      npm: 8.19.2 - ~/.nvm/versions/node/v16.18.0/bin/npm
    Managers:
      CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1
    IDEs:
      Android Studio: 2021.3 AI-213.7172.25.2113.9123335
      Xcode: 14.1/14B47b - /usr/bin/xcodebuild
    npmPackages:
      expo: ~47.0.8 => 47.0.8
      react: 18.1.0 => 18.1.0
      react-native: 0.70.5 => 0.70.5
    npmGlobalPackages:
      expo-cli: 6.0.8
    Expo Workflow: managed

Minimal reproducible example

Here's a delicious snack

https://snack.expo.dev/@wavy-jeff/load-ye-a-sound

For another example, here's a public repo

https://github.com/onwavy/sound-loading-example

[RRaideRR]

I'm having a similar issue on my expo-av Video component which I cannot track down. Sometimes, no alert pops up. Like every third or fourth try!

      videoRef.current
        .loadAsync({ uri: cachedVideo.localUri }, { isLooping: true })
        .then((e) => {
          Alert.alert('Not always printed');
        })
        .catch((e) => {
          Alert.alert('Also not always printed', JSON.stringify(e));
        });

[github-actions]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[jefflieb-wavy]

Hi, adding a comment here to prevent the issue from being closed.

[github-actions]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[artsnr1]

It's still there in sdk 49...sigh!! Also if internet connectivity drops it keeps trying to load and never throws an error

[tgeorgiev]

experiencing the same with createAsync and a corrupted audio file. I have the file locally in documentDirectory, I can getInfoAsync and validate it exists, but when I call

console.log('pre create');
await Audio.Sound.createAsync({ uri: uri });`
console.log('post create');

the whole execution stalls and in the console you can see just pre create.

This is reproducible only when using the Expo Go client in an iOS simulated device. On a real device with the Expo Go client it properly throws an error.

Any recommendations to check if a file is play-able before calling createAsync, are appreciated!

[github-actions]

This issue is stale because it has been open for 90 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[jefflieb-wavy]

Hello again bot. This issue is still present in sdk 49 with the latest expo-av version.

[muratak18]

I'm having the same issue.
Expo version 49.
On Android it works as expected. But on IOS it does not throw error.

[squareborg]

Same issue for me,

Users on ios getting app hang as the promise never rejects.

I think in my case the uri points to a file that iOS has made unavailable either through icloud removing the local file or some other feature in ios.

Anyone got any workarounds? Gonna have to see if maybe I can stat the file before loading it

[francescovenica]

what's the file name? I just found out if the file name has spaces it doesn't work...removing the spacing it started to work, maybe is something related to the encoding of the url? replacing the string with encodeURI(audioUrl) fix all my issues

[squareborg]

what's the file name? I just found out if the file name has spaces it doesn't work...removing the spacing it started to work, maybe is something related to the encoding of the url?

Yeah you are getting a succesful load as you fixed your uri, but it should reject if the uri is invalid right, the problem is the promise never rejects just hangs. at least thats what I see, if you hardcode your uri to some incorrect location your promise resolve reject or hang?

[francescovenica]

yeah you are right, it should still throw the error or at least timeout is the url is wrong...I wrote just to give a workaround to who read this post (I've just spent the day on this 😂 )

[squareborg]

Im getting around it with RNFS for now. I'd imagine RNFS.exists would be enough but im not to sure how iOS manages storage if its in icloud, so I went nukelear and made sure I could read the file, was a pretty horrible bug stopping the app launching

try {
    await RNFS.readFile(settings.customMp3Object.fileCopyUri, 'base64');
    await holdSound.current.loadAsync(
        { uri: settings.customMp3Object.fileCopyUri },
        {
            isLooping: true,
            volume: settings.holdMusicVolume
        }
    );
} catch (error) {

[squareborg]

what's the file name? I just found out if the file name has spaces it doesn't work...removing the spacing it started to work, maybe is something related to the encoding of the url? replacing the string with encodeURI(audioUrl) fix all my issues

I just checked, and found out I have the same file name space bug too, Thanks i'll implement your suggestion, Android works fine with spaces

[squareborg]

what's the file name? I just found out if the file name has spaces it doesn't work...removing the spacing it started to work, maybe is something related to the encoding of the url? replacing the string with encodeURI(audioUrl) fix all my issues

I just checked, and found out I have the same file name space bug too, Thanks i'll implement your suggestion, Android works fine with spaces

Okay so of my space in the filename bug, I actuallly needed to use decodeURI for my RNFS (workaround) call and as my URI is alredy encoded by react-native-document-picker I didnt need to encode the uri for the expo-av .loadAsync() call

Seems RNFS doesnt want encoded URI's

[qusaieilouti99]

I can confirm that the issue still exists on SDK 49. It's an unacceptable major bug. Why has it been ignored for over a year? Has anyone found a workaround?

[squareborg]

I can confirm that the issue still exists on SDK 49. It's an unacceptable major bug. Why has it been ignored for over a year? Has anyone found a workaround?

Far from ideal but I had to go with Promise.race():

const res = await Promise.race([
    holdSound.current.loadAsync(
        { uri: filePath },
        {
            isLooping: true,
            volume: settings.holdMusicVolume
        }
    ),
    new Promise((resolve, reject) =>
        setTimeout(() => {
            reject(new Error("timed out"));
        }, 5000)
    )
]);

[qusaieilouti99]

I can confirm that the issue still exists on SDK 49. It's an unacceptable major bug. Why has it been ignored for over a year? Has anyone found a workaround?

Far from ideal but I had to go with Promise.race():

const res = await Promise.race([
    holdSound.current.loadAsync(
        { uri: filePath },
        {
            isLooping: true,
            volume: settings.holdMusicVolume
        }
    ),
    new Promise((resolve, reject) =>
        setTimeout(() => {
            reject(new Error("timed out"));
        }, 5000)
    )
]);

Thank you for your reply, but can't go with this because I'm loading a bunch of audio files simultaneously and this can lead to a lot of timers being added into memory at the same time, I'm in a performance enhancement cycle of my app and this is the last thing I would do

[github-actions]

This issue is stale because it has been open for 90 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[jefflieb-wavy]

Preventing this from closing. Updated the snack to use the latest av version, the issue continues clinging tenaciously to its existence.