-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Cast connection is not recover after create a new CastProxy #768
Comments
I believe I have reproduced and found a fix for this bug. The fix will be out soon. |
If you call chrome.cast.initialize a second time, it does not error but it also does not fire off receiverStatusChanged in order to signal the initial receiver status. This can result in problems if the CastProxy is destroyed and then re-created; specifically, it will erroneously claim to be unable to cast until the receiver status next changes. This makes hasReceivers_ into a class variable, so that a new sender will use the hasReceivers_ of previous ones. The original bug report was kind of confusing, so I cannot say for sure if this actually solves their problem or not. Hopefully it does. Issue #768 Change-Id: I7839ed99a8c48c69567bbcaeb1f9b6728265d63b
@avelad, can you please retest with the master branch? We think this might fix the issue, but we are not certain if we understood the report correctly. Thanks! |
@theodab @joeyparrish , I can reproduce the error, I'll try to share with you a code example. |
If you call chrome.cast.initialize a second time, it does not error but it also does not fire off receiverStatusChanged in order to signal the initial receiver status. This can result in problems if the CastProxy is destroyed and then re-created; specifically, it will erroneously claim to be unable to cast until the receiver status next changes. This makes hasReceivers_ into a class variable, so that a new sender will use the hasReceivers_ of previous ones. The original bug report was kind of confusing, so I cannot say for sure if this actually solves their problem or not. Hopefully it does. Issue #768 Change-Id: I7839ed99a8c48c69567bbcaeb1f9b6728265d63b
Those code samples aren't enough for me to personally replicate your issue. However, I did notice that when destroying the cast proxy, you do nothing with the return value when calling castProxy_.destroy().
|
@theodab, I sent you an email with the source code and video with the problem. I hope that help, if not contact me. |
Beforehand, calling chrome.cast.session_.destroy() would typically cause an error, as the message or update listener was called after the the CastSender was destroyed. This removes those listeners before destroying. Issue #768 Change-Id: I7889adce7b829c3f24dac7a178c9be26e2fdc887
The cast sender API doesn't seem to be able to re-use an existing session unless you reload the page. This stores the old session, so that it can be re-used without reloading the page. In order to enable this, CastProxy.destroy no longer leaves the current session; I figure if you want to leave the session, you'll call forceDisconnect. That part I am not fully sure about; perhaps it would be better to have a separate optional argument about whether or not to leave, or make it a part of the forceDisconnect argument. Issue #768 Change-Id: Ie648372cea4b106ff85df3d0dcc563fca5d10d8c
Okay, I fixed a bug and changed the behavior of the cast sender so that you can re-connect to a session properly after destroying it. |
@theodab , thanks for all. I'll check the changes and I tell you if it works (I need some days). |
hi @theodab , I just tested the latest commit, and it works perfectly!!! Do you think that it's possible make a cherry-pick to 2.2.3? |
It's possible, since these changes are smallish bugfixes and not major feature work, but that decision is up to Joey. |
Yes, I see no problem cherry-picking these to v2.2.3, which I hope to release this week. |
Beforehand, calling chrome.cast.session_.destroy() would typically cause an error, as the message or update listener was called after the the CastSender was destroyed. This removes those listeners before destroying. Issue #768 Change-Id: I7889adce7b829c3f24dac7a178c9be26e2fdc887
The cast sender API doesn't seem to be able to re-use an existing session unless you reload the page. This stores the old session, so that it can be re-used without reloading the page. In order to enable this, CastProxy.destroy no longer leaves the current session; I figure if you want to leave the session, you'll call forceDisconnect. That part I am not fully sure about; perhaps it would be better to have a separate optional argument about whether or not to leave, or make it a part of the forceDisconnect argument. Issue #768 Change-Id: Ie648372cea4b106ff85df3d0dcc563fca5d10d8c
What version of Shaka Player are you using? 2.1.0
master
? YesAre you using the demo app or your own custom app? Custom app
What browser and OS are you using?
Chrome 58 on Ubuntu 17.04
Error:
Create a CastProxy (and init the player) and load any manifest (eg: https://storage.googleapis.com/shaka-demo-assets/sintel/dash.mpd). Cast (canCast() returns true)and reproduce some seconds and destroy the player (shakaControl.player_.unload()) and then remove video tag of the current DOM (using components with AngularJS). Note: Cast Receiver is avalaible.
Next, add a new video tag (reusing the same component but, inserting it again in the dom), create a new CastProxy (and init the player) and load any manifest (eg: https://storage.googleapis.com/shaka-demo-assets/tos-ttml/dash.mpd). Now canCast() return false and it doesn't reuse the previous conection that it's available.
Note: if I reload the page instead of the previous, it's works.
The text was updated successfully, but these errors were encountered: