Users reporting a disconnect from Chromecast.

[GoogleCodeExporter]

Sometime around Nov 9 2014 I started receiving emails and reviews complaining 
that my app disconnects from the Chromecast quickly. The version of the app on 
the reviews is from June/July and the web page itself hasn't changed since 
around the same time. 

The reviews are as follows:

"Disconnects the connection to the recently chrome cast upon successful 
transmission of the data"
"Stopped working Worked of for ages now won't stay connected to chromecast"
"Won't stay connected to the chromecast it's annoying me because iV paid for 
the app and now it don't work not a happy chapy"
"I've Downloaded your appapp it was working properly be for i paid for the app 
now it won't stay connected to chromecast for more then 10 seconds how to fix 
plz"
"Today,I tried several times to stream with my Galaxy Tab 2 and Galaxy S3, but 
it didn't work. Every time maximum 5 seconds after the video started, the cast 
disconnected. First, I thought it was because of the Chromecast, but all the 
other apps do work."
"The app will not stay connected to my Chromecast. Is there anything I can try?"

Anyways those are just some of the reviews and comments on my app. I went ahead 
and looked at another app with a larger number of downloads (LocalCast) and 
found these comments on it:

11/10 "It constantly disconnects never had this problem till now. "
11/9 "Used to work fine Now it disconnects from my Chromecast whenever I try to 
stream anything. "
11/9 "Suddenly stops working Worked well for a while, now just disconnects 
every time I attempt to use it"
11/9 "Bad Connection Last several version have big problem seen and keeping 
conection with my chromecast if i restart my phone or tablet cant see the 
chromecast i have to connect with some other app like bubbleupnp and then 
localcast can see it never had any problems like that with other apps and you 
blame google play services funny how all other apps dont have that problem "
11/8 "Issues with connection Since the last update, my localcast will not stay 
connected with Chromecast for more than a few seconds before it drops the 
connection. I will be using BubbleUPnP until this issue is corrected."
11/8 "Horrible Works a few minute then stops "
11/8 "Disconnect Disconnects after a few seconds. I've tried reinstalling but 
still having same issue. Worked fine until today "

So as you can see it isn't an isolated issue. I went back a few days on the 
LocalCast reviews and couldn't find any other mentions of disconnects before 
November 8. 

One of my users said that rebooting everything (Chromecast, phone, home wifi) 
fixed it but the rest claim that doesn't fix it.

I don't have any logs to submit as I have yet to experience this and I've 
tested on 4 different Chromecast devices. 

Thanks.

Original issue reported on code.google.com by car...@instantbits.com on 10 Nov 2014 at 7:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just had the issue happen to me. I'm attaching the log. 

Original comment by car...@instantbits.com on 10 Nov 2014 at 8:35

Attachments:

• disconnect.txt

[GoogleCodeExporter]

Can you also provide the log for the receiver.

Original comment by lnicho...@google.com on 10 Nov 2014 at 8:47

• Changed state: Acknowledged

[GoogleCodeExporter]

How do I get the receiver log? the connection to port 9222 went down when the 
app disconnected. 

Original comment by car...@instantbits.com on 10 Nov 2014 at 8:49

[GoogleCodeExporter]

You can only get the logs while the session is live. Reproduce the issue with 
the remote debugger connected. You should be able to see the last part of the 
logs even when it goes down.

Original comment by lnicho...@google.com on 10 Nov 2014 at 8:51

[GoogleCodeExporter]

I am attaching what I could get of the receiver console output. Just like the 
previous log, all I changed was company names, app ids. I should also mention 
that between my first report and right now the Chromecast has worked just fine 
several times. Also it is not necessary to send a video to the Chromecast for 
this issue to occur, simply connecting with the app and waiting a few seconds 
will do it. 

Original comment by car...@instantbits.com on 10 Nov 2014 at 9:01

Attachments:

• receiverlog.txt

[GoogleCodeExporter]

