Chromecast is sending disconnect command due to heartbeat timeout, preventing graceful reconnect

[GoogleCodeExporter]

Note this is only happening on certain devices:

What steps will reproduce the problem?
1. Open Haystack TV 
2. Cast a video and put the app aside, waiting for the screen to turn off on 
the device.
3. Wait a few minutes while a video or two plays.
4. Open the device , when Haystack TV resumes you will notice that the 
Chromecast disconnects, Haystack TV can not use Chromecast reconnect because it 
got a disconnect command :

D/CastDeviceController( 1101): [controller-0020 API] disconnecting due to 
heartbeat timeout

What is the expected output? What do you see instead?

Ideally the disconnect command is not sent. This way when the app resumes it 
can gracefully reconnect to the Chromecast session (Haystack TV enables 
Chromecast reconnect provided we did not receive a disconnect command).

What version of the product are you using? On what operating system?

This is happening with a Nexus 7 1st gen tablet running version 4.2.2 of 
Android.

Please provide any additional information below.

I'm attaching a log file captured when this issue happened.

Original issue reported on code.google.com by ish...@gmail.com on 29 Aug 2015 at 12:52

Attachments:

• Chromecast_disconnect_when_turn_screen_off.txt

[GoogleCodeExporter]

Are you using the Cast Companion Library in your app? We highly recommend that 
you use CCL instead of trying to implement your own reconnection logic.

Original comment by jonathan...@google.com on 31 Aug 2015 at 11:46

• Changed state: NeedInfo

[GoogleCodeExporter]

Yes we are using the Cast Companion Library right now and are following it for 
our reconnection logic.

Original comment by i...@haystack.tv on 3 Sep 2015 at 7:05

[GoogleCodeExporter]

When did you first start seeing this issue?
Do you see it on any other devices (Android/iOS)?
Is more than one video playing on the device before it goes to sleep?
Just to double check, you're using the latest version of CCL, correct?

Original comment by jonathan...@google.com on 3 Sep 2015 at 10:31

[GoogleCodeExporter]

We are on CCL version 2.1.1. 

We observe the issue also when only one video is playing, it seems to have less 
to do with multiple videos and just how long the screen is off.

In house we are only seeing this on this Android Device running 4.2.2. (we have 
an iOS version but have not seen this problem there). We can't reproduce on 
newer versions of Android. 

Original comment by ish...@gmail.com on 3 Sep 2015 at 11:26

[GoogleCodeExporter]

Are you seeing this issue with the CastVideos app (from GitHub) as well?

Original comment by jonathan...@google.com on 4 Sep 2015 at 3:22

[GoogleCodeExporter]

We just tested with the latest version of CastVideos / CCL on GitHub and the 
issue is happening there as well. We cast the video and then the screen goes 
off. After about a minute we turn the screen on and the Chromecast has 
disconnected from the tablet, though the video keeps playing on the television.

Original comment by ish...@gmail.com on 4 Sep 2015 at 6:28

[GoogleCodeExporter]

So when the device wakes up and your wifi reconnects to the access point it was 
previously connected to, is the app still unable to reconnect to the Chromecast?
Also, what version of Google Play Services are you using?

Original comment by jonathan...@google.com on 4 Sep 2015 at 11:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After the screen turns off the wifi never drops on the device. After the user 
turns on the screen the device is no longer casting (i.e. although the TV still 
shows the session the device appears to have lost the connection). 

If the user taps on the chromecast icon then it successfully reconnects to the 
existing chromecast session.

The google play services version on the device is 7.8.99(2134222-030)

Original comment by ish...@gmail.com on 11 Sep 2015 at 12:18

[GoogleCodeExporter]

Can you run the CastVideos app, try to reproduce the issue there, capture the 
logs, and send them to us?

Original comment by jonathan...@google.com on 11 Sep 2015 at 5:38

[GoogleCodeExporter]

Hi there, attached here is the log we captured from running CastVideos and 
reproducing the issue.

Original comment by ish...@gmail.com on 15 Sep 2015 at 5:29

Attachments:

• cast_log.txt

[GoogleCodeExporter]

When you reproduced the error in #11, was that with CCL version 2.4?

