androidx / media

Jetpack Media3 support libraries for media use cases, including ExoPlayer, an extensible media player for Android
https://developer.android.com/media/media3
Apache License 2.0
1.69k stars 404 forks source link

isPlayingAd value change is delayed sometimes for midroll ads #745

Open ryanl-fun opened 1 year ago

ryanl-fun commented 1 year ago

Version

Media3 1.1.1

More version details

Issue reproduced on

Devices that reproduce the issue

Google TV Chromcast and Android mobile devices

Devices that do not reproduce the issue

N/A

Reproducible in the demo app?

Yes. Please see comment below.

Reproduction steps

Notes:

Steps:

  1. Play a video with ads.
  2. After the preroll is finished. Click the "settings" button on player to go to a new screen.
  3. Do nothing on this new screen, and return to player by pressing "back" button on TV remote. (this can also be an equivalent "back" action on mobile device)
  4. After returning to player, let the playback continue, until it reaches mid-roll.
  5. When mid-roll starts playing, observe if the ad controls, and countdown times show up correctly.

Expected result

The ad controls, and countdown times show up correctly.

Actual result

Media

N/A

(Think it doesn't depend on media, but can revisit)

Bug Report

tonihei commented 1 year ago

Just a few clarifying questions:

ryanl-fun commented 1 year ago

Just a few clarifying questions:

* Are you using client-side or server-side inserted ads?

* Is it a live stream or on-demand content?

* Does the problem also occur without entering this "settings" screen? If not, can you share more details what you do exactly after coming from the setting screens to resume playback?

Hi,

Let me know if you need another information. Thanks!

tonihei commented 1 year ago

We actually don't do anything after we go back to player, we do popBackStack and have the player to continue on the states of before leaving the player.

I think this may be a core part of the problem. You should release the player when you stop/pause the current fragment and re-create it when coming back, otherwise it may malfunction or use resources needed by other components. See these sections in guides/codelabs where this is explained: https://developer.android.com/media/implement/playback-app#preparing_the_player or https://developer.android.com/codelabs/exoplayer-intro#playeractivity.kt_3

Please also refer the IMA extension README that has a section about resuming playback after backgrounding that explains how to persist the ad playback state despite releasing the player. You can also see this happen in the ExoPlayer demo app.

ryanl-fun commented 1 year ago

Hello, we have tried to release the player when we go to another screen and re-created the player when coming back, we save the adsLoader and pass the same instance back when re-creating the player, but we still see this issue. Could you please provide some further help on this? Thank you!

tonihei commented 12 months ago

If you play the same stream and same ad tag in the ExoPlayer demo appm, do you see the same issue too? If so, please share the stream and ad tag so we can reproduce and investigate further.

google-oss-bot commented 11 months ago

Hey @ryanl-fun. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

google-oss-bot commented 11 months ago

Since there haven't been any recent updates here, I am going to close this issue.

@ryanl-fun if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

ryanl-fun commented 11 months ago

Hello @tonihei I wasn't working on this bug for the past couple of sprints due to priority change, but I just had some time to revisit this.

So, yes, I'm able to see the issue on the demo app. I tested with "Playlist: Client-side Ads - DASH VOD: Tears of Steel (11 periods, pre/mid/post) - No ads". I see similar issue when mid-roll starts to play.

What I did was I added a button on player_activity.xml, next to select_tracks_button. I have this button to go to a new activity when clicked, and this new activity can just use any layout file (I used fragment_error_message). So, after the pre-roll finishes playing, I click on this new button, it takes me to error screen; then I press back, and I go back to player. The video resumes. When it plays into mid-roll, I can see the ad UI doesn't show up right away, it only shows up when is it only 1-2 seconds left on the ad. Please see video below.

https://github.com/androidx/media/assets/110640973/3cfb73bb-228f-4c09-b5ef-df2eb694237e

tonihei commented 10 months ago

Thanks for the update! I can reproduce the same problem with briefly going to the home screen and back to the demo app as well (as it seems to be related to how we recover a previous playback when reentering the player activity).

tonihei commented 10 months ago

From what I can tell, it looks like a strange behavior from the underlying IMA Ads SDK. I reported the issue to them (internal ref: b/316355530), so it either gets fixed in the IMA SDK or we learn about the root cause and can workaround the problem in ExoPlayer.

tonihei commented 10 months ago

@ryanl-fun Just checking - I noted that the bug is only reproducible with "Playlist: Client-side Ads - DASH VOD: Tears of Steel (11 periods, pre/mid/post) - No ads". If I play the same client-side ad stream by itself, everything works fine. This looks like mixing client-side IMA ad insertion with server-side (DAI) ad insertion may not work as well as it should.

Do you also mix client-side and DAI in you real app? Or do you have any other pattern of using multiple ad loaders in your app?

ryanl-fun commented 10 months ago

Hi @tonihei we actually do client side ads only. No other pattern of ad loaders. I hope this information helps. : )