Fix MULTI_THREAD timing issue on Samsung TV #1556
Merged
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
We recently noticed an issue when loading multiple contents that led to
infinite loading, that was only seen on Samsung TVs.
After investigation, we noticed that there's a small window of time
where the messages sent by the WebWorker are not listened by the main
thread, that lead to those infinite loading as the main thread is still
waiting for a message the Worker already sent.
This happened if the message was sent by the worker during the short time
interval between:
- "Content preparation": When main thread asks the worker to load the MPD
and to initialize some things
- and "Content start": We actually start to play that content
Basically, this time interval should roughly be equal to the time it
takes to "stop" the previous content (which we do by emptying the
`HTMLMediaElement`'s src attribute), so a really short time yet still too
long to possibly lead to issue (if for example the MPD loads faster than
the stop operation, the main thread wouldn't get the info).
There's multiple ways we could fix the issue. For now, I chose to add a
way I'm not perfectly happy with due to the amount of logic added but
which should work:
- At "content preparation", we listen to worker messages. For those
that we can process immediately (for now, just logs) we process them
right now, for others, we push them to a special message queue until
the content is started
- At "content start", we check the message queue and if not empty, we
process all messages from it at that point.
I tested it with success on a Samsung TV reproducing the issue.
peaBerberian
added
bug
Florent-Bouisset
approved these changes
Sep 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We recently noticed an issue when loading multiple contents that led to infinite loading, that was only seen on Samsung TVs.
After investigation, we noticed that there's a small window of time where the messages sent by the WebWorker are not listened by the main thread, that lead to those infinite loading as the main thread is still waiting for a message the Worker already sent.
This happened if the message was sent by the worker during the short time interval between:
Basically, this time interval should roughly be equal to the time it takes to "stop" the previous content (which we do by emptying the
HTMLMediaElement's src attribute), so a really short time yet still too long to possibly lead to issue (if for example the MPD loads faster than the stop operation, the main thread wouldn't get the info).There's multiple ways we could fix the issue. For now, I chose to add a way I'm not perfectly happy with due to the amount of logic added but which should work:
At "content preparation", we listen to worker messages. For those that we can process immediately (for now, just logs) we process them right now, for others, we push them to a special message queue until the content is started
At "content start", we check the message queue and if not empty, we process all messages from it at that point.
I tested it with success on a Samsung TV reproducing the issue.