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.
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.