Play and Pause button gets stuck on "buffering/loading" animation.

[nl-danish]

Describe the Bug Whenever i click the Play button on the podcast tracks, the play/pause button placeholders becomes stuck on "buffering," and then unable to resume playing or pause any longer. I have recently migrated to 0.5rc package from 3.2. And, it seemed to be working fine, the same code earlier with using playbackState before i migrated to this version. But, I have no idea what causes this bug now. But, this package also have seem to be solved few of my earlier bugs that i have encountered, so kudos to that.

Steps To Reproduce

1. Click any play button to any podcast tracks
2. It changes the placeholder animation to buffering and gets fixated to the same for every other tracks. (Earlier, it used to go from Play Button > Buffering > Pause Button), from this we can pause and resume the same track again.

Code To Reproduce Not possible to post the whole code here, but here's an example of a snippet from the code if ( playbackState === State.Playing && // episodeId === episodeToPlay && currentTrack && currentTrack.id === episodeId && _allow ) { ref.current.timeStamp = null; isClickLoading = false; isPlaying = true; // isLoading = false; }

Environment Info: npx react-native info : System: OS: macOS 13.3.1 CPU: (8) arm64 Apple M1 Memory: 113.25 MB / 8.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 18.16.0 - /opt/homebrew/opt/node@18/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 9.5.1 - /opt/homebrew/opt/node@18/bin/npm Watchman: 2023.05.22.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.12.1 - /Users/appName/.rvm/gems/ruby-2.7.6/bin/pod SDKs: iOS SDK: Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1 Android SDK: Not Found IDEs: Android Studio: 2022.2 AI-222.4459.24.2221.9971841 Xcode: 14.1/14B47b - /usr/bin/xcodebuild Languages: Java: 11.0.19 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: ^17.0.2 => 17.0.2 react-native: ^0.66.5 => 0.66.5 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found react-native-track-player: "4.0.0-rc05" Real device? Or simulator? Both What OS are you running? For development: Mac. For the bug: Android and Ios, both.

[nl-danish]

Also, i get an error often times whenever i reload or a popup out of nowhere in my simulators, It says such that, `Malformed calls from JS: field sizes are different.

[[165,102,102,104],[26,0,1,2],[[12479,2000,1690285333452,false],[12479],["{"type":"log","level":"log","mode":"BRIDGE","data":["useTrackPlayerEvents","[Invariant Violation: [\"<<NaN>>\",57768,57769] is not usable as a native method argument]"]}",1]],28884]

RCTFatal -[RCTCxxBridge handleError:] __34-[RCTCxxBridge _initializeBridge:]_block_invoke facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1::operator()() const decltype(static_cast<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(fp)()) std::__1::__invoke<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) void std::__1::__invoke_void_return_wrapper<void, true>::__call<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) std::__1::__function::__alloc_func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() std::__1::__function::__func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() std::__1::__function::__value_func<void ()>::operator()() const std::__1::function<void ()>::operator()() const invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK __CFRunLoopDoBlocks __CFRunLoopRun CFRunLoopRunSpecific +[RCTCxxBridge runRunLoop] NSThread__start _pthread_start thread_start `

I'm not sure, if they both are connected or not, so i'm posting this here. I can also post another issue, if they are not connected.

To point out, I have replaced Event.PlaybackTrackChanged with PlaybackActiveTrackChanged, as it was described in the migration documentation.

[dcvz]

@nl-danish is this issue also reproducible for you in the example app?

[nl-danish]

Yes, @dcvz.

[nl-danish]

Is this a common bug that is frequently happening? It has become frequent with a red screen error, since i have updated the package. I'm attaching a screenshot preview of the same, thank you.

https://github.com/doublesymmetry/react-native-track-player/issues/2072#issuecomment-1649676007

[dcvz]

Is this a common bug that is frequently happening? It has become frequent with a red screen error, since i have updated the package. I'm attaching a screenshot preview of the same, thank you.

#2072 (comment)

This typically happens when sending data over the JS bridge that cannot be serialised correctly. My guess would be that one of the imports has perhaps not been migrated correctly. Maybe one of the enums.

[nl-danish]

Thanks for getting back so quick, @dcvz. Really appreciate it.

I have tested and noticed, that it's only popping up after i've changed Event.PlaybackTrackChanged to Event.PlaybackActiveTrackChanged. I'll try to include the snippets from my code form previous change to the recent one regarding this Event for more clarification.

Old Implementation:

