Project dead?

[Thijmen]

Hi there,

Is this project still maintained? There are quite some interesting PR's open, such as #2565 for Android.

If it's not maintained anymore, is there anyone who would take a fork?

[Thijmen]

@dcvz if you need help - I am more than happy to help out. I think there are some PR's that deserve some attention, let's go for a new beta?

[c-goettert]

I am wondering the same.. currently using the 5.0.0 alpha but I don't know if it ever will be released. Anyone knows some non-expo alternatives?

[Thijmen]

I've reached out to the maintainer by email and offered my help. Let's see where this gets us.

[bitcrumb]

Also interested in getting some more traction here!

There is actually quite a bit of bugs that would require attention and have (confirmed) fixes. Would be nice to have this in an official v5.0.0.

In fact I just opened a new bugfix myself:
#2589

[bitcrumb]

I took the liberty to use some AI ✨ to generate an overview:

Bug Report Summary: v5.0.0-alpha0 open fix PRs

A review of open pull requests against 5.0.0-alpha0 identified the following confirmed bugs with pending fixes. All referenced PRs remain unmerged.

---

🤖 Android

1. NEXT and PREVIOUS notification buttons swapped

Affected: Android
PRs: #2565, #2571
Issues: #2564, #2507

CustomCommandButton.PREVIOUS was mapped to Capability.SKIP_TO_NEXT and CustomCommandButton.NEXT was mapped to Capability.SKIP_TO_PREVIOUS — a straightforward transposition. This caused the wrong capability to be associated with each button, resulting in incorrect button visibility, ordering, or missing buttons in the media notification.

Legitimacy: Confirmed. The enum values are clearly mislabelled and both PRs agree on the fix.

---

2. Notification play/pause and external controls have no effect

Affected: Android
PR: #2565
Issues: #2564, #2507

InnerForwardingPlayer.play() and .pause() emitted the appropriate events to React Native but never called super.play() / super.pause(), so the underlying ExoPlayer never actually started or stopped playback when triggered externally (notification, Bluetooth, car stereo). Similarly, no override existed for setPlayWhenReady(), so external state changes via that path emitted no events at all.

Legitimacy: Confirmed. The missing super calls are a clear omission — the overrides intercepted the action without forwarding it.

---

3. Lock screen / media key controls broken on OxygenOS 14

Affected: Android (OnePlus devices running OxygenOS 14 / Android 14)
PR: #2559
Issues: #2507

An existing workaround routes media key intents through onMediaKeyEvent for Android < 13, because onMediaButtonEvent is not reliably called on those versions. OnePlus introduced the same regression in OxygenOS 14, but fixed it again in OxygenOS 15. The workaround needed to be extended to also cover OnePlus devices on Android 14.

Legitimacy: Confirmed. The OxygenOS 14 regression is documented in issue #2507 and verified on a OnePlus 9.

---

4. Custom notification buttons (NEXT, PREVIOUS, JUMP_FORWARD, JUMP_BACKWARD) unresponsive on some Android versions

Affected: Android
PRs: #2565, #2571
Issues: #2564, #2507

On some Android versions Media3 dispatches custom notification button clicks as intents to onStartCommand rather than through onCustomCommand. Because onStartCommand had no handling for ACTION_CUSTOM_NOTIFICATION_ACTION, these button presses were silently dropped.

Legitimacy: Confirmed. Both PRs independently identify and fix the same gap.

---

5. QueuedAudioPlayer.load() does not update the internal Kotlin queue

Affected: Android
PR: #2589

In the else branch of load(), ExoPlayer's internal playlist was updated via addMediaItem + removeMediaItem, but the Kotlin queue LinkedList was never updated to match. After switching tracks, queue[currentIndex] continued to return the first-ever loaded item.

The practical consequence: updateMetadataForTrack(index, bundle) reads the current track from queue[index] and calls replaceItem(index, track.toAudioItem()). Because queue[0] was stale, replaceItem called exoPlayer.replaceMediaItem with the original stream URL every metadata refresh cycle, reverting playback to the first-ever loaded track within seconds of switching.

All queue-derived properties (currentItem, items, previousItems, nextItems) were also affected, as they all read from the Kotlin queue.

