iOS Control Center shows "Not Playing" after setMediaItems

[brianlenz]

Describe the Bug
After calling setMediaItems() followed by play(), the iOS Control Center and lock screen show "Not Playing" and do not respond to remote commands — but only when there is no prior persisted "now playing" state for the app in iOS (e.g. fresh install, or after a prior session that explicitly cleared the player). If the app was previously registered as "now playing" by iOS and force-quit (without clearing), the next session works correctly.

Steps To Reproduce

1. Fresh install the app (or call TrackPlayer.clear() in a prior session while the audio session is active, which explicitly removes the app from iOS's "Now Playing" registry).
2. Call setupPlayer() + setCommands().
3. Call setMediaItems([...]) then play().
4. Observe the iOS Control Center / lock screen.

Expected: Control Center shows track title, artist, and playback controls.
Actual: Control Center shows "Not Playing". No track metadata is visible.

Environment Info:

react-native info

System:
  OS: macOS 26.6.1
  CPU: (10) arm64 Apple M1 Max
  Memory: 218.64 MB / 64.00 GB
  Shell:
    version: 5.3.9
    path: /opt/homebrew/bin/bash
Binaries:
  Node:
    version: 25.6.1
    path: /opt/homebrew/bin/node
  Yarn:
    version: 4.17.1
    path: /opt/homebrew/bin/yarn
  npm:
    version: 11.9.0
    path: /opt/homebrew/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/brian/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 25.5
      - iOS 26.5
      - macOS 26.5
      - tvOS 26.5
      - visionOS 26.5
      - watchOS 26.5
  Android SDK:
    API Levels:
      - "29"
      - "30"
      - "31"
      - "33"
      - "34"
      - "35"
      - "36"
    Build Tools:
      - 26.0.2
      - 26.0.3
      - 28.0.3
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 31.0.0
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
      - 35.0.0
      - 36.0.0
    System Images:
      - android-28 | Google ARM64-V8a Play ARM 64 v8a
      - android-29 | Google APIs ARM 64 v8a
      - android-29 | Google Play ARM 64 v8a
      - android-30 | Google Play ARM 64 v8a
      - android-31 | Google Play ARM 64 v8a
      - android-33 | Desktop ARM 64 v8a
      - android-33 | Google APIs ARM 64 v8a
      - android-34 | Google Play ARM 64 v8a
      - android-35 | Google Play ARM 64 v8a
      - android-36 | Google Play ARM 64 v8a
      - android-36 | Pre-Release 16 KB Page Size Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2026.1 AI-261.25134.95.2612.15914620
  Xcode:
    version: 26.6/17F113
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.30
    path: /opt/homebrew/bin/javac
  Ruby:
    version: 3.3.0
    path: /Users/brian/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.2.0
    wanted: 19.2.0
  react-native:
    installed: 0.83.6
    wanted: 0.83.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

• @rntp/player version 5.8.0
• iPhone 17 Pro Max
• iOS 26.6

How I can Help
What can you do to help resolve this?
Have you investigated the underlying issue?

[brianlenz]

@dcvz, it looks like this may be a similar issue to #2664. It turns out that react-native-video appears to be somehow interfering with RNTP's control over Control Center. I am using the latest RNV v7 beta 11 release, which includes support for completely disabling audio session management, which we've done (TheWidlarzGroup/react-native-video#4829). Once I disabled that, it solved the issue with Control Center showing "Not Playing" 👍 But that then presented a new issue: the metadata (title/artwork) appear correctly, but the player controls do not, which seems to be the same symptom as #2664.

Here's an example showing the disabled + incorrect player controls:

We have RNTP configured to use SkipForward and SkipBackward buttons, not the previous/next buttons shown in the screenshot.

We've tried calling TrackPlayer.setCommands() to try to reset/force the controls back into the expected state, but it doesn't seem to work. The TrackPlayer state seems to show the correct state, but the Control Center player doesn't reflect the config.

What I can say is that if we do not ever mount a video for react-native-video, then the issue doesn't happen. This would seem to point to RNV being the problem. Nevertheless, I'm suspicious about whether there is an underlying issue in RNTP that is preventing it from "self-healing" since the old RNTP v5 alpha didn't have this issue (against the same react-native-video dependency + behavior). After all, once RNV is unmounted and out of the picture, the issue with RNTP persists until app relaunch.

I've spent quite a bit of time trying to assess this with AI, including analyzing both RNTP and RNV code, but I've not yet been able to identify a culprit just yet.

I did use the example to create a repro, so here's a PR with a branch with changes for you to test with:

#2681

Here are the steps to repro:

1. Launch the TrackPlayerExample app in iOS.
2. Scroll down and observe the video is visible.
3. Play a track.
4. Open iOS Control Center and observe Now Playing.

Expected behavior: Now Playing shows track metadata and active, correct controls.
Actual behavior: Now Playing shows track metadata and disabled, incorrect controls.

You can then use the "Remove" button to completely remove the video component from the app. At that point, RNV should be completely out of the picture. If you try playing a new track again, the Now Playing behavior in Control Center is unchanged.

Note that the example app may need some updating to get to the latest React Native, as I had to add a hack to get iOS builds working due to glog issues. I also needed to update to the latest RNTP.

Hopefully this is helpful in your investigation 🙏 If there is anything else I can help with, please let me know!

[dcvz]

Thanks @brianlenz for the detailed report, I'll take a look!

[brianlenz]

Thanks, @dcvz! I'm still looking, too.

BTW, it looks like that glog build issue is caused by the 0.37.x release of react-native-nitro-modules:

margelo/nitro#1573

[brianlenz]

@dcvz I've got a patch that seems to fix our particular use case that I wanted to provide to you in case it is helpful in your investigation. I'm unclear if this is an appropriate, generic fix for RNTP or not. Here is AI's assessment:

Root cause

registerOnce() adds the MPRemoteCommandCenter targets once per module lifetime, and apply() is delta-only (never re-adds targets, per #2664). So there's no code path that can re-add them.

When a second AVPlayer shows up in the process (react-native-video mounting a video view), iOS drops our target bindings. Control Center falls back to a disabled next/previous template and taps never reach our handlers.

What made this hard to spot: RNTP's own state stays correct. Polling MPRemoteCommandCenter.shared() showed isEnabled and preferredIntervals continuously correct while Control Center showed the wrong disabled controls. Logging inside the handlers confirmed taps produce zero invocations. The object is right; the system's binding to it is stale.

Repro

Cold boot → mount a react-native-video view → start RNTP playback. Metadata/artwork correct, transport controls wrong and disabled. Never mount the video view and it all works.

Fix

1. RemoteCommandController.forceReregister(...) — removes and re-adds targets, then re-applies capabilities. Extracted the addTarget block into a shared addTargets(handlers:).
2. TrackPlayer.healRemoteCommandTargets() — called on a non-playing → playing transition only, via the existing lastIsPlaying guard.

I kept it off the capability-update path on purpose; churning there is what #2664 was about. A play transition is infrequent and is exactly when the controls need to be right.

Verified by triggering the re-register manually from JS after reproducing (controls snapped to correct instantly), then moving it to the automatic trigger.

Dead ends

• MPNowPlayingSession + becomeActiveIfPossible(): made it worse — returned success=true but Control Center went to "Not Playing" entirely.
• MPNowPlayingInfoCenter.playbackState: neutral, no effect.

Neither is in the patch.

Yarn patch (against 5.9.2): @rntp-player-npm-5.9.2-067138c277.patch

[brianlenz]

@dcvz just wanted to check if you have any updates on this issue? Thank you! 🙏