Closed GoogleCodeExporter closed 8 years ago
Could you provide full timestamped logs of both the sender and the receiver so
we can see what is happening on both sides? Also, how consistently can you
reproduce this?
Original comment by and...@google.com
on 20 Nov 2014 at 4:22
This is very easily reproducible, happens about 1/3-1/2 of the time.
Attached are both receiver and Android sender logs.
On the receiver, note the disconnect message at 11.004s, and on the sender at
23:43:53.071 onRouteUnselected - the user chooses to disconnect the app.
Original comment by mokesmo...@gmail.com
on 20 Nov 2014 at 10:06
Attachments:
Bottom line, as you can see: frequently when an Android user initiates a
disconnection, the receiver gets a message with
{"data":"{\"reason\":\"transport_closed\",\"senderId\":\"62:com.zz.myapp-12\",\"
type\":\"senderdisconnected\"} , which is then dispatched as an "unknown"
disconnection event. The disconnect event reason should of course be
"requested_by_sender"
Original comment by m...@juko.fm
on 21 Nov 2014 at 11:35
Verified that this occurs also with Google Play Services 6.5.87. In fact, on my
S4 running 4.4.2 this bug happens on almost every disconnect.
Original comment by m...@juko.fm
on 25 Nov 2014 at 6:20
Confirmed that it occurs both on Nexus S 4.1.2 and Samsung S4 4.4.2. The Nexus
S was using GPS 6.1 up until a few minutes ago when it received the 6.5 update.
On occasion when the user disconnects we get a "closed_by_peer" message which
leads to a "requested_by_user" disconnect event. More often we see a
"transport_closed" message which leads to disconnect reason: unknown
Original comment by m...@juko.fm
on 25 Nov 2014 at 7:12
I am also seeing this issue (Galaxy S4 4.4.2). Not sure when it started as
development has been focused in other areas. All I can say is at some point in
the last few months, the behavior has changed. My receiver app almost always
get a reason 'unknown' instead of the proper requested_by_sender.
Original comment by sakamoto...@myqubix.com
on 30 Nov 2014 at 5:12
@Google team, can you please prioritize this? Currently it's hard to know when
to shut down the receiver app due to this bug.
Original comment by m...@juko.fm
on 30 Nov 2014 at 6:20
sakamoto: could you please capture both sender and receiver log at the same
time so we can see what your sender is sending and what your receiver is doing;
you would need to turn on debugging in console and capture the log.
Original comment by anad...@google.com
on 30 Nov 2014 at 6:21
[deleted comment]
@Google, have you seen the logs 7 comments above this one? I can confirm the
logs are the same for GPS 6.1 and 6.5
Original comment by m...@juko.fm
on 30 Nov 2014 at 6:29
I have seen that and I asked for more logs to investigate. A new user reported
that and a new set of logs from the new user is valuable.
Original comment by anad...@google.com
on 30 Nov 2014 at 6:45
It is also very useful if anyone who can reproduce this could provide a better
log on Chromecast by using the Chromecast app on Android and sending a feedback
from there (making sure the box that the checkbox "Send Chromecast usage and
crash reports to Google" is checked and then send a feedback; that has more low
level information that can tell us with a lot more detail why receiver is
interpreting the disconnect reason as "unknown". To help us find that feedback
easily, please have the user enter "issue-416" string in the description of
feedback. When that is done, please let us know so we can look for the log so
we can investigate, thanks.
Original comment by anad...@google.com
on 1 Dec 2014 at 7:12
@Google, you can easily reproduce this with the CastHelloText-android app.
In MainActivity.java, inside onRouteUnselected change the teardown() call to
mApiClient.disconnect(); You will then easily see the unknown disconnect reason
bug.
Original comment by mokesmo...@gmail.com
on 4 Dec 2014 at 1:37
I can reproduce this easily, so I did that now and sent feedback using the
Chromecast app, as requested. I started my feedback description with
"issue-416", so it should be easy to find!
Original comment by erik.mid...@gmail.com
on 4 Dec 2014 at 2:03
we are investigating the issue.
Original comment by anad...@google.com
on 4 Dec 2014 at 5:41
It's happening in our app too, almost every time when sender disconnects.
tested on Samsung Note4- 4.4.4, Nexus5 Android 4.4.4.
i've attached sender and receiver logs as well. Expecting a fix for this soon
as this has a huge impact on receiver app behaviour.
Thanks,
Sri
Original comment by s...@spuul.com
on 8 Dec 2014 at 5:30
Attachments:
[deleted comment]
[deleted comment]
This will be fixed in an upcoming update.
Original comment by and...@google.com
on 6 Feb 2015 at 4:14
Any timeframe for the fix? Thanks.
Original comment by m...@juko.fm
on 11 Feb 2015 at 5:07
I will add that this issue now occurs EVERY time and not some of the time, as
before.
Original comment by m...@juko.fm
on 11 Feb 2015 at 8:01
Do you have the latest version of Google Play Services? If you still experience
the issue, could you send us a feedback report (please prefix the feedback
report with "Issue 416" so we can identify it quickly) and include in it what
type of receiver you are using (for custom receivers please include what you
are doing in the "onSenderDisconnected" callback for the receiver). Also,
please include the Android sender logs for the same session as the one in the
feedback report, so we can see what happens on both ends.
Original comment by and...@google.com
on 6 Mar 2015 at 5:13
Hmmm, now with GPS 6.7.76 it works fine.... there was a period where it behaved
well, then it again broke, now fixed again. All this without my relevant app
code changing. So looks good now, hope it stays this way this time :)
Original comment by m...@juko.fm
on 9 Mar 2015 at 10:39
I can confirm that with 6.5.99 the error occurs frequently. I have yet to see
it happen with 6.7.76
Original comment by m...@juko.fm
on 9 Mar 2015 at 12:50
Original comment by and...@google.com
on 9 Mar 2015 at 4:22
Original issue reported on code.google.com by
m...@juko.fm
on 27 Oct 2014 at 1:38