Cast Extension on Windows, API always returns no devices

[GoogleCodeExporter]

1. In windows 7 install either cast extension or cast extension beta
2. Clicking the extension will show the chromecasts on the network correctly, I 
can cast to them from the extension or from inside youtube.
3. My page with chromecast code, when the API initialized the callback always 
returns e as chrome.cast.ReceiverAvailability.UNAVAILABLE

This code works perfectly on mac and on linux. All windows (I've only tested on 
7) machines don't work. I've tested on 2 different networks both wired and 
wireless.  

Original issue reported on code.google.com by mor...@gmail.com on 21 Feb 2014 at 6:09

[GoogleCodeExporter]

This is common issue among Windows users.  See this post: 
https://plus.google.com/+ShawnShen/posts/XfcKKeR4Y84 to get more info on what 
to try.

Original comment by shawns...@google.com on 21 Feb 2014 at 6:16

• Changed state: Acknowledged

[GoogleCodeExporter]

Its none of the items described in your post.

I can confirm this happening on 4 computers on 4 networks, 3 chromecasts.

The chromecast works flawlessly in every other circumstance.eg, casting a tab, 
sending a youtube clip from the chrome browser.

Original comment by mor...@gmail.com on 21 Feb 2014 at 6:25

[GoogleCodeExporter]

The app is already published so its can't be linked to the device ID.

Original comment by mor...@gmail.com on 21 Feb 2014 at 6:29

[GoogleCodeExporter]

Have you tried to change Windows Wifi from public to home?

Original comment by shawns...@google.com on 21 Feb 2014 at 6:30

[GoogleCodeExporter]

Yes, its on home and work, never on public.

Original comment by mor...@gmail.com on 21 Feb 2014 at 6:45

[GoogleCodeExporter]

As a seasoned programmer, I'm gonna guess that the bug is not when extension is 
searching for a chromecast, rather when the extension is telling the JS script 
whether a device exists.

Reason: 
1. Clicking the chromecast extension button shows the device
2. The logs that you just released in the beta version of the extension also 
shows the device available

Original comment by mor...@gmail.com on 21 Feb 2014 at 6:52

[GoogleCodeExporter]

I've also had dozens of reports of this bug.

They are able to Cast tabs, Youtube, Netflix, etc.. The UNAVAILABLE error 
happens, too. Not related to any of the fixes in the second post. 

Original comment by mathieu....@matbee.com on 23 Feb 2014 at 6:16

[GoogleCodeExporter]

Well guys, there is something fishy about this. I have tried every avenue I can 
think of, but the chrome.cast.ReceiverAvailability.UNAVAILABLE is always 
returned to my simple sender app. I'm on Win 7.
I'm using the default app ID, but have registerd my ChromeCast device.

The extension for Chrome works as expected and so does Netflix (close down 
bug), YouTube and my iOS apps.

Now what?

/Regards

Original comment by ClasLePetit on 23 Feb 2014 at 8:46

[GoogleCodeExporter]

I'm having the exact same issues on another Windows 7 machine.
Casting tabs works fine, YouTube and Netflix work fine, any app attempting to 
use the newer version of the cast API seems to be failing. 

Network is set to "Home", I've disabled Windows Firewall.

I did some digging through the Google Cast extension code and there's a 
function that I assume is supposed to return the listing of Chromecast devices 
that support the provided appId. My Linux machine always has the complete list 
of devices while Windows 7 is always an empty array.

Original comment by gra...@kennery.com on 23 Feb 2014 at 10:20

[GoogleCodeExporter]

For those who are having trouble, can you please click on the Cast extension 
icon and follow the pop-up to click "Send feedback..." to send logs to us so 
that we can do more debugging of this mDNS issue?

Original comment by shawns...@google.com on 24 Feb 2014 at 7:45

[GoogleCodeExporter]

Can you also try going into the Network and Sharing Center, click on Change 
Adapter Settings, press Alt-N to open the Advanced settings menu, choose 
Advance Settings, and make sure that the network interface used to interface 
with Chromecast is moved to the top of the list?

Original comment by markdavi...@google.com on 24 Feb 2014 at 9:26

[GoogleCodeExporter]

^-- That doesn't fix it. Tried it on numerous users computers.

Original comment by mathieu....@matbee.com on 24 Feb 2014 at 9:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As shawnshen had mentioned, please send us feedback through the cast extension 
itself, attache the logs to your feedback and use "issue159" (no space) as a 
tag so we can find them among all other feedbacks. After submitting your 
feedback, please drop us a note here to make sure we don't miss your 
submission; we need your help to debug this issue, thanks.

Original comment by anad...@google.com on 25 Feb 2014 at 1:31

[GoogleCodeExporter]

Thanks all you guys at google for looking into it.

A little weird thing my colleague found. It works on his macbook with a windows 
7 vm (virtual box), but not when booted into windows 7. 