I should also mention, while having this issue with my app I went ahead and 
tried using LocalCast with the same Chromecast and it had the exact same issue, 
just five seconds or so and it disconnected. 

Original comment by car...@instantbits.com on 10 Nov 2014 at 9:03

[GoogleCodeExporter]

Please fill in this form with your original logs so we can investigate this 
further:
https://support.google.com/cast-developer/contact/google_cast_contact_us?rd=1

Original comment by lnicho...@google.com on 10 Nov 2014 at 9:20

[GoogleCodeExporter]

I submitted them. I wasn't sure what my developer ID was so I just put my 
email. 

Original comment by car...@instantbits.com on 10 Nov 2014 at 9:41

[GoogleCodeExporter]

I should mention the Chromecast I am able to reproduce this on has version 
22062 on it while the others have 19084.

Original comment by car...@instantbits.com on 11 Nov 2014 at 2:08

[GoogleCodeExporter]

Connects to chromecast for few seconds and suddenly disconnects after few 
seconds 
plz fix isuue
thanks

Original comment by riyapate...@gmail.com on 11 Nov 2014 at 1:04

[GoogleCodeExporter]

Any updates on this issue? 

Original comment by car...@instantbits.com on 13 Nov 2014 at 2:24

[GoogleCodeExporter]

At the suggestion made by return email from Carlos, I did reboot Chromecast 
from my Tablet and the app stopped disconnecting from Chromecast home page on 
my tv. Thank you Carlos.

Original comment by roth.505...@gmail.com on 13 Nov 2014 at 3:03

[GoogleCodeExporter]

I think I found a little more information about the issue, it appears to only 
affect apps using a custom receiver. I added the default receiver tonight to 
another app I have and it stays connected just fine but as soon as I try it 
with my app which has the custom receiver the connection drops a few seconds 
later. 

Original comment by car...@instantbits.com on 13 Nov 2014 at 3:10

[GoogleCodeExporter]

Es wäre schön das Problem mit dem abbrechen bald in den griff zu bekommen. 

Original comment by chopperp...@googlemail.com on 13 Nov 2014 at 7:37

[GoogleCodeExporter]

OK also... Reset Google Crome stick. Push the button in the stick for 25 sec. 
Configurate it. 

Original comment by chopperp...@googlemail.com on 13 Nov 2014 at 8:00

[GoogleCodeExporter]

Would you please update the chromecast firmware?

It is unconvient to use the chrome cast. 

It is connected and disconnected between mobile and chromecast. 

Original comment by power...@gmail.com on 14 Nov 2014 at 10:47

[GoogleCodeExporter]

Please make to support the mirrering on galaxy note2 and note3 neo.

Original comment by power...@gmail.com on 14 Nov 2014 at 10:52

[GoogleCodeExporter]

Any updates?

Original comment by car...@instantbits.com on 15 Nov 2014 at 11:37

[GoogleCodeExporter]

We've also seen a spike in users reporting this issue. We also have a custom 
receiver and users report that the chromecast session disconnects a few seconds 
inton the session.

Original comment by dbarr...@gmail.com on 16 Nov 2014 at 3:59

[GoogleCodeExporter]

#20 there appears to be a workaround for this on this g+ comment 
https://plus.google.com/u/1/109720416927515295704/posts/fRAihp2o1gz?cfem=1

I tried it on the one Chromecast I have that can reproduce the issue and it 
seemed to work. 

Original comment by casol...@gmail.com on 16 Nov 2014 at 4:02

[GoogleCodeExporter]

Using the Cast-Player-Sample reference receiver app as a starting point for 
your custom receiver is recommended since it is equivalent to the Styled Media 
Receiver in terms of features and bug fixes: 
https://github.com/googlecast/Cast-Player-Sample

Original comment by lnicho...@google.com on 16 Nov 2014 at 4:24

[GoogleCodeExporter]

We are using the cast-custom-receiver sample and at least 5 different users of 
our App are reporting the issue: 
https://github.com/googlecast/cast-custom-receiver
Assuming that sample is supported, right?

