Media3 upgrade

[jkransen]

This PR solves two issues

• ExoPlayer is deprecated, and replaced by Media3
• Buffer underruns caused music to distort rather than pause

Both were solved by upgrading to Media3

I run it locally in the emulator without problems. The UI is slightly different, but arguably better, with a list of playlists instead of a grid. That is apparently how Media3 does it. Let me know what you think!

[joeyberkovitz]

I'll take a look. Last time I looked at media3, I realized that the car side still uses the old lib so media3 ends up being translated over

That had the side effect of messing with things (I think getting auto resume to work - the car wouldn't pass the media ID). I have a branch with it, possibly locally, though I'll have to test

[jkransen]

Ok let me know if you find anything. Do you have a way to deploy branches directly to your car? I don't seem to have that option.

I checked that the changes did not require a higher minSdk, they don't, but I was unaware that the car side itself may mess things up.

I just checked with my AI agent, and indeed we seem to be missing an auto-resume part with Media3. I will add that ASAP.

[joeyberkovitz]

check out my old branch https://github.com/joeyberkovitz/plex-aaos/tree/media3-migration

https://github.com/joeyberkovitz/plex-aaos/blob/media3-migration/automotive/src/main/java/us/berkovitz/plexaaos/MediaService.kt#L515

last I tried it - playlists just straight didn't work properly (as mentioned in the comment). I had to get pretty hacky with embedding relevant info because the media3 to media1 compat layer strips out a lot of info.

you can't test directly on a car because they usually don't allow ADB/debug, so you're mostly stuck with the desktop emulators (volvo and standard google). if you really need to, you can setup a dev app in the play store and deploy that to the car without going through the approval process

[jkransen]

Thanks, I could reproduce it in the emulator. I have a solution for it as well now. Do you think it is too hacky now with my most recent commit? Part of it is for buffering, because I still got distortions at resuming as well as starting songs.

[jkransen]

Speaking of the approval process, does approval by Google imply that it is released to Volvo, or do they have to approve as well? What are your experiences with the process? I read that they are much stricter than with the phone apps, and rightly so I guess.

[joeyberkovitz]

once google approves, it's released to every car. the approval process isn't too hard, though occasionally they'll manually validate the app and complain if they can't figure out how to use it.

when I last looked at it - I felt like the concept of media3 was nice, but actually using media3 on top of media1 felt like a downgrade and loss of functionality.

I'll check out your branch later, I had also mostly figured out some hacks to make things work, it's just that media1 doesn't need any hacks to work properly.

this just seems like a typical case of google being dumb and not properly supporting their own systems. (sorry - rant mode) - if you deprecated the old version, why is the new one still using the old one under the hood, and not even able to fully utilize the existing APIs? on media1 - the car would remember whatever ID was playing (playlist + song). we lose that now, so you basically have to ignore most of what the media service asks you, just store everything yourself, and kind of guess what to do.

if media3 (I guess the player portion) is sufficiently more stable than exoplayer, maybe that'll outweigh the costs of "downgrading" to the media3 service. IDK if you did it, but on my branch - I didn't bother to put together the functionality for shuffle/repeat because I pretty much just decided that the upgrade was pointless after the playlist mess.

[jkransen]

I realised something last night. Plex servers also keep track of where players are. Players periodically send their progress explicitly to PUT /:/timeline, containing current position and playback status (playing, paused, stopped). The downside is that "current playlist" is not part of the update.

I think one way or another it is good to start sending these updates. Without this, songs played in the car would never show up in the "Recently Played" playlist.

The next question would be whether to retrieve this information (from /library/onDeck), and resume from the server state rather than keeping state locally as the above commit does. The problem would be that we would not know the playlist, which may be more relevant in the car than the current song. We could still keep track of the playlist locally, and retrieve the most recent unfinished song + position that this playlist contains.

The fun would be that you can finish the song in the car that you started at home, and vice versa. But maybe I am overthinking, and maybe we don't even want to resume songs halfway in the car. What do you think? We could add an "Auto Resume" checkbox to the settings pane?

I'll do some experiments here, to see how it works, and whether it blows up the code base.

[joeyberkovitz]

Yeah, I think sending state back to the server is fine, but shouldn't be necessary

I guess the question is if exoplayer is so broken that it's worth migrating to media3, which is also broken in different ways

If it's worth it, worst case we have local storage and can just remember things independently of the car

I'd want to do some testing to make sure feature parity remains. Mainly:

• shuffle/repeat support
• if you turn the car off/on - it resumes in the correct playlist, mode and at the last position

[joeyberkovitz]

left a comment about the buffering. anyway - I cleaned up the branch I had earlier as it dealt with some deprecations that weren't handled here and I also handled some issues around pagination + saving song progress

the only thing i did was kill the download manager. I'll look into preserving that before I merge

[joeyberkovitz]

ended up releasing media3

with regard to the buffering - I just set the media3 DefaultLoadControl to buffer 10 seconds of audio before starting playback. that seems more correct to me than toggling playWhenReady on and off

LMK if that helps out