wrong url announced

[DDanilo]

On Windows 10 the url announced is malformed:

Example app listening at http://false:50470

i can connect to Chromecast TV from the taskbar icon and see the cast icon appear on TV but no audio. Maybe is correlated with the wrong URL ? Tested while connected only to WiFi network.

========= Log from cmd =================== VIRTUAL DEVICE FOUND 10.173.20.130 ChromecastTest connected, launching app ... http://**false**:50470/ app "[object Object]" launched, loading media [object Object] ... status broadcast playerState=undefined media loaded playerState=undefined

[matbee-eth]

false?? Oh that's a bug.

[DDanilo]

Forgot to mention that stream works well via browser on localhost

[Fred688]

I seem to be getting this same issue with the current windows version:

audio-cast.exe "C:\Users\XXX\Desktop\audiocast\resources\bin\driver\win32\RegSvrEx.exe" /c C:\Users\XXX\Desktop\audiocast\resources\bin\driver\win32\audio_sniffer.dll" C:\Users\XXX\Desktop\audiocast\resources\bin\ffmpeg\win32\ffmpeg C:\Users\XXX\Desktop\audiocast Example app listening at http://false:53865 Selected Audio Device: 10.1.1.30 Audio1 10.1.1.25 Sharp Spawned Ffmpeg with command: ffmpeg -list_devices true -f dshow -i dummy pipe:1 VIRTUAL DEVICE FOUND

Is there a work-around for this?

[estrasnick]

I had this same issue, and I modified the source code to resolve it and get the audio working. I'm hoping that this will help @acidhax to resolve the issue, but for those looking for an immediate fix, I'll post the solution below. You'll need to work with the source code, which you can compile using grunt as shown in the readme:

(note that I still have a million exception error messages popping up - I'll resolve that later)

This issue arises from the following code in src/lib.js:

getIp() {
        var ip = false
        var alias = 0;
        let ifaces = os.networkInterfaces();
        for (var dev in ifaces) {
            ifaces[dev].forEach(details => {
                if (details.family === 'IPv4') {
                    if (!/(loopback|vmware|internal|hamachi|vboxnet|virtualbox)/gi.test(dev + (alias ? ':' + alias : ''))) {
                        if (details.address.substring(0, 8) === '192.168.' ||
                            details.address.substring(0, 7) === '172.16.' ||
                            details.address.substring(0, 5) === '10.0.'
                        ) {
                            ip = details.address;
                            ++alias;
                        }
                    }
                }
            });
        }
        return ip;
    }

I debugged this loop and found that my IP wasn't getting recognized because it did not start with any of the three prefixes above (mine was 10.30.x.x). While these are the standard private address prefixes, they may not be appropriate depending on your network configuration.

In order to solve this bug, you will need to determine the IP prefix for devices on your network, and add in an additional substring check like so:

                            details.address.substring(0, 8) === '192.168.' ||
                            details.address.substring(0, 7) === '172.16.' ||
                            details.address.substring(0, 5) === '10.0.' ||
                            details.address.substring(0, 6) === '10.30.'

Note that the second argument in the call to substring() must be set based on the length of the prefix. If your prefix is something other than 10.30., you will need to determine what to add. If you have audio devices listed, you can find the prefix there. Otherwise,an easy way to do this is to add a print statement like this into the code just above the if statement that checks the IP prefixes, recompile and run, and observe the address that gets printed:

console.info('Valid address: %s', details.address);

Ideally you have just one IP printed, and you can take the prefix from that.

Hope this helps someone. @DDanilo you should try adding 10.173. @Fred688 try adding 10.1.

@acidhax - I'm happy to issue any pull request if you'd like, but clearly this solution won't work for all possible IPs, and a broader change could solve this issue in a more generalizable fashion. I'm not familiar with all commonly used IP prefixes, but at the very least I can't help but suspect that there's a simpler way to determine the correct IP without going through this seemingly unreliable matching. Let me know if I can help or test anything else on my (apparently unique) network configuration.

[Bones12345]

Sounds like details.address.substring(0, 5) === '10.0.' should simply be changed to details.address.substring(0, 3) === '10.' to me (10.anything is private, AFAIK). Thanks!

[matbee-eth]

It's entirely possible to detect the correct IP address--- however not with the default audio streaming chromecast app. You get in trouble when you introduce people connected to a VPN, and auto detecting network IP fails.

That being said, a PR would solve it for some.

[mcprat]

You can always just have README directions for people with VPNs and proxies...