Fix empty CastTimeline on reconnect #9078
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
They are not restored correctly on a reconnect.
inv3rse
force-pushed
the
bugfix/castTimelineRestore
branch
from
fae08b6 to
77fdbe0
Compare
|
I resolved the merge conflicts and checked the behavior again. |
|
@marcbaechinger can you have a look? |
|
Closing all PRs on this deprecated project. We are now unable to merge PRs from here. If you would like us to consider this change again please file a new PR on the media3 project: https://github.com/androidx/media/pulls |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After connecting to a cast device that is already playing, the
CastTimelinewould initially stay empty.And in turn all methods that rely on the timeline would also report incorrect data.
The reason for this is that the
MediaQueuewould always return an empty array as active ids until there are further state changes on the cast. This does appear to be an issue in the cast framework, but it can easily be worked around by checking theMediaStatusinstead.Fixes #9026