Adding fallback handling for MediaUtils.convertToRepeatMode() in MediaControllerImplLegacy

[h6ah4i]

What's the matter?

I am using a forked version of the media3 library for my app to work around a specific issue. The problem is that some apps maybe use their own extended definition of repeat mode.

At least, the app I can find that causes the problem is Stellio. This app has two special repeat modes that cannot be handled by MediaUtils.convertToRepeatMode()

• Jump to a next list - Stop on last track
  • 👉 representation code in decimal: 100
• Jump to a next list - Stop from first list
  • 👉 representation code in decimal: 101

Proposed solution

Wrap the MediaUtils.convertToRepeatMode() call with a try-catch block and fallback to an alternative repeat mode like this.

media/libraries/session/src/main/java/androidx/media3/session/MediaControllerImplLegacy.java

Line 1869 in 2fc189d

repeatMode = MediaUtils.convertToRepeatMode(newLegacyPlayerInfo.repeatMode);

-    repeatMode = MediaUtils.convertToRepeatMode(newLegacyPlayerInfo.repeatMode);
+    try {
+      repeatMode = MediaUtils.convertToRepeatMode(newLegacyPlayerInfo.repeatMode);
+    } catch (IllegalArgumentException e) {
+      repeatMode = Player.REPEAT_MODE_OFF;
+    }

I think calling MediaUtils.convertToShuffleModeEnabled() is somewhat dangerous too due to the same reason, but I don't find the app that causes the error in the real world for now.

[oceanjules]

It is a design decision not to handle the repeat modes we know nothing about. Although, I can see a way for us to introduce a different function like:

MediaUtils.convertToRepeatMode(@PlaybackStateCompat.ShuffleMode int repeatMode, @Player.RepeatMode int defaultMode);

However, to avoid that, can I ask you whether you can handle the repeat mode yourself before letting it propagate as an invalid integer? If you manage to convert it to PlaybackStateCompat.REPEAT_MODE_INVALID, then it will be handled exactly how you want - with a Player.REPEAT_MODE_OFF

media/libraries/session/src/main/java/androidx/media3/session/MediaUtils.java

Lines 957 to 960 in 2fc189d

	switch (playbackStateCompatRepeatMode) {
	case PlaybackStateCompat.REPEAT_MODE_INVALID:
	case PlaybackStateCompat.REPEAT_MODE_NONE:
	return Player.REPEAT_MODE_OFF;

[h6ah4i]

However, to avoid that, can I ask you whether you can handle the repeat mode yourself before letting it propagate as an invalid integer? If you manage to convert it to PlaybackStateCompat.REPEAT_MODE_INVALID, then it will be handled exactly how you want - with a Player.REPEAT_MODE_OFF

That sounds like a more flexible and clean solution to me 👍

[h6ah4i]

@oceanjules

Sorry, I am not sure where I can inject the repeat mode transformation logic without creating a fork of the media3 library... Will you add the mechanism in a future release of media3?

The app I mentioned Stellio is not what I maintain. I just need to control this app from a different app through androidx.media3.session.MediaController created with a MediaSession.

In the implementation of the media3 library, I can see there are two places where I need to insert a transformation logic.

1. In a android.support.v4.media.session.MediaControllerCompat.Callback#onRepeatModeChanged() callback

   • media/libraries/session/src/main/java/androidx/media3/session/MediaControllerImplLegacy.java

     Line 1751 in 2fc189d

     public void onRepeatModeChanged(

2. Where calling the android.support.v4.media.session.MediaControllerCompat.getRepeatMode() method

   • media/libraries/session/src/main/java/androidx/media3/session/MediaControllerImplLegacy.java

     Line 1231 in 2fc189d

     controllerCompat.getRepeatMode(),

   • media/libraries/session/src/main/java/androidx/media3/session/MediaControllerImplLegacy.java

     Line 1667 in 2fc189d

     controllerCompat.getRepeatMode(),

---

Should I report this issue to the issue tracker of Android instead of here, because MediaControllerCompat is part of androidx.media:media package?

[oceanjules]

After an internal discussion, it was noted that:

• the behaviour of handling of unsupported types is currently undefined. It can be an IllegalArgumentException or it can be a common-case default value or anything else.
• ideally, you would be able to talk to the app developers who are violating the interface and let them know that they are causing the crash. We are aware of the difficulties that brings and we want to provide the best experience for whoever is on the MediaController/MediaSession Media3/Legacy boundary (with the focus of media3 adoption of course)
• in this particular case, we will change the current behaviour to:
  • unsupported PlaybackStateCompat repeat mode -> Player.REPEAT_MODE_OFF
  • log-warning that this is the translation that occurred
• in the future, we might end up with injectable behaviour for various Legacy <-> Media3 modes where you could override the defaults

[h6ah4i]

Thanks for the detailed information 🙇 I'll try to contact the author of the app that violates the spec of the media/media3 boundary.