Closed randomascii closed 4 years ago
Thanks, nice feature. It happens every now and then that the firewall rules aren't right, even after selecting 'Allow' at first launch.
The time between the application sends 'LOAD' to the device and an incoming connection is received shouldn't take more than 10 - 15 seconds. I'm thinking about a nice way to display a message, and to prevent too much false alerts...
In my case I gave permissions for private networks but not public. Is it expected that this is insufficient? I'm putting together a PR for the documentation to clarify this and I'd like to make sure I'm clarifying this correctly. Once I opened up the firewall for public networks everything worked properly.
Thanks for creating this!
I didn't know the exact difference between private and public myself, this article explained it to me.
In my case the wifi connection was 'Public' that's why I needed the 'Public' rule in the firewall. After changing the wifi connection to 'Private' keeping only the 'Private' rules in the firewall was sufficient.
Good point to add some more documentation about it. Maybe add an extra line in the README.md, and a further clarification in the wiki!?
Huh. Apparently my home WiFi was set as a public network, which was causing me great confusion. Anyway, diagnosing this would be nice and I just sent a PR for possible documentation enhancements.
I was also confused, public is the default in Windows 10 I guess. I merged the pull request, thanks! I will look at the code changes later.
My experience has been that a few months ago an update to Windows changed the network from private to public. I don't know why that happened. In any event, the network should be private. I recently did a clean install of Windows and the network was automatically setup as private as part of the install.
Setup 2.5.4.zip checks if it takes too long (> 15 seconds) for the device to connect to the application to load the stream.
If so the device box turns pink with the status 'Check Firewall'. After the firewall rules are changed the application recovers without restarting.
Does it work for you? What do you think of it like this?
That sounds perfect. I won't get a chance to test it for a little while, but don't wait on me.
No hurries. I hope someone else can test it before I create a new release. In 2.5.5 I added a fix for when the stream is already loaded before connections are blocked by the firewall.
It's in release 2.6.
I realize this issue is closed, but would like to add a comment, and perhaps a question:
I have discovered that Windows updates routinely change the Local Network from Private to PUBLIC, and this kills a number of things, including DAS. I found a Microsoft forum that discussed this, and evidently this action has been happening for more than a few years. Suggestions in that form from Microsoft have been ineffictive...
SO, a "Check Firewall" message/notation in DAS might be better worded as "Check Firewall & Wi-Fi Privacy Status"
AND: Does anyone here have a working solution to prevent a Windows update from changing this setting?
Thanks!... I didn't expect any solutions to Microsoft's changing the Privacy setting, but thought I'd post the question just in case anyone else reading this has some suggestions.
AND, wanted all DAS users to be aware of Microsoft's sneaky behaviour...
By the way, I just read the additions in the Wiik & Homepage about the Firewall issues: ".....(public or private) for audio to play."
In my experience, the Local Area Network MUST be set to Private for DAS to cast/stream. Windows 10 is notorious for arbitrarily changing this setting to back "Public". I also learned that this setting must be checked on every PC on the Network, because each one manages how it views the Network independent of how it is set on other devices.
I did a test:
So 'Public' is also possible.
So you are confirming that after changing the network to PUBLIC, you saw "Check Firewall", but it didn't prevent streaming...
In my cases, the "Check Firewall" message appears on the bottom of a Speaker Group in the Device list, and the box is no longer Green, but is a brownish-orange. Clicking on the Speaker Group does NOT cause it to resume streaming.
I guess there are other variables at play here...
At any rate, once I got my Wi-Fi set back to Private, DAS has been streaming for more than 10 hours.
On Public it started streaming AFTER I added a rule for DAS in the Windows firewall (allow Public).
Thank you for the clarification!...
I probably won't make that change, because DAS' "Check Firewall" is likely the first alert I would notice when Microsoft has changed my Network back to Public. I haven't yet identified any valid reason for it to be Public, so I like the Warning that DAS gives me!
Windows continues to switch my network from Private to Public... It seems to happen whenever my Gateway (Modem + Router) is rebooted. Where is the setting you depicted here?:
Thanks!
That is, I opened Windows Defender Firewall with Advanced Security, but could not find a process that would let me enter DAS as "ChromeCast.Desktop.AudioStreamer"
"ChromeCast.Desktop.AudioStreamer" is already in de list when you go to the inbound rules. Rightclick the item, choose Properties, go to the Advanced tab, there you can check both Public and Private. That should work for you!
THANK YOU!...
There are 4 entries for DAS in my Inbound Rules, 2 Public and 2 Private... Both of the Public entries have "Block the connection" selected on the 'General' Tab. (See annotated screen shots). I am assuming if I select one of the "Allow..." choices, it will enable DAS to play/stream if my Network has been switched to Public, is that correct?
The REAL issue, though is how to prevent Windows from changing the network to Public... {I've found a few discussions on that topic, but no real solution so far.}
That's correct, 'Allow' will enable DAS for 'Public' too. I don't know how too lock 'Private'.
When I first installed this it could connect to my Chromecast Audio and would play sound when adjusting the volume, but it couldn't forward the music that I was playing. I eventually found that adjusting the firewall rules fixed the problem. I suspect that this is a common mistake so it might be good for the application to detect this problem (failure to play for n-seconds?) and display a message suggesting what the user should do.