Original comment by mor...@gmail.com on 25 Feb 2014 at 1:38

[GoogleCodeExporter]

Just submitted from my Windows 7 machine!

Original comment by gra...@kennery.com on 25 Feb 2014 at 1:41

[GoogleCodeExporter]

Graham, did you use "issue159" (without any space in between)?

Original comment by anad...@google.com on 25 Feb 2014 at 1:43

[GoogleCodeExporter]

Indeed, I did!

Original comment by gra...@kennery.com on 25 Feb 2014 at 1:45

[GoogleCodeExporter]

I've instructed users and a few of them have responded, but I can't say that 
they used "issue159" with no space. That being said, "issue 159" is what some 
have used before knowing to use no spaces.

Original comment by mathieu....@matbee.com on 25 Feb 2014 at 1:50

[GoogleCodeExporter]

I've filed multiple logs. Two for each of the CastHelloVideo sender example 
from GitHub and two from Chromecast Video App for Chrome from groupnotes.ca.
(resending with the issue159 tag) - would the log from the Chrome JavaScript 
console make it better?

Original comment by ClasLePetit on 25 Feb 2014 at 2:13

[GoogleCodeExporter]

This is the URL my Chrome sender app is using to get the sender API
"chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm/cast_sender.js"
.where that long number of course is the extension id.
Is that the correct version of the API?
No version noted within the code. Is there a call, that returns version.sub 
version?

Original comment by ClasLePetit on 25 Feb 2014 at 3:05

[GoogleCodeExporter]

I am a bit confused; why are you not using the following in your sender app:

<script type="text/javascript" 
src="https://www.gstatic.com/cv/js/sender/v1/cast_sender.js"></script>

Original comment by anad...@google.com on 25 Feb 2014 at 5:25

[GoogleCodeExporter]

^-- that's exactly what that script does.

Original comment by mathieu....@matbee.com on 25 Feb 2014 at 5:28

[GoogleCodeExporter]

I am not familiar with chrome extensions. Assuming it does exactly that, would 
be the advantage of that over simply calling out the script directly?

Original comment by anad...@google.com on 25 Feb 2014 at 5:32

[GoogleCodeExporter]

Simply offline ability and keeping all resources...inside.

Original comment by mathieu....@matbee.com on 25 Feb 2014 at 5:36

[GoogleCodeExporter]

You will not be able to do anything offline. regardless, it is hijacking the 
original issue, so I'll stop here.

Original comment by anad...@google.com on 25 Feb 2014 at 5:38

[GoogleCodeExporter]

Hi, I have same issue at windows 7.
Then I test windows 8 is work, ubuntu also work.
all test used same sample sender.

Original comment by sinc...@gmail.com on 25 Feb 2014 at 3:20

[GoogleCodeExporter]

sincoew: please read the thread in this issue and follow the steps to submit a 
feedback with the requested tag and then let us know when you are done, thx.

Original comment by anad...@google.com on 25 Feb 2014 at 3:22

[GoogleCodeExporter]

Had my first bug report from an OSX user which had exactly this problem. He 
sent the logs just a minute ago. 1:05 AM EST.

Original comment by mathieu....@matbee.com on 27 Feb 2014 at 6:08

[GoogleCodeExporter]

To collect more data and help us resolve the problem, we’d like users to 
perform the following steps and provide the resulting information to help us 
narrow down what’s causing the issue.

(1) Submit feedback.  Use the “Send Feedback” option from the Cast 
extension menu, and refer to the issue (e.g. issue159) in the description.  
This will give us OS, Chrome, Cast extension versions + basic logs (which 
should confirm that mDNS finds no devices whereas DIAL does).  Feedback should 
be submitted while signed in so we can correlate feedback with other 
information provided by the user. 

(2) Confirm issue repro:  Does this happen 100% of the time on the affected 
machine or only occasionally?  Which of these, in order, resolves the problem?
Restarting the extension (via chrome://extensions, toggling the “Enabled” 
checkbox with developer mode turned on)
Restarting Chrome (use Menu -> Exit and ensure no Chrome processes are running)
Restarting Windows

(3) Provide IP configuration.  Open a Command Prompt, run “ipconfig /all”, 
and provide a copy of the output.  This will provide some data on how 
networking is set up on affected machines.

(4) Collect detailed Chrome logs (optional).  Assuming that the issue repros 
across Chrome restarts, exit Chrome (confirming all processes have stopped), 
and restart with logging enabled.  To do this:

(4a) Open a Command Prompt and go to the directory where the Chrome binary is 
installed.  This is typically either “C:\Program Files 
(x86)\Google\Chrome\Application”, or 
“C:\Users\<username>\AppData\Local\Google\Chrome\Application”. Chrome 
Canary will be in “Chrome SxS” instead of Chrome.

