Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple createMediaSource calls when initiating the playback #1570

Closed
SemihGk opened this issue Aug 30, 2018 · 3 comments
Closed

Multiple createMediaSource calls when initiating the playback #1570

SemihGk opened this issue Aug 30, 2018 · 3 comments
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@SemihGk
Copy link
Contributor

SemihGk commented Aug 30, 2018

Have you read the FAQ and checked for duplicate open issues?:
Yes
What version of Shaka Player are you using?:
master
Can you reproduce the issue with our latest release version?:
yes
Can you reproduce the issue with the latest code from master?:
yes
Are you using the demo app or your own custom app?:
demo app
If custom app, can you reproduce the issue using our demo app?:

What browser and OS are you using?:
Chrome MacOS
What are the manifest and license server URIs?:

It does not matter. Use any sample content.
What did you do?
Initiated playback and call load method of shaka player.
What did you expect to happen?
It should create MediaSource only once, not twice in order.
What actually happened?
It created MediaSource and it removed it. Then, it created again.

When we initialize Shaka Player, attach method calls createMediaSource method. Then, when we call .load() method, it also calls unload method. However, unload method calls createMediaSource as well. Eventually, this creates MediaSource twice even though previous one is destroyed.

Please let me know if the issue is still unclear, but solution should be very straightforward. This if seems very suspicious .

Thank you,
Semih.

@vaage
Copy link
Contributor

vaage commented Aug 31, 2018

@SemihGk Good new, I am already looking through the load chain code for work with #816. If this issue is not causing any major issues for you or your users, would you be willing to wait until I make more progress on #816 where then we can re-evaulate whether this is still an issue after more of that work is complete?

@vaage vaage added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Aug 31, 2018
@vaage vaage self-assigned this Aug 31, 2018
@SemihGk
Copy link
Contributor Author

SemihGk commented Aug 31, 2018

@vaage , I appreciate for your concern. This is definitely not an issue as this is not causing any problem on most of the platforms (if we do not count performance case) except 2019 LG TV . I made a fix on my fork. So, there is no rush at all. This is just a 'good to have' enhancement. Thank you.

@shaka-bot shaka-bot removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Aug 31, 2018
@vaage vaage added type: enhancement New feature or request and removed needs triage labels Aug 31, 2018
@shaka-bot shaka-bot added this to the Backlog milestone Aug 31, 2018
@joeyparrish joeyparrish added type: bug Something isn't working correctly and removed type: enhancement New feature or request labels Sep 2, 2018
@joeyparrish
Copy link
Member

I'm relabeling this as a bug, since I can say with certainty that I didn't intend this part of the system to behave in this way. But since you have a workaround and this may be solved during #816, I'm going to leave it in the backlog for now. Thanks!

shaka-bot pushed a commit that referenced this issue Feb 26, 2019
In order to support multiple different forms of loading, we have
designed a toolkit that we are calling "The Load Graph Toolkit". It
allows us to describe a series of work as a graph, and provides a way
for us to move through that graph, executing actions at each step.

This is the first step toward resolving #816, #997, and #1570. This
will provide the framework to build a more structured system for
loading and unloading content.

Issue #816
Issue #997
Issue #1570

Change-Id: I2f91089d07b0c901843550492308fcfd775bf161
shaka-bot pushed a commit that referenced this issue Feb 26, 2019
This is the initial integration between the walker and the player. In
order to make this simpler, this keeps all of "load" as one transition
and will slowly break it into multiple parts in later CLs.

Tests that focused on verifying the changes in states were moved from
the unit tests to the integration tests.

As of this CL we model the load graph as:

  Detached -> Attached -> Loaded -> Unloading
      ^         ^                       |
      |         |                       |
      +---------+-----------------------+

With this CL we lose:
  - Interrupting manifest load retries when interrupting a load.
  - Interrupting loading.
  - Pre-initializing media source.

We have immediate plans to add back:
  - Interrupting loading.
  - Pre-initializing media source.

We are still designing how to handle:
  - Interrupting manifest load retries when interrupting a load.

Issue #816
Issue #997
Issue #1570

Change-Id: Ie929621f94c2701f7d4e031b7a31dbd1c74a69c6
@joeyparrish joeyparrish modified the milestones: Backlog, v2.5 Mar 15, 2019
@shaka-project shaka-project locked and limited conversation to collaborators Apr 28, 2019
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

4 participants