Metadata update behaviour on bluetooth devices

[6rism0]

I've experienced different behaviour regarding metadata updates on different bluetooth devices.

Bluetooth devices that show metadata information to the user, seem to handle metadata updates differently. The metadata updates we want to show are plain instream icecast metadata.

When testing metadata updates in a car console, it seems like the metadata would only update when the player state changes as well. But on the other hand, when connecting to a fairly new tv, the metadata gets updated as expected.

With other player implementations using the https://github.com/google/ExoPlayer calling MediaSession::setMetadata would result in immediate updates, regardless which type of BT device is connected.

Is there a way to achieve consistent updates on every device? Might this be an issue with our implementation?

[marcbaechinger]

Thanks for your report!

With other player implementations using the https://github.com/google/ExoPlayer calling MediaSession::setMetadata would result in immediate updates, regardless which type of BT device is connected.

Can you give me some details how the media session is updated? Is this a Media3 session that you are running in a MediaLibraryService/MediaSessionService or do you have a custom implementation?

When testing metadata updates in a car console, it seems like the metadata would only update when the player state changes as well. But on the other hand, when connecting to a fairly new tv, the metadata gets updated as expected.

I understand you are connecting the device by Bluetooth to the car console or TV? Is this correct? As in, this is not about an Android Auto or Android TV integration?

If this is the case, then the car console/TV is not directly talking to your app. Instead the Bluetooth service in Android reads out the media session state when it changes and sends it to the connected BT device I think.

Is there a way to achieve consistent updates on every device? Might this be an issue with our implementation?

It's indeed weird that it works for some BT connection but not for others.

I suggest you try the same with the session demo app to see if this is an issue with your implementation. If you add your URI to the catalog.json file you should be able to play your media quite easily. You can then verify on the mobile notification whether the metadata on the phone is updated as expected. Then connect the device with BT in the same way as before.

If it doesn't work with the session demo, then please create a bug report and upload it here for me to investigate.

If it works with the session demo, then it may be that your implementation has an issue. We'll see.

[6rism0]

Hey @marcbaechinger,

Can you give me some details how the media session is updated? Is this a Media3 session that you are running in a MediaLibraryService/MediaSessionService or do you have a custom implementation?

Yes, we use a MediaLibraryService and added some custom implementation wrapper around the player, but I think this can be ignored as I could reproduce the same behaviour without any custom implementation and with session demo app.

I understand you are connecting the device by Bluetooth to the car console or TV? Is this correct? As in, this is not about an Android Auto or Android TV integration?

Thats correct, just plain BT connection. The devices we've used to test this are:

1. Car Console (issues updating as described above) - https://www.sony.com/electronics/support/mobile-cd-players-digital-media-players-xav-series/xav-ax100/specifications
2. TV (no issues) - https://www.lg.com/nz/tvs/lg-oled48c24la

Test session demo app

The behaviour is exactly the same with the demo app, the notification is updated immediately and the car console is stuck with previous metadata as long as the player state is not changed.

Here is the corresponding bug report

[6rism0]

Hey there @marcbaechinger, are there any updates regarding this issue?

[Neocortexxx]

Hi @marcbaechinger, good to see someone has the same issue with BT metadata. I can confirm the same behavior like @6rism0. Are there any new insights to this issue yet?