(4b) Run chrome.exe  
--vmodule="mdns*=1,cast_*=1,dns_sd*=1,local_discovery*=1,service_discovery*=1" 
--enable-logging.  (Text in italics is a single line).

(4c) Verify that you’re unable to launch a v2 application, then exit Chrome.

(4d) The debug log should be contained in a file called “chrome_debug.log” 
in your user data directory (typically 
“C:\Users\<username>\AppData\Local\Google\Chrome”).

(4e) Note that debug logs contain verbose information, so please ensure no 
personal tabs or information was open, and that you are comfortable with 
information being submitted.

(5) Collect Wireshark traces (optional).  If you’re comfortable and have 
Wireshark installed, collect a trace while performing step # 4 to provide 
visibility about what’s happening at a network level.

When providing (2) and (3), this information is not sensitive and can be shared 
via E-mail or public bugs - though even better is copying & pasting into the 
feedback report.  The information in (4) or (5) should not be posted publicly, 
and should be shared using Google Drive explicitly with a Google devrel account 
for internal analysis (anaddaf@google.com).

We greatly appreciate the assistance in resolving the issue. 

These steps are also outlined in the attachment (Troubleshooting.pdf) if you 
want to look at a nicely formatted version of the instructions.

Original comment by anad...@google.com on 28 Feb 2014 at 7:18

Attachments:

• Troubleshooting.pdf

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Done up to and including (4)

Original comment by ClasLePetit on 28 Feb 2014 at 8:20

[GoogleCodeExporter]

We have made some headway with the issue. To confirm our findings, it would be 
useful to see how many of the folks who are running into this issue have AVG 
firewall installed on their box (even if it is disabled)? Please drop a note 
here to let us know one way or the other. If you are not using AVG but are 
using a different firewall, please let us know about that too. Thanks.

Original comment by anad...@google.com on 2 Mar 2014 at 12:03

[GoogleCodeExporter]

The 2 computers I looked at have avast, i tried with it enabled and disabled.

Original comment by mor...@gmail.com on 2 Mar 2014 at 12:56

[GoogleCodeExporter]

Running into same issue (already submitted "issue159" feedback via extension).  
Don't have AVG, but do have Trend Titanium Maximum.  I've disabled it 
completely, and also have turned off Windows Firewall and disabled all network 
adapters except for the wifi network with the Chromecast, and I'm still getting 
the error.  Only happens with a custom receiver app and the Chrome API.  
Youtube, Netflix, and others work fine from Chrome.  In my sender app, the Cast 
API seems to initialize fine, but the receiverListener() callback from 
ApiConfig returns "unavailable".  This has been consistent no matter what I've 
tried.  My Mac on the same network can cast my custom receiver app with no 
problems.

Original comment by daseym...@gmail.com on 2 Mar 2014 at 4:19

[GoogleCodeExporter]

We believe we have an understanding of where the issue is coming from (it is 
caused by the "presence" of Anti Virus software such as AVG); even if you 
disable them, the issue still manifests itself. We are working on a solution 
based on our findings.

If, however, you are running into this issue and you do not have any Anti Virus 
software installed (Note: disabling them is not enough), please let us know 
since that would be pointing to a different issue that would need a different 
solution.

Thank you for your patience and collaboration, special thanks to ClasLePetit 
who provided valuable debugging info for us.

Original comment by anad...@google.com on 5 Mar 2014 at 6:03

[GoogleCodeExporter]

Can confirm completely.