Original comment by jonathan...@google.com on 15 Sep 2015 at 5:43

[GoogleCodeExporter]

Its CCL version 2.1. We can try it on 2.4 and let you know.

Original comment by ish...@gmail.com on 15 Sep 2015 at 5:57

[GoogleCodeExporter]

Yes, please do.

Original comment by jonathan...@google.com on 15 Sep 2015 at 5:58

[GoogleCodeExporter]

We re-checked and the CCL version was in fact 2.4 for the log report we sent 
out. The use case is working fine on all other devices except for the Nexus 7 
1st gen tablet. 

Original comment by ish...@gmail.com on 18 Sep 2015 at 5:29

[GoogleCodeExporter]

Please reproduce the issue again and make sure you're capturing the CCL logs. 
You can do  this by setting DEBUG=true in CCL in "LogUtils.java" class.

Original comment by jonathan...@google.com on 18 Sep 2015 at 6:35

[GoogleCodeExporter]

Were you able to reproduce the issue and get the CCL logs? If so, please 
provide them here.

Original comment by jonathan...@google.com on 25 Sep 2015 at 4:11

[GoogleCodeExporter]

Closing this ticket due to a lack of response. If you can provide the requested 
information, we can reopen the ticket and investigate further. 
We were not able to reproduce the issue on a V1 Nexus 7 running Play Services 
7.8.99, so it may be an issue with your device or network.

Original comment by jonathan...@google.com on 2 Oct 2015 at 7:27

• Changed state: Invalid

[GoogleCodeExporter]

Hi there, I apologize for getting back to you late on this as I was out on 
leave for a couple weeks.

We have re-tested this on the latest version of CastVideos and CCL (CCL version 
is now 2.5.2).

We are still seeing issues with the CastVideos app using the same test 
scenario, albeit slightly different. Both of these are running on the 
aforementioned Nexus 7 1st gen tablet running version 4.2.2 of Android. Google 
Play Services version 8.1.15. I'm attaching the logs with debug=true in 
LogUtils.java for each issue.

Issue 1: Cast button is no longer highlighted after screen turns off.

To reproduce:
1) Cast a video on the CastVideos app
2) After the video begins casting, turn off the screen (do not kill the app).
3) Wait a few seconds. You will see the connection is suspended in your logcat. 
Wait a few more seconds, eventually you will see some disconnection messages 
pop up.
4) Turn on the screen and unlock the phone. Notice that the cast icon is no 
longer lit. The cast session is working however (i.e. the client can still send 
commands to the session).

Issue 2: Pressing Pause button on lock screen after turning screen off causes 
cast session to be unresponsive.

1) Cast a video on the CastVideos app
2) After the video begins casting, turn off the screen (do not kill the app).
3) Wait a few seconds. You will see the connection is suspended in your logcat. 
Wait a few more seconds, eventually you will see some disconnection messages 
pop up.
4) Turn on the lock screen. Now press the pause button. You will see an error 
message in the logs. After this the app cannot send commands to the cast 
session.

Original comment by i...@haystack.tv on 14 Oct 2015 at 9:32

Attachments:

• Issue2_Session_unresponsive_after_lock_screen_pause.log
• Issue1_Cast_Button_no_longer_lit_After_turn_off_screen.log

[GoogleCodeExporter]

Make sure you have the setting to "keep Wi-Fi on during sleep" enabled on the 
device (as seen in 
https://support.google.com/nexus/answer/2819519?hl=en&ref_topic=3045814). If it 
is enabled and you're still getting Wi-Fi disconnects when the device goes to 
sleep, the issue may be related to 
https://code.google.com/p/android/issues/detail?id=42272 (see comment #34), in 
which case you'd either have to update your Android version or wait for the 
issue to be resolved. As I mentioned previously, we weren't able to reproduce 
your issue and after looking at the log files, we can't find anything that can 
pinpoint the cause of the issue so there's nothing further that can be done on 
our end.

Original comment by jonathan...@google.com on 15 Oct 2015 at 8:12

[GoogleCodeExporter]

Ok thank you!

Original comment by i...@haystack.tv on 15 Oct 2015 at 9:28