Legitimacy: Confirmed. The if (queue.isEmpty()) branch correctly calls add(), which updates the queue. The else branch bypassed add() and manipulated ExoPlayer directly without mirroring the change — a clear omission.

---

6. Pressing previous always skips track instead of restarting

Affected: Android
PR: #2571

In v4, pressing the previous button within the first 3 seconds of a track skipped to the previous track, and after 3 seconds it restarted the current one. This behaviour was lost in v5-alpha. skipToPrevious() unconditionally called player.previous() regardless of playback position.

Legitimacy: Confirmed regression from v4. Standard behaviour for media players (also how Apple Music, Spotify etc. behave).

---

🍎 iOS

7. Lock screen controls missing on first play when locking immediately

Affected: iOS
PR: #2583

In configureAudioSession(), audioSessionController.activateSession() was called before AVAudioSession.setCategory(.playback, ...). This caused the session to activate with iOS's default .soloAmbient category, which does not support MPRemoteCommandCenter or lock screen media controls. Only .playback and .playAndRecord categories support remote commands.

The result: if the user locked the device immediately after pressing play for the first time, no lock screen controls appeared. Backgrounding the app first worked as a workaround because the session had time to be reconfigured.

Legitimacy: Confirmed. iOS documentation is explicit that the category must be set before activation for it to take effect.

---

8. Lock screen shows no metadata when locking immediately after play

Affected: iOS
PR: #2583

NowPlayingInfoController in SwiftAudioEx publishes metadata asynchronously via a concurrent dispatch queue. If the user locks the screen immediately after pressing play, MPNowPlayingInfoCenter.default().nowPlayingInfo is still nil when iOS queries it to render the lock screen widget.

Legitimacy: Confirmed. The async dispatch is observable — backgrounding the app first resolves the issue because the dispatch has time to complete before the lock screen appears.

---

9. Pressing previous always skips track instead of restarting

Affected: iOS
PR: #2571

