Repository navigation
Erroneous onPlaybackStatsReady calls when changing playlist #180
Description
Media3 Version
1.0.0-beta02
Devices that reproduce the issue
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Yes
Reproduction steps
Let's consider the following playlist:
0. A
[...]
497. B
498. C
499. D
And the following onPlaybackStatsReady:
override fun onPlaybackStatsReady(eventTime: AnalyticsListener.EventTime, playbackStats: PlaybackStats) {
val mediaItem = eventTime.timeline.getWindow(eventTime.windowIndex, Timeline.Window()).mediaItem
val totalPlayTimeMs = playbackStats.totalPlayTimeMs
println("${mediaItem.mediaId} played for ${totalPlayTimeMs}ms")
}Case 1
- Play B
- Change playlist
Case 2
- Play B
- Play C
- Play D
- Change playlist
Expected result
Case 1
B played for 1000ms
Case 2
B played for 1000ms
C played for 1000ms
D played for 1000ms
Actual result
Case 1
B played for 1000ms
A played for 1000ms
Case 2
B played for 1000ms
C played for 1000ms
D played for 1000ms
A played for 2996ms
Media
Not applicable
Bug Report
- You will email the zip file produced by
adb bugreportto dev.exoplayer@gmail.com after filing this issue.
Activity
vfsfitvnm commentedon Oct 5, 2022
device-2022-10-05-190902.mp4
[-]Erroneous onPlaybackStatsReady calls when chaning playlist[/-][+]Erroneous onPlaybackStatsReady calls when changing playlist[/+]tonihei commentedon Oct 6, 2022
Could you clarify what you mean by "Change playlist" in your instructions? It seems "A" is never played in the reproduction steps, so it's not entirely clear why you expect a callback for this media item.
Note that the
onPlaybackStatsReadyis only called once an item definitely finished playing, so maybe it just happens later than you expect it happen?vfsfitvnm commentedon Oct 6, 2022
After submitting the issue I realized I put the "expected result" as "actual result" as vice versa - and I quickly edited the message. However I think you still read the original message (via e-mail maybe) - however yes, "A" is never played and so I do not expect a callback to be called for such media item.
But as you can see from the screen recording, the callback for "A" occurs.
For "changing playlist" I meant calling
player.setMediaItems(...)(this is what happens indemo-session).vfsfitvnm commentedon Oct 6, 2022
To add more, playing around with playlist changes, I can see suspicious calls for the first media item of the just-replaced playlist with
playbackStats.totalPlayTimeMsequals to zero.tonihei commentedon Oct 10, 2022
I can reproduce what you are seeing, but it looks as if everything is working as intended.
PlayableFolderActivityin the session demo app calls:The first method will start playback with the first item in the list, the second call will update the position to the item you tapped. So the
PlaybackStatsListenercorrectly tracks 0 play time for the first item in the list as it was briefly the active item.To actually avoid the issue, the
PlayableFolderActivityshould set the item list and the start position in one command. I'm going to update the code accordingly.vfsfitvnm commentedon Oct 10, 2022
That's what I thought too, but I swear I couldn't find such
setMediaItemsoverload. This solves the original issue!However, I still find odd that
onPlaybackStatsReady(having the firstmediaItemof the playlist) is called withtotalPlayTimeMsnot equal to zero. It looks like the playback time counter keeps running with these calls:tonihei commentedon Oct 10, 2022
It was always zero in my tests. Can you describe a specific sequence of item selections that cause the additional problem of keeping the counter running? And also, where exactly did you add/remove/replace the
PlaybackStatsListener?vfsfitvnm commentedon Oct 10, 2022
Here's the fork which reproduces the issue: https://github.com/vfsfitvnm/media
Steps to reproduce:
tonihei commentedon Oct 11, 2022
Thanks for the helpful reproduction steps. This is indeed a bug in our session tracking that happens only for the case where we seek very quickly to a new item before the current one got the chance to update its internal state. We'll provide a fix for this as well.
Set new playlist and start index with one command
Ensure sessions without MediaPeriodId are ended after seek to new item
Ensure sessions without MediaPeriodId are ended after seek to new item
Set new playlist and start index with one command
Ensure sessions without MediaPeriodId are ended after seek to new item
Ensure sessions without MediaPeriodId are ended after seek to new item
Chore/bump exo 2.18.2 (#66)
tonihei commentedon Jan 26, 2023
Issue was fixed by the commits above.
Chore/merge canary in (#74)
Impr/doris 1730 migrate exo 2.18.4 (#77)