TrackPlayer.load(track: Track) causes crash when using a resource object as artwork
Describe the Bug When setting the track artwork using a resource object, the app crashes.
The TrackPlayer.load() method takes a Track object instead of an AddTrack object. The base Track object does not support resource objects for loading artwork, causing the crash.
Steps To Reproduce You can repro the bug by trying to use a react native resource object with the TrackPlayer.load() method when adding a track with artwork.
Code To Reproduce
await TrackPlayer.load({
voiceId: voice.voiceId,
isSampleVoice: true,
url: voice.mediaUrl,
artwork: require('../../../assets/images/icon.png'),
});
Replicable on Example App? Can you replicate this bug in the React Native Track Player Example App? N/A
Environment Info:
Paste the results of npx react-native info
System:
OS: macOS 14.0
CPU: (12) arm64 Apple M2 Pro
Memory: 68.48 MB / 16.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 21.1.0
path: /opt/homebrew/bin/node
Yarn:
version: 1.22.19
path: ~/Workplace/Jellypod/frontend/mobile/node_modules/.bin/yarn
npm:
version: 10.2.0
path: /opt/homebrew/bin/npm
Watchman:
version: 2023.10.09.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.13.0
path: /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 23.0
- iOS 17.0
- macOS 14.0
- tvOS 17.0
- watchOS 10.0
Android SDK: Not Found
IDEs:
Android Studio: Not Found
Xcode:
version: 15.0/15A240d
path: /usr/bin/xcodebuild
Languages:
Java: Not Found
Ruby:
version: 2.6.10
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.72.3
wanted: 0.72.3
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: false
iOS:
hermesEnabled: true
newArchEnabled: false
Paste the exact react-native-track-player version you are using. 4.0.1
Real device? Or simulator?
What OS are you running?
How I can Help What can you do to help resolve this? I can create a fix. Have you investigated the underlying JS or Swift/Android code causing this bug? Yes - provided info in the description. Can you create a Pull Request with a fix? Yes
could u post the error msg? TP.add and load does the same transformation so should work imo
Also having this issue, but only on iOS. Android appears to work fine.
could u post the error msg? TP.add and load does the same transformation so should work imo
Also, when the app is crashing for me, there are no apparent error messages. I don't get an error message in metro and I also do not get an error message when running npx react-native log-ios
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue was closed because it has been stalled for 7 days with no activity.
I can confirm that this bug is still occurring as of version 4.1.1. This usage of load():
const artworkPath = './someArtwork.png';
await TrackPlayer.load({
url,
title: recording.name,
artwork: require(artworkPath),
});
...results in a EXC_CRASH (SIGABRT). This equivalent code:
await TrackPlayer.reset();
await TrackPlayer.add({
url,
title: recording.name,
artwork: require(artworkPath),
});
...works as expected.
@jbrowning I think it's the same issue I had with setQueue and I added this resolveImportedAssetOrPath to fix it in this PR
they had this problem with add as well and they did the same thing to fix
I just tried here and it fixed for me
are you familiar with patch-package?
you can do this
go to the library in node_modules/react-native-track-player/src/trackPlayer.ts and search for the load function, then change to this:
export async function load(track: Track): Promise<number | void> {
const resolvedTrack = {
...track,
url: resolveImportedAssetOrPath(track.url),
artwork: resolveImportedAssetOrPath(track.artwork),
};
return TrackPlayer.load(resolvedTrack);
}
then you need to install patch-package and do a patch to fix in your local react-native-track-player
let me know if this is clear enough