Closed GoogleCodeExporter closed 8 years ago
I've found a reproduceable case:
Windows 7, Avast! Anti-virus.
When Chrome is NOT RUNNING (No chrome.exe processes whatsoever) - launch
Videostream using the Chrome App Launcher.
This might be out of the scope of the Cast extension issue tracker but some
support on this if I escalate it would be much appreciated.
I'm digging into other OS/Anti-virus combos now.
Original comment by gra...@kennery.com
on 4 Dec 2014 at 5:02
Confirmed to be an issue on Windows 8.1, Avast, Chrome App Launcher.
Original comment by gra...@kennery.com
on 4 Dec 2014 at 5:18
Original comment by na...@google.com
on 4 Dec 2014 at 6:55
Are you still facing the issue? If so please let us know Chrome and Chromecast
extension version you are experiencing the issue on.
Original comment by na...@google.com
on 13 Mar 2015 at 11:47
Yes - this is still happening to MANY of our users.
I can reproduce it with:
Windows 8
Cast Extension: 15.226.0.1
Chrome: 42.0.2311.22 m (64-bit)
NO ANTIVIRUS
The steps to reproduce are as follows:
1. Install Videostream
2. Kill ALL chrome.exe processes (Ensure NOTHING is running)
3. Open the Chrome App Launcher
4. Launch Videostream
5. Attempt to cast
The Chromecast API appears to be initialized correctly but will return
receiver_unavailable. If you attempt to cast, it will cast the TAB instead.
This appears to be a timing issue. With faster systems, the ability to
reproduce is low. To mitigate the issue, we are delaying the call of:
chrom.cast.initialize for a few seconds and it seems to fix on a few systems.
We have a system that requires a delay of EIGHT seconds before it reliably
initializes correctly.
Original comment by gra...@kennery.com
on 16 Mar 2015 at 5:25
[deleted comment]
Could you please send a feedback report from the cast extension after you
successfully reproduce the issue. Please prefix it as "for Issue 442". Here's
how you can do it (just in case):
https://support.google.com/chromecast/answer/3187017?hl=en
Original comment by na...@google.com
on 16 Mar 2015 at 7:00
Sent a bunch of feedback reports with various steps taken - they all were
prefixed with, "for Issue 442" and the list of steps taken within each report.
All of them were started with Chrome in a completely closed state.
A few of them, I clicked the cast extension only to have "Tab Casting" work
A few others, I selected a video and allowed Videostream to tell me receiver is
unavailable - clicking the extension gives me the "tab casting" option
I also tried reloaded the page, and the cast SDK and extension worked perfectly
fine.
Through all of these, even with the SDK in a "broken" state - it still injects,
initializes as normal, and responds with "receiver_unavailable". There doesn't
seem to be a way to detect when we enter this state - everything seems normal.
Original comment by gra...@kennery.com
on 17 Mar 2015 at 6:17
Cast extension scans Chromecast devices first to make sure videoStream's appId
is supported on each device.
Could you tell me the delay from your app started and your
chrome.cast.ApiConfig's receiverListener got invoked with
chrome.cast.ReceiverAvailability.AVAILABLE?
chrome.cast.ReceiverAvailability.AVAILABLE means at least one device exist that
told Cast extension the app ID you provided is supported.
I found the feedbacks you submit, however, they do not have fine logs to allow
me find out when Chromecast device responded with appID available message. Do
you mind submitting another feedback with fine logs?
1. Open the console of the Cast extension.
2. enter
localStorage['includeFineLogsInFeedback'] = true
3. restart Chrome, or disable/re-enable the Cast extension.
4. reproduce the issue
5. submit the feedback the same way. You will see a warning paragraph in red
"Warning - Detailed logging is enabled;"
You can enter "delete localStorage['includeFineLogsInFeedback']" in the Cast
extension console and then restart to disable submitting fine logs.
Original comment by haibi...@google.com
on 8 Apr 2015 at 12:48
Logs have been sent, did a number of different flows, the only success was when
we added a five second delay before calling chrome.cast.initialize
New logs are prefixed with "For Issue 442 - Round two"
Original comment by gra...@kennery.com
on 8 Apr 2015 at 4:20
Thanks for the logs! It is initialization race condition unique to app
launcher, tab loaded before extension finished loading. At the mean time,
please continue using 5 second delays before calling chrome.cast.initialize
Original comment by haibi...@google.com
on 8 Apr 2015 at 6:49
Google Cast (Beta) 15.408.1.1 has the fix. Please give it a try.
Original comment by haibi...@google.com
on 10 Apr 2015 at 11:09
Closing this issue since there is no response from @graham.
Please respond back in this thread, if you tried Google Cast (Beta) 15.408.1.1
and it didn't solve the issue and we would gladly reopen the ticket.
Original comment by na...@google.com
on 5 May 2015 at 2:34
Original issue reported on code.google.com by
gra...@kennery.com
on 4 Dec 2014 at 3:50