updateMetadataForTrack not working most of the time

[RamProg]

trafficstars

Describe the Bug updateMetadataForTrack is not changing the notification and the Now Playing Center on Android. I'm leaving an example with the title property changing, but the same happens with the duration and with every other property.

Steps To Reproduce On Android Add a track to the queue, play it and try to update the notification with the updateMetadataForTrack. You should see a change in the notification, but that's not happening. If you get the track you'll see the changes, but the notification always stays the same (I think it worked once or twice, but fails most times).

Code To Reproduce

const oldTitle = (await TrackPlayer.getTrack(0))?.title;
console.log('old Title: ', oldTitle);
await TrackPlayer.updateMetadataForTrack(0, {
    title: 'has changed',
});
const newTitle = (await TrackPlayer.getTrack(0))?.title;
console.log('newTitle', newTitle);

// oldTitle: 'My favourite Song'
// newTitle: 'hasChanged'

Environment Info:

System:
    OS: macOS 12.2.1
    CPU: (10) x64 Apple M1 Max
    Memory: 28.82 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.15.0 - ~/.nvm/versions/node/v14.15.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v14.15.0/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v14.15.0/bin/npm
    Watchman: 2022.07.04.00 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
    Android SDK: Not Found
  IDEs:
    Android Studio: 2021.2 AI-212.5712.43.2112.8609683
    Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.16 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: Not Found
    react-native: Not Found
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

react-native-track-player v3.1.0 Also happens in nightly. Android Studio Simulator and device. MacOS.

How I can Help I can provide support and data.

[Tucker2015]

Having the same issue but my Artwork is updating correctly just not title or artist. iOS works fine.

I tried

TrackPlayer.updateNowPlayingMetadata({ title: String(title), artist: String(artist), artwork: img === '' ? metadata.artwork : img, });

This is the same code I used in v2.2.0-rc3 and updated fine with that version.

[RamProg]

Yeah, my issue is with the duration because I'm trying to get the duration and then update it, but I noticed it also fails with other properties. I haven't tried the updateNowPlayingMetadata, but if it's not working for you it's probably the same issue.

[VinceBT]

I have the same issue in android, using the same code as before, and I have null for the artist and title, and sometimes the artwork works

[gavrichards]

I've been attempting to debug this. I've traced the metadata through to KotlinAudio's NotificationManager class.

The notificationMetadata property is set with the artist, title and artworkUrl. If you insert a log here, you can see the values as expected.

That then calls the reload method, which in turn calls the invalidate method on Exoplayer's notification manager.

This is where the trail currently runs cold for me.

If you comment out the call to reload(), you will see the notification no longer updates at all. Leave the call to reload() in, and only the artwork updates, but not the artist or title.

For anyone looking to replicate, you need to pull this repo and KotlinAudio and set everything up locally as explained in the example project's README.

Then edit PlayerControls.tsx in the example project, to include a way to update metadata, like this:

export const PlayerControls: React.FC = () => {

  const sendMeta = async () => {
    const trackIndex = await TrackPlayer.getCurrentTrack();
    if (trackIndex !== null) {
      const metadata = {
        artist: 'HELLO',
        title: 'WORLD',
        artwork: 'https://is2-ssl.mzstatic.com/image/thumb/Music122/v4/ca/0e/ec/ca0eeccb-eecd-4c72-557d-3d422c6dd1c6/5054197264252.jpg/600x600bb.jpg',
      };

      TrackPlayer.updateMetadataForTrack(trackIndex, metadata);
    }
  };

  return (
    <View style={{ width: '100%' }}>
      <View style={styles.row}>
        <Button
          title="Prev"
          onPress={() => TrackPlayer.skipToPrevious()}
          type="secondary"
        />
        <PlayPauseButton />
        <Button
          title="Next"
          onPress={() => TrackPlayer.skipToNext()}
          type="secondary"
        />
        <Button
            title="Meta"
            onPress={sendMeta}
            type="secondary"
        />
      </View>
    </View>
  );
};

You will note that the notification updates correctly with each track that is played, but when you tap the "Meta" button, only the artwork changes - the artist and title remain as they were.

[jspizziri]

@mpivchev could use your eyes on this one. I took a high-level look. Not sure why the ExoPlayer invalidate method isn't doing what its supposed to be (at least not entirely).

[gavrichards]

I've stumbled on a fix, but I don't fully understand how/why it works. It involves this section here.

If you change:

    fun replaceItem(index: Int, item: AudioItem) {
        val mediaSource = getMediaSourceFromAudioItem(item)
        queue[index] = mediaSource

        if (currentIndex == index && automaticallyUpdateNotificationMetadata)
            notificationManager.notificationMetadata = NotificationMetadata(item.title, item.artist, item.artwork)
    }

