"Multiple renderer media clocks enabled" when setting selection override

[moneytoo]

I'm migrating to TrackSelectionOverrides for "track" selection in ExoPlayer 2.16.0. I'm using it with TrackSelectionParameters and it seems to be working (I set the overrides when Player.STATE_READY).

...
TrackSelectionParameters.Builder trackSelectionParametersBuilder = new TrackSelectionParameters.Builder(this)
		.setTrackSelectionOverrides(overridesBuilder.build());
player.setTrackSelectionParameters(trackSelectionParametersBuilder.build());

However when overrides get set for a media file utilizing multiple audio renderers (the default one as well as ffmpeg; for example file containing AC3 & TrueHD or AC3 & MP2), I receive following error:

E/ExoPlayerImplInternal: Playback error
      com.google.android.exoplayer2.ExoPlaybackException: Unexpected runtime error
        at com.google.android.exoplayer2.DefaultMediaClock.onRendererEnabled(DefaultMediaClock.java:96)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.enableRenderer(ExoPlayerImplInternal.java:2454)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.enableRenderers(ExoPlayerImplInternal.java:2402)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.reselectTracksInternal(ExoPlayerImplInternal.java:1709)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:511)
        at android.os.Handler.dispatchMessage(Handler.java:103)
        at android.os.Looper.loop(Looper.java:214)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: java.lang.IllegalStateException: Multiple renderer media clocks enabled.
        at com.google.android.exoplayer2.DefaultMediaClock.onRendererEnabled(DefaultMediaClock.java:96) 
        at com.google.android.exoplayer2.ExoPlayerImplInternal.enableRenderer(ExoPlayerImplInternal.java:2454) 
        at com.google.android.exoplayer2.ExoPlayerImplInternal.enableRenderers(ExoPlayerImplInternal.java:2402) 
        at com.google.android.exoplayer2.ExoPlayerImplInternal.reselectTracksInternal(ExoPlayerImplInternal.java:1709) 
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:511) 
        at android.os.Handler.dispatchMessage(Handler.java:103) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.os.HandlerThread.run(HandlerThread.java:67) 

• ExoPlayer version number: 2.16.0 with applied patch eb678a7
• Android version: Android 10
• Android device: OnePlus 7

[tonihei]

I don't think this ever worked when setting overrides for the extension renderer only. The reason is that the DefaultTrackSelector assigns one audio track to the default renderer, and the override just assigns the second audio track to the extension renderer in addition to the first one. To make this work, the default selection needs to be removed specifically by making an empty override for the first renderer. See #2618 where this came up in the past (and we prevented it from happening for cases without overrides).

However, the good thing is that the contract of the new TrackSelectionOverride.Builder.setOverrideForType actually allows us to do this internally because the method promises to only select the provided override for its type. So we can simplify such use cases by automatically disabling all other selections for the same track type.

p.s.: Thanks for finding all these tricky edge case problems with our new track selection API! This is extremely helpful, although we should have caught them ourselves before releasing :)

[krocard]

However, the good thing is that the contract of the new TrackSelectionOverride.Builder.setOverrideForType actually allows us to do this internally because the method promises to only select the provided override for its type. So we can simplify such use cases by automatically disabling all other selections for the same track type.

Yes this is what I had in mind when I introduced the API. It makes for a much simpler usage for the client to only have to set one override per type.

The cl adding the logic of disabling every over track of the same type is still pending as it complexify the logic significantly due to backward compatibility for legacy overrides.

I did not realize that it would cause an actual issue in multi audio renders. Sorry about that @moneytoo.