Seeing this makes me very happy.

I think you'll want to update to the 2.18.7 version of ExoPlayer first, and then migrate over to the corresponding Media3 1.0.2 release (and then update to the latest Media3 release). I think it'll make the Media3 migration easier to manage.

If you look at the ExoPlayer changelog, I think you'll get use out of this:

• Add track selection methods to the Player interface, for example, Player.getCurrentTracksInfo and Player.setTrackSelectionParameters. These methods can be used instead of directly accessing the track selector.

There's some other stuff in the ExoPlayer releases that I think could be used, too. Be sure to take advantage of any new features (like the above).

Here's some other resources:

• https://github.com/androidx/media/blob/release/RELEASENOTES.md
• https://android-developers.googleblog.com/2021/10/jetpack-media3.html
• Example session: https://github.com/androidx/media/tree/main/demos/session
• More MediaSession info: https://developer.android.com/guide/topics/media/media3/getting-started/mediasession

I already played around with this in https://github.com/ByteHamster/AntennaPod/tree/media3. This is an insane amount of work and requires completely re-writing our playback service. Incremental version updates probably won't help because the entire playback code needs to be thrown away anyway.

My very minimalistic re-write that doesn't support any features except the "play" button (no speed, no position saving, etc) still does not fix #6576. So I'm pretty sure that upgrading to media3 will not directly solve any of the issues we currently have, but will cause us a bunch of new issues. So this rewrite is quite low on my list currently.

I can take a stab at this. As a preliminary warning, however, I think this would involve redesigning (and rewriting) many components, so it is quite a major change that would require more discussions. Will this Github issue be an appropriate venue for such discussions?

Regarding #6576 (sorry, I'm not allowed to comment there): I have a good understanding on what's happening there. I think the media session API is just not designed to handle resuming playback from the notification when the playback service is evicted. Upgrading to media3 should actually help there, if we let it take care of the service lifecycle and notifications.

I think this would involve redesigning (and rewriting) many components, so it is quite a major change that would require more discussions. Will this Github issue be an appropriate venue for such discussions?

Personally I prefer the forum for long/difficult discussions because it's a bit better suited for it (quoting etc). However, if there's no changes affecting the UI/UX, it's fine to do it here I guess.

Will this Github issue be an appropriate venue for such discussions?

I would say so, yes. It's mainly a technical discussion and doesn't need UI decisions. I guess discussing code in the PR would also be a big part of this.

I think this would involve redesigning (and rewriting) many components, so it is quite a major change

Yes, that's what I thought as well when playing around with media3 a bit. Given that the playback service is, by far, the most complex part of AntennaPod, I think it is worth the rewrite. (Some years ago I rewrote the download service, which helped a lot with making it more maintainable. I even deleted like half of the code while keeping the same functionality. I assume it could be similar for the playback service)

@ByteHamster would it be possible to unlock #6576 so that I can chime in on the matter of the service being destroyed when media is paused, resulting in the play button not working from the notification?

I don't want to post about it here, given that I don't think media3 is the magic solution and would rather continue in the original report.