Same regression as Android (#5 above). skipToPrevious unconditionally called player.previous() without checking playback position first.

Note: The iOS implementation in PR #2571 contains a secondary bug — it calls player.previous() unconditionally before checking the threshold, then calls it a second time in the else branch. The correct logic checks position first and only calls player.previous() in the ≤3s branch.

Legitimacy: Confirmed regression from v4. The PR fix has a logic error that should be corrected before merging.

[Thijmen]

That's a great summary @bitcrumb, those would be indeed the first things that needs fixing if we would need forking this project. Hope it doesn't need to come that far.

[lovegaoshi]

nobody needs the ai slop.

rntp is an apache oss with no warranty what so ever. u r free to fork or find alternative like folks choosing expo audio or https://github.com/evergrace-co/react-native-audio-pro or make ur own like https://github.com/bbplayer-app/BBPlayer/tree/dev/packages/orpheus, but expecting maintenance from someone elses free time wont get u far. welcome to oss

[Thijmen]

@lovegaoshi having a rough day? People are offering their ✨free✨ time to help this project out. No need to act hostile.

[lovegaoshi]

please move the discussion to whoever is doing free work then.

…

On Fri, Feb 27, 2026, 12:01 PM Thijmen Stavenuiter ***@***.***> wrote: *Thijmen* left a comment (doublesymmetry/react-native-track-player#2582) <#2582 (comment)> @lovegaoshi <https://github.com/lovegaoshi> having a rough day? People are offering their ✨free✨ time to help this project out. No need to act hostile. — Reply to this email directly, view it on GitHub <#2582 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVVVIIZ3PGZN2PJYJNL4OCPAXAVCNFSM6AAAAACVEPPSXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZUHAZDSNBXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[bitcrumb]

We're not expecting any maintenance and are instead actively reaching out to help. Part of that is asking status. People have already actively contributed to this package with PRs that are stale due to lack of follow-up (which we want to tackle).

In an effort to shed light on what I think should certainly be part of an official 5.0.0 release I created an AI-assisted overview of all open bug PRs and related issues. These are not just small bugs btw.

I also didn't just generate this with a spray-and-pray prompt, but actively verified each of the PRs, issues and claims. I am not deeply invested in this project, so I did it to the best of my ability.

Ideally we get this project (a bit more) active again for everybody's sake.

Btw, I have made a fork already to contribute back a PR with a fix. If this project doesn't take of anymore, continuing work on that fork is of course an option. And having all open PRs fixed in that fork would be a matter of minutes to hours using Claude Code.

But instead of contributing to yet another fork with no traction (yet), I'd rather have everyone contribute to an already established package.

Thanks for pointing out the other packages/projects btw, did not know about those yet. I can also add that I've got my main use-case (live audio streaming with lock screen controls) covered by expo-audio now that Expo SDK 55 has been released.

It's also pretty straightforward for me to use pnpm patching or patch-package and let Claude Code (or other LLMs) generate patches without contributing back or caring.

Instead I opted to engage in this issue to get things flowing. You on the other hand have been far from helpful with your comments.

And for what it is worth: I could actually execute (part of the) work while doing my day job, since I actively need this package (or other packages if that proves to be the way out) when creating React Native apps for our customers.

/out

[lovegaoshi]

ur very welcome to fork and maintain urself with absolutely no permission required from an apache 2.0 oss. i dont know what ur expecting besides someone else to maintain it, which i hope i made it clear u should seek alternatives instead.

…

On Fri, Feb 27, 2026, 12:13 PM Lode Vanhove ***@***.***> wrote: *bitcrumb* left a comment (doublesymmetry/react-native-track-player#2582) <#2582 (comment)> We're not *expecting* any maintenance and are instead actively reaching out to help. Part of that is asking status. People have already actively contributed to this package with PRs that are stale due to lack of follow-up (which we want to tackle). In an effort to shed light on what I think should certainly be part of an official 5.0.0 release I created an AI-assisted overview of all PRs and related issues. These are not just small bugs btw. I didn't just generate this with a spray-and-pray prompt, but actively verified each of the PRs, issues and claims. I am not deeply invested in this project, so I did it to the best of my ability. Ideally we get this project (a bit more) active again for everybody's sake. Btw, I have made a fork already to contribute back a PR with a fix. If this project doesn't take of anymore, continuing work on that fork is of course an option. And having all open PRs fixed in that fork would be a matter of minutes to hours using Claude Code. But instead of contributing to yet another fork with no traction (yet), I'd rather have everyone contribute to an already established package. Thanks for pointing out the other packages/projects btw, did not know about those yet. I can also add that I've got my main use-case (live audio streaming with lock screen controls) covered by expo-audio now that Expo SDK 55 has been released. It's also pretty straightforward for me to use pnpm patching or patch-package and let Claude Code (or other LLMs) generate patches without contributing back or caring. Instead I opted to engage in this issue to get this flowing. You on the other hand have been far from helpful with your comments. /out — Reply to this email directly, view it on GitHub <#2582 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZMOVVSKPMAENE7AXFO4TET4OCQOBAVCNFSM6AAAAACVEPPSXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZUHA4DGNZTGM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[bitcrumb]

i dont know what ur expecting besides someone else to maintain it

Literally this:

But instead of contributing to yet another fork with no traction (yet), I'd rather have everyone contribute to an already established package.

It is indeed absolutely no effort to fork and go on with my things. That is not the idea of this thread though.

[gavrichards]

@bitcrumb I applaud and support your efforts. I'm sure many others will too. Ignore the negative comments. The poster in question is routinely hostile on this repository. They're in the minority.

[DennisdeWitNL]

You know, @lovegaoshi, we are enthusiasts and want to contribute. Like it or not, but even AI solves solves some bugs. That makes it easier to contribute to a project that would be dead otherwise.

I don’t see the issue. You can always code review before merging. But finally we are contributing, taking time out of the hands of the main founders and we get a rather low kick under the belt because… why?

You’ve contributed in the past and that was great, maybe you are annoyed because the project was abandoned, but I have only seen negative comments from you lately. I feel sorry about that, as we genuinely try to fix what’s broken in an awesome repo. I don’t see the point of potentially chasing people away by negativity.

[wave52]

Has anyone tried react-native-audio-api yet? I'm curious if anyone has successfully migrated from RNTP to it and what the experience was like.