Original comment by dbarr...@gmail.com on 16 Nov 2014 at 7:42

[GoogleCodeExporter]

Is your code in sync with the latest version of the reference receiver?

Original comment by lnicho...@google.com on 16 Nov 2014 at 4:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Github has various options for you to track any updates to a repo. We 
continuously add features, make improvements and fix bugs in the reference apps.

Original comment by lnicho...@google.com on 16 Nov 2014 at 4:20

[GoogleCodeExporter]

Is there a policy on how often we need to update the code to reflect what is on 
github or when changes are required? and are you saying that this issue is 
because I haven't updated my code? Yesterday I am pretty sure I reproduced the 
issue using the latest of this example (which is what my code is based on) 
https://github.com/googlecast/cast-custom-receiver/blob/master/sample_media_rece
iver.html

Original comment by car...@instantbits.com on 16 Nov 2014 at 4:37

[GoogleCodeExporter]

It is up to you to decide when to pick up changes to the public repos. Our 
reference apps comply with the Cast Design Checklist. The other sample apps are 
designed to demonstrate the use of various specific API's and are not compliant 
with the Cast Design Checklist.

Original comment by lnicho...@google.com on 16 Nov 2014 at 4:41

[GoogleCodeExporter]

Last night we merged in the latest changes from 
https://github.com/googlecast/cast-custom-receiver but that didn't help, users 
are still reporting the issue. They say the only work around is to reset 
chromecast, but the issue comes back the second time the launch our receiver. 
Do you have any insights on the issue? Did you find anything from the logs?

Original comment by dbarr...@gmail.com on 16 Nov 2014 at 6:02

[GoogleCodeExporter]

Are you calling window.close() somewhere in your code, and if so, where?

Original comment by ali.nad...@gmail.com on 16 Nov 2014 at 7:50

[GoogleCodeExporter]

We only call it inside onSenderDisconnected:
if(senders.length == 0 && event.reason == 
cast.receiver.system.DisconnectReason.REQUESTED_BY_SENDER)

We're using the code from the cast-custom-receiver sample. The sample also 
calls window.close() in a couple other places but those are with 10 second 
timeouts and the receiver is disconnecting within 2-3 seconds so that could not 
be the reason.

Original comment by dbarr...@gmail.com on 16 Nov 2014 at 8:01

[GoogleCodeExporter]

Are you positive that this issue doesn't show up if you switch to a 
default/styled receiver?

Original comment by anad...@google.com on 16 Nov 2014 at 8:07

[GoogleCodeExporter]

I'm not sure myself, that was reported by someone else on the G+ community. But 
the apps/people that have been reporting the issue are all using the 
cast-custom-receiver as a starting point for their apps. It would be good to 
hear from other people about this.

Original comment by dbarr...@gmail.com on 16 Nov 2014 at 8:09

[GoogleCodeExporter]

Before adding the workaround (below) I asked my users to use the Chromecast's 
feedback option and use the following phrase in the feedback field: 
LocalCast_100
At least 10 stated that the feedback was sent.

It seems that all (affected) receivers crash/disconnect when the Chromecast is 
in that state. I could switch between my development and production receiver, 
which are hosted on different domains and have different app ids and both would 
crash/disconnect.

Workaround:
The last log I could capture before the receiver disconnected/crashed was from 
window.castReceiverManager.onReady. I noticed when I call 
document.location.reload(); that the receiver worked, so I added this 
workaround:

window.castReceiverManager.onReady = function(q) {            
      if (sessionStorage.getItem('temporaryBugFixedByReloading') !== 'fixed') {
          sessionStorage.setItem('temporaryBugFixedByReloading', 'fixed');
          document.location.reload();
      }
};

I cannot confirm that this worked, but I guess it did. I had no single user 
report since I added this and most of the reviews mentioning it were changed. 
(~50.000 app uses on Sunday)

How to reproduce this ?
I tried it for 3 hours: disconnecting, rebooting, unplugging, resetting, 
casting with other apps. Nothing triggered it. But I noticed that it happened 
two times, when I switched the TV on in the morning.

Sorry for probably unnecessary information, but in this case probably every 
single bit helps, I guess.

Original comment by dakdr...@gmail.com on 16 Nov 2014 at 8:13

[GoogleCodeExporter]

I will have to test this again later today but yesterday I tried both 
https://github.com/googlecast/cast-custom-receiver and 
https://github.com/googlecast/Cast-Player-Sample and only 
https://github.com/googlecast/cast-custom-receiver would reproduce the problem. 
And the fix that was posted on G+ does seem to have fixed it for me:

window.castReceiverManager.onReady = function(q) {            
                if (sessionStorage.getItem('temporaryBugFixedByReloading') !== 'fixed') {
                    sessionStorage.setItem('temporaryBugFixedByReloading', 'fixed');
                    document.location.reload();
                }
            };

Original comment by car...@instantbits.com on 16 Nov 2014 at 8:14

[GoogleCodeExporter]

We also implemented the document.location.reload() hack over the weekend and 
the user complaints have been significantly reduced. Thank you!
However, we all know that's not a long term fix, hopefully we can get to the 
bottom of this.

Original comment by dbarr...@gmail.com on 17 Nov 2014 at 6:40

[GoogleCodeExporter]

There are a few things that you need to do and then report back.

(1) Make sure that you are basing your receiver on Cast-Player-Sample and not 
the cast-custom-receiver.

(2) As it is done in the Cast-Player-Sample, please call stop rather than 
window.close()

(3) You may be calling window.close() when UI visibility change event is fired. 
That can be another factor in shutdown if such event is fired incorrectly (due 
to issues in the TV, etc). You might want to change that to "pause" rather than 
"close/stop" to avoid a bad behavior (that is what the Cast-Player-Sample does 
as well)

(4) Monitor your sender device when that happens to see if the disconnect is 
issued directly by sender or it is propagated down from receiver to narrow down 
which component is causing this.

(5) the "reload()" hack is not a solution, so you should not use that.

Original comment by anad...@google.com on 17 Nov 2014 at 6:44

• Changed state: NeedInfo

[GoogleCodeExporter]

Answers to #37:

1.- Is there a difference on how Cast-Player-Sample parses m3u8 files compared 
to cast-custom-receiver? I am having an issue with one m3u8 which uses a crypt 
key. On cast-custom-receiver I can see it clearly making the call to get the 
crypt key whereas I don't see that on the Cast-Player-Sample. Everything else 
looks the same until then. 

2.- I have removed the close calls one by one and found the one that does it, 
however on the comments it says this will depend on the TV so I am guessing the 
method right below it will also need to have the close removed. It is this one 
which does it (I have the close commented out):

 window.castReceiverManager.onVisibilityChanged = function (event) {
            console.log("### Cast Receiver Manager - Visibility Changed : " + JSON.stringify(event));

            /** check if visible and pause media if not - add a timer to tear down after a period of time
             if visibilty does not change back **/
            if (event.data) { // It is visible
                window.mediaElement.play(); // Resume media playback
                window.clearTimeout(window.timeout); // Turn off the timeout
                window.timeout = null;
            } else {
                window.mediaElement.pause(); // Pause playback
                window.timeout = window.setTimeout(function () {
                    console.log("this one closes it");
                    //window.close();
                }, 10000); // 10 Minute timeout
            }
        }

4 .- I had submitted several logs before, I'm guessing you can see whether that 
is the case on those logs?

5.- I couldn't agree more. 

Original comment by casol...@gmail.com on 18 Nov 2014 at 2:14

[GoogleCodeExporter]

I just went back and read that code and realized this is totally wrong:

 window.timeout = window.setTimeout(function () {
                    console.log("this one closes it");
                    //window.close();
                }, 10000); // 10 Minute timeout

It has 10000 but the value is in milliseconds so that is not a 10 minute 
timeout. The question is, should I comment out the close or increase the 
timeout? I ask that because I am sometimes sending a video quicker than 10 
seconds and it still disconnects. 