useTrackPlayerEvents([Event.PlaybackTrackChanged], async (event) => { try { if (event.type === Event.PlaybackTrackChanged) { await TrackPlayer.getQueue(); const trackIndex = await TrackPlayer.getCurrentTrack(); // get the current id if (+trackIndex !== -1) { await TrackPlayer.getTrack(+trackIndex); await TrackPlayer.getQueue(); const currentTrackIndex = await TrackPlayer.getCurrentTrack();

New Implementation:

useTrackPlayerEvents([Event.PlaybackActiveTrackChanged], async (event) => { try { if (event.type === Event.PlaybackActiveTrackChanged) { await TrackPlayer.getQueue(); const trackIndex = await TrackPlayer.getActiveTrackIndex(); // get the current id if (+trackIndex !== -1) { await TrackPlayer.getTrack(+trackIndex); await TrackPlayer.getQueue(); const currentTrackIndex = await TrackPlayer.getActiveTrackIndex();

[dcvz]

Thanks for getting back so quick, @dcvz. Really appreciate it.

I have tested and noticed, that it's only popping up after i've changed Event.PlaybackTrackChanged to Event.PlaybackActiveTrackChanged. I'll try to include the snippets from my code form previous change to the recent one regarding this Event for more clarification.

Old Implementation:

` useTrackPlayerEvents([Event.PlaybackTrackChanged], async (event) => {

try {

  if (event.type === Event.PlaybackTrackChanged) {

    await TrackPlayer.getQueue();

    const trackIndex = await TrackPlayer.getCurrentTrack(); // get the current id

    if (+trackIndex !== -1) {

      await TrackPlayer.getTrack(+trackIndex);

      await TrackPlayer.getQueue();

      const currentTrackIndex = await TrackPlayer.getCurrentTrack();`

  

New Implementation:

` useTrackPlayerEvents([Event.PlaybackActiveTrackChanged], async (event) => {

try {

  if (event.type === Event.PlaybackActiveTrackChanged) {

    await TrackPlayer.getQueue();

    const trackIndex = await TrackPlayer.getActiveTrackIndex(); // get the current id

    if (+trackIndex !== -1) {

      await TrackPlayer.getTrack(+trackIndex);

      await TrackPlayer.getQueue();

      const currentTrackIndex = await TrackPlayer.getActiveTrackIndex();`      

What does the import for the Event look like?

[nl-danish]

What does the import for the Event look like?

Like this,

import TrackPlayer, { Event, useTrackPlayerEvents, // Capability } from 'react-native-track-player';

[nl-danish]

Hi @dcvz,

Hope you're doing well. Any idea, about how this might be fixed or which version of the package we should migrate too?

Thanks, Danish

[dcvz]

Hi @nl-danish looking over this issue again. There are many users successfully using the example and the latest RC's without encountering this issue. I think it must be an issue with the migration to v4. Have you already gone through: https://rntp.dev/docs/next/v4-migration?

[nl-danish]

Hi @dcvz, Thanks for getting back.

Yes, I have did gone through the v4 documentation, but it seems that the documentation have been updated, from the last time i looked at it. I think, i should try the migration once again freshly while going through the same, and document my changes, so that i'll be also easier to share what changes i've done regarding RNTP package & if the issue still persists.

I'll soon write it here, once i'm done with it.

Thanks again, Danish.

[nl-danish]

Hi @dcvz,

I freshly incorporated the changes from the "Migrating from v3.2 to v4" document on the Friday, and again the issue was still persistent to me, the same one.

We, figured that it might be the issue again with how we were importing things out, so we compared our changes with the example app, but everything seems to be perfectly same, but still we were getting the same old, "Malformed calls from JS: field size are different" error, and this time we also used the latest RC which was 09.

Please let us know, if we're doing something wrong or if there's something we should do more. We've followed the document quite well, and tried this the third time now which a different RC version, but it's still the same issue. Updating to this new update of the package, would really help solve us many of the issues.

Thanks, Danish

[puckey]

Hi @dcvz,

I freshly incorporated the changes from the "Migrating from v3.2 to v4" document on the Friday, and again the issue was still persistent to me, the same one.

We, figured that it might be the issue again with how we were importing things out, so we compared our changes with the example app, but everything seems to be perfectly same, but still we were getting the same old, "Malformed calls from JS: field size are different" error, and this time we also used the latest RC which was 09.

Please let us know, if we're doing something wrong or if there's something we should do more. We've followed the document quite well, and tried this the third time now which a different RC version, but it's still the same issue. Updating to this new update of the package, would really help solve us many of the issues.

Thanks, Danish

The only time I have encountered this Malformed calls from JS: field size are different error has been when I didn't rebuild native when updating RNTP..

[nl-danish]

Hello @puckey,

We made sure that we were rebuilding the native while updating our package, just for a better idea we also cleared out the cache and the storage of every new build before and after updating the package and the new terms, but the error popped up again.

[puckey]

Can you give a full stack trace of the error?

[MTPL0005-AbhishekDube]

I'm also facing the Play and Pause buttons getting stuck on the "buffering/loading" animation on Android 14, although it works perfectly on Android 10. I'm currently using version 3.2.0. I attempted to update the library to version 4.0.1 but encountered the SwiftAudioEx dependency problem.

[nl-danish]

Thanks for bringing it up @MTPL0005-AbhishekDubey,

I missed your comment @puckey, about asking for the stack trace, It's the same error stack as the one from above (this)

Please, let me know if there's more details i could provide for this issue, we're still using the older version of the package, because of this hurdle.

[MTPL0005-AbhishekDube]

@nl-danish I have solved the SwiftAudioEx issue after running pod update SwiftAudioEx. but after updating to 4.0.1. I'm still facing the issue.

[github-actions[bot]]

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.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.