I totally uninstalled Avast, restarted and it works. (I have no idea why, but 
I'm terrified of running windows without antivirus)

Can everyone who had the issue please test and let us know which antivirus they 
were using.

Mordy

Original comment by mor...@gmail.com on 5 Mar 2014 at 6:24

[GoogleCodeExporter]

Very likely related to this bug in Chromium

https://code.google.com/p/chromium/issues/detail?id=348692

Original comment by mor...@gmail.com on 5 Mar 2014 at 8:21

[GoogleCodeExporter]

I have the same issue on a Linux server (Fedora FC20) as well as on a Windows 7 
machine. So not Windows specific in my case. I have tried all of the 
suggestions on this and other boards to no effect. In addition to suggestions 
on this page, I have added the Linux machine IP address to the Cast SDK domain, 
used server IP address in the URL, tried an external site hosting one of the 
demo apps (http://www.videws.com/eureka/helloVideos/) suggested on 
Stackoverflow, etc. I have also sent a report via Chromecast with logs attached 
(ref issue 159) from the Linux machine. Obviously the Linux machine is NOT 
running any of the Windows Anti Virus programs.

Any suggestions

Original comment by ecand...@gmail.com on 5 Mar 2014 at 8:42

[GoogleCodeExporter]

ecanderl,
I may have missed it but did you notify us when you sent your report?

Original comment by anad...@google.com on 5 Mar 2014 at 8:44

[GoogleCodeExporter]

I submitted feedback from (from the cast icon on the Linux server),
attached the logs and referenced issue159 (no space). From reading the
thread, it appeared that was how you preferred to get feedback.  I can send
again or send in a different way if you would like.

Then I added a similar comment to the issue 159 thread at
code.google.com
<https://code.google.com/p/google-cast-sdk/issues/detail?can=2&start=0&num=100&q
=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&s
ort=&id=159>
which
is where I found the best match for the problem that I am seeing, with the
exception that my issue is not limited to just Windows 7.

Original comment by ecand...@gmail.com on 5 Mar 2014 at 9:00

[GoogleCodeExporter]

ecanderl,

Thanks. What was the date that you submitted your Linux log? 

Original comment by anad...@google.com on 5 Mar 2014 at 9:04

[GoogleCodeExporter]

Within minutes (prior) to adding the comment to the issue 159 thread.

Original comment by ecand...@gmail.com on 5 Mar 2014 at 9:06

[GoogleCodeExporter]

I used AVG 2014 Internet Security, and was only able to make the apps work with 
the Chrome flag --no-sandbox

After unistalling AVG completely and restarting the computer, the situation is 
the same. Empty device list, unless I bail out of the sandbox, sorry

Even with the Windows firewall down, no luck. I still have to step out of the 
sandbox

Original comment by ClasLePetit on 5 Mar 2014 at 9:39

[GoogleCodeExporter]

FYI, went back to Windows to try the "--no-sandbox" suggestion. This did work 
for me on Windows.

It also brought up the Styled Receiver that I had registered and was using in 
the "CastHelloVideo-chrome-master" demo application. I expect going back to the 
default receiver would work as well. I did get warnings from chrome that this 
was not a supported option and stability and security could suffer as a result. 
Ignored those for the purpose of testing.

I tried to run chrome on the Linux machine in the same way, but received an 
error as things were starting up on chrome. It looks like it would take a bit 
of work to make the "--no-sandbox" for chrome on Linux; things died with the 
following error on Linux:
 [13831:13831:0100/000000:ERROR:zygote_linux.cc(546)] write: Broken pipe
[0305/170119:ERROR:nacl_helper_linux.cc(236)] NaCl helper process running 
without a sandbox!
Most likely you need to configure your SUID sandbox correctly

Chrome Version on Windows / Linux is up to date: 33.0.1750.146 m / 33.0.1750.117

Chromecast extension on Windows / Linux also looks current: 14.123.1.5 / 
14.123.1.5

I will update you if I am able to get the Linux Chrome installation to behave 
in a similar manner.

Thanks,

Ewald

Original comment by ecand...@gmail.com on 5 Mar 2014 at 10:44

[GoogleCodeExporter]

Admittedly, I'm no expert on the sandbox, but it may be less forgiving in some 
versions of Chrome. My guts feeling (for what it's wirth and not knowing the 
code) is that this is a issue of cross domain scripting...

Original comment by ClasLePetit on 5 Mar 2014 at 10:53

[GoogleCodeExporter]

Good news -- was able to confirm that disabling the Chrome sandbox on Linux 
worked as well. The command is a bit different on Linux:

google-chrome --disable-setuid-sandbox

I did get one error immediately after Chrome started up:

[15281:15290:0305/183833:ERROR:cert_verify_proc_nss.cc(857)] 
CERT_PKIXVerifyCert for 192.168.120.152 failed err=-8179

There were no errors while running the sample apps and everything else appeared 
to function properly. The above error did not appear to do any harm as far as I 
can determine, but have not looked at things in a very exhaustive manner yet.

I hope that there is a more general solution since this is at best a very good 
work around to unblock my development for the moment. However, it is not clear 
how web / chrome applications can be deployed more generally without a more 
general fix.

Thanks,

Ewald

Original comment by ecand...@gmail.com on 5 Mar 2014 at 11:51

[GoogleCodeExporter]

Keep up the good work guys!

Original comment by ClasLePetit on 6 Mar 2014 at 1:29

[GoogleCodeExporter]

Thanks for all the feedback and repro steps everyone, as well as for confirming 
that --no-sandbox corrects the problem.

In our tests this was caused by antivirus software (or, I suppose, potentially 
other things that inject the Chrome binary, per the point above that a full AVG 
uninstall did not fix).  

A change has been landed in Chrome that should work around this issue without 
requiring --no-sandbox.  This should be available on Chrome canary starting 
tomorrow, with version 35.0.1875.0 (or higher).  We'd appreciate feedback on 
whether this addresses the issue for folks on the thread; canary installs 
separately from your main Chrome install, so hopefully you can give this a try 
without risk of disruption.

Original comment by markdavi...@google.com on 6 Mar 2014 at 9:01

[GoogleCodeExporter]

[deleted comment]