Original comment by car...@instantbits.com on 18 Nov 2014 at 2:17

[GoogleCodeExporter]

I've done some testing following Stefan's suggestions, the events happen as 
follows:

### Cast Receiver Manager is READY:
### Cast Receiver Manager - Visibility Changed
Timeout gets set
### Cast Receiver Manager - Sender Connected

So even clearing timeout on "ready" won't fix it, but clearing it on "sender 
connected" seems to fix it, I've only done a couple of tests. 

Original comment by car...@instantbits.com on 18 Nov 2014 at 2:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can we rely on castReceiverManager.onVisibilityChanged at all ? Is it only 
wrongly called with data = false on startup ?

Original comment by dakdr...@gmail.com on 18 Nov 2014 at 2:59

[GoogleCodeExporter]

In response to #37:
1. Both use MPL library for adaptive streams with a difference that the 
Cast-Player-Sample uses the latest version of that and the other one uses an 
out-dated unsupported version.

2. As I have mentioned a few times, DO NOT USE the cast-custom-receiver as a 
basis for your receiver. the correct sample, Cast-Player-Sample correctly uses 
the stop() method in two places and those should most likely be all you need to 
use that method.

4. The submitted logs don't show anything out of ordinary; it shows that the 
shutdown is caused by probably calling window.close().

Original comment by anad...@google.com on 18 Nov 2014 at 4:29

[GoogleCodeExporter]

In response to #39, #40: DO NOT USE cast-custom-receiver as the basis for your 
receiver. The Cast-Player-Sample does the correct thing for the ui visibility 
change: if ui becomes invisible when playing,m it pauses and that should be 
what you need to do as well.

Original comment by anad...@google.com on 18 Nov 2014 at 4:32

[GoogleCodeExporter]

In response to #43 and #44, I think you might be forgetting that it isn't 
trivial to just change the receiver code. No one implements a custom receiver 
unless they are going to add a bunch of their own code to it. You are taking 
about apps here with hundreds of thousands of downloads, we can't go replacing 
code willy nilly without extensive testing, not to mention it will take a while 
to make the changes. Plus as mentioned before there are other issues with 
switching, like that m3u8 issue which might take a long while to even figure 
out what the problem is. 

Original comment by car...@instantbits.com on 18 Nov 2014 at 4:38

[GoogleCodeExporter]

#45: No one is claiming it is just flipping a switch, but if you want to have a 
solid starting point for a custom receiver, I told you what the right choice 
is. In your case, I suggest you start moving your receiver to the one that was 
suggested; the cast-custom-receiver is mainly used as a sample to help users 
see various debug messages as state changes, etc. The fact that it is using an 
old MPL and SDK should have warned you that it is not really a reference app. 

Regardless of these, I am pointing you to where your disconnect issue is and 
how you'd like to handle that is certainly up to you.

Original comment by anad...@google.com on 18 Nov 2014 at 4:56

[GoogleCodeExporter]

We have updated the receiver to report the UI Visibility change more 
accurately. You need to reboot your chromecast to pick up the new receiver. 
Please give that a try and let us know if you still see issues.

Original comment by anad...@google.com on 24 Nov 2014 at 6:35

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the fix however I haven't been able to reproduce the issue today 
even without a reboot so I'm not sure I'm going to be able to test the fix. My 
firmware is still at 22062. 

Original comment by car...@instantbits.com on 24 Nov 2014 at 10:06

[GoogleCodeExporter]

There is no firmware update; receiver has been updated so you should pick that 
up without any firmware change

Original comment by anad...@google.com on 24 Nov 2014 at 10:08

[GoogleCodeExporter]

Ok so I'm guessing there is a chance I already have it. Anyway to verify if I 
have it? for what it's worth the code that I am 100% certain had the issue last 
week seems to be working fine today. 

Original comment by car...@instantbits.com on 24 Nov 2014 at 10:15