to:

    fun replaceItem(index: Int, item: AudioItem) {
        val mediaSource = getMediaSourceFromAudioItem(item)
        queue[index] = mediaSource

        if (currentIndex == index && automaticallyUpdateNotificationMetadata) {
            notificationManager.notificationMetadata =
                NotificationMetadata(item.title, item.artist, item.artwork)

            mediaSessionConnector.setMediaMetadataProvider {
                mediaSource.getMediaMetadataCompat()
            }
        }
    }

...then it works.

I discovered this because I noticed how the call to set notificationManager.notificationMetadata in BaseAudioPlayer is followed by a similar snippet (but I was able to simplify it for this fix).

I would definitely appreciate @mpivchev reviewing this. Particularly how automaticallyUpdateNotificationMetadata is used in both sections I've referenced.

[jspizziri]

Possibly related to https://github.com/doublesymmetry/react-native-track-player/issues/1653?

@gavrichards if its convenient I'd be curious to see if your fix also fixes the issue above.

[gavrichards]

@jspizziri I'll give it a quick try now.

[RamProg]

I updated to RNTP v3.2 and this issue is still happening.

[gavrichards]

I updated to RNTP v3.2 and this issue is still happening.

The PR https://github.com/doublesymmetry/KotlinAudio/pull/52 hasn't been reviewed yet, so the bug is still present.

[neoassyrian]

hi, I'm having an issue where the updateMetadataForTrack is not working. I use it when I recieve the song details from a radio live (using icy or icy-headers) inside the "PlaybackMetadataReceived" event

I'm currently on "react-native-track-player": "^3.2.0",

[puckey]

I was also able to fix this by removing the original mediaSessionConnector.setMediaMetadataProvider call. See https://github.com/doublesymmetry/KotlinAudio/pull/54/commits/9db93a959387485cadfbe29d2cce199b52e1eb5f

It seems that it was causing exoplayer to update the notification as well. @mpivchev I see you introduced this in the following pr https://github.com/doublesymmetry/KotlinAudio/commit/d2ac459a90498aa4487358e5716979aba558bffe – perhaps there is a good reason for adding it that I may be missing?

[RamProg]

Still happening on 3.2.0-d23c3fb990aaf9d6783881fabe21e059b62b0782

[gianpietro1]

Hi! I'm also seeing the issue on Android devices & 3.2.0. Any expected version for the review/fix? Thanks!

[gavrichards]

In the current nightly, artist and title is now working, but the artwork no longer updates, getting stuck on the initial image for the track.

[gianpietro1]

Not sure if this helps, but I'm not seeing the issue at all in API 28 (ZTE Blade A530 with Android 9)

[DrMickArtisan]

Hi, If it can helps, I only view this on android 11 (api 30). On API 33 it seems to work (but I only try on emulator)

[puckey]

In the current nightly, artist and title is now working, but the artwork no longer updates, getting stuck on the initial image for the track.

Should be fixed by https://github.com/doublesymmetry/KotlinAudio/pull/59

[jspizziri]

Now that https://github.com/doublesymmetry/KotlinAudio/pull/59 has been merged we'll need to wait for the build to be available on jitpack.io and then bump the version here https://github.com/doublesymmetry/react-native-track-player/blob/main/android/build.gradle#L52

Any community members interested in creating a PR for that? Should be a chipshot.

[gavrichards]

This is now fixed in nightly, issue can be closed.

[mitchdowney]

I am still running into this issue on Android.

I don't know for sure my problem isn't user error, but I am using the nightly branch, and it seems like KotlinAudio 2.0.0-rc3 is installed (I'm not 100% sure how to check this but I see it in the RNTP build.gradle).

The image on the lockscreen stays whatever the image was that first loaded for the track.

I call await PVAudioPlayer.updateMetadataForTrack(currentIndex, newTrack) and the new track has different artwork URLs (and open the URL in a browser to verify the images are different), yet the lock screen stays the same image.

[tewson]

This issue was fixed in 4.0.0-rc05 but seems to have come back in 4.0.0-rc06.

[gavrichards]

I can confirm we're seeing this regression too, after updating from 4.0.0-rc04 to 4.0.0-rc06.

[puckey]

So I think we also need to update the tag of the exoplayer media item here: https://github.com/doublesymmetry/KotlinAudio/blob/main/kotlin-audio/src/main/java/com/doublesymmetry/kotlinaudio/players/QueuedAudioPlayer.kt#L217

Will be able to look into it early September

[dcvz]

There's a fix for this ongoing here: https://github.com/doublesymmetry/KotlinAudio/pull/87. I'll update this thread when that's done.

[dcvz]

This should be fixed now in v4.0.0.0-rc07