Unable to find chromecast with "Render" Stuck on "Scanning"

[Disco]

Hi,

I've just come across this issue as yesterday it was working fine. But I am unable to cast any videos. It gives me the option of either "Local" or a greyed out "Scanning". I have tried reinstalling to no avail.

I have the latest version of VLC Player. (VLC 3.0.3)

Thanks

[Disco]

main debug: looking for renderer probe module matching "any": 1 candidates
main debug: no renderer probe modules matched
qt debug: starting renderer discovery service mDNS renderer Discovery
main debug: looking for renderer_discovery module matching "microdns_renderer": 1 candidates
microdns debug: mDNS: listening to _googlecast._tcp.local renderer
main debug: using renderer_discovery module "microdns"

[Disco]

chromecast works through chrome and everything else just not VLC

[InTheWings]

If that does not show in chrome, then that's not a vlc issue

[cdlag]

I have the exact same problem with vlc 3.0.3 on a Dell XPS 13, has anybody found a solution? It looks like Windows Surface experienced the same problem, and the Dell XPS is almost like a Surface, so that is maybe where the problem comes from...

[laionidas]

I'm having a similar problem with my Chromecast Audio, and made a thread about it before.

I'm also pretty sure that the problem lies with VLC: it worked fine before, and I only started having issues recently. After all, Chromecasts itself or my Wifi network have not changed, and only VLC has been updated.

[Jean-Baptiste Kempf]

Yeah, it could be, but it's hard to guess the issue, since this is mostly related to networking problem.

[scojack]

I have the same exact problem of Disco and cdlag

VLC 3.0.3 Vetinari 64 bit

Windows 10 Pro X64 Build 1803 April 2018 Update

I think the issue started after 1803 update

The issue seems to be impossibile to find Chromecast device. It ìs interesting that cast is possible executing VLC from command line as found on this topic:
https://forum.videolan.org/viewtopic.php?t=143114

Code: Select all

"C:\Program files\VideoLAN\VLC\vlc.exe" "path_to_file_video_files" --sout "#chromecast" --sout-chromecast-ip=<Chromecast IP address> --demux-filter=demux_chromecast

The strange thing is that *sometimes* VLC find Chromecast, but many times stucks on "scanning" with non apparently reason.

The same chromecast device is always found by several Android devices and Ipad with no problema

Everyone have any ideas to track and solve this issue?

Thanks in advance!

Giacomo

[Jean-Baptiste Kempf]

Android with VLC or?

[scojack]

Sorry.. i don't understand what are you asking for..
Anyway..

Issue present on VLC 3.0.3 64bit on Windows 10 Pro PC Version 1803 : can't find Chromecast (no chromecast shown in Playback > Renderer : just "Local" and stuck on "scanning") but cast is possible if VLC is started from cmd with --sout etc.. arguments)
It is very probable that issue comes up after 1803 update
On same PC it is possibile to find and cast to chromecast with Chrome

On same WIFI Network it is possible to find and cast to same chromecast device from Android VLC 3.0.11
On same WIFI Network it is possible to find and cast to same chromecast device from Ipad with VLC for iOS 3.1.0

Thanks!

Giacomo

[Jean-Baptiste Kempf]

Yes, so there is something blocking VLC from accessing the network on the machine.

Indeed, discovery of the chromecast is mDNS (multicast), to guess the address. After, that sout is direct access...

Do you have a firewall?

[Jean-Baptiste Kempf]

Is VLC installed in the Program FIles location?

[scojack]

Hi Jean-Baptiste Kempf! Thanks for your reply

Yes, VLC in installed in the Program Files location that is C:\Program Files\VideoLAN\VLC\

I have Windows Firewall but i also tried to disable it and open VLC: still stuck on Scanning e no chromecast device is shown.

Any other ideas?

Repeat: I'm pretty sure that issue started after Windows 10 Aprile 2018 update. Maybe is something changed in that update?

Thanks

[Jean-Baptiste Kempf]

It is very possible that this changed things, but what?

[scojack]

Update: issue seems solved! I googled around about Windows 10 Upgrade 1803 and mDNS and found that:

https://antsle.com/forum/topic/did-wind ... addresses/

I Installed bonjour Print service for Windows from Apple website as suggested

Best Regards
Giacomo

[laionidas]

Found another solution that doesn't require Apple Bonjour, or other workarounds that require installation of additional software. The below can be found in my original thread.

Fixed it after I remember other programs (noticably GOG Galaxy) having similar issues:

The trick is to install VLC x64 to "C:\something", instead of "C:\program files\something", so any other folder than "program files" really. There is also a firewall prompt after every fresh installation, when installing to other folders than "program files", but not when installing to the latter. I haven't tried manually creating firewall exceptions for a "program files" installation, but I think I did in the past and it made no difference. I am sure I tried it for other programs (like GOG Galaxy), and it didn't resolve the issue either, while an installation to "C:\something", instead of "C:\program files\something", did. Recent versions of Windows 10 x64 just seem to have some connectivity and access-rights issues that can't be resolved by granting administrator permission.

[sunmoon51]

Yes, so there is something blocking VLC from accessing the network on the machine. Indeed, discovery of the chromecast is mDNS (multicast), to guess the address.

I HAD this issue too. I've found interesting post about the mDNS issues: Why do some WiFi routers block multicast packets going from wired to wireless? . Then I've found on the Internet which my network provider routers support Apple Bonjour|Microsoft mDNS and which don't. Then I asked them to replace my old cable modem. Today I got the new one. Guess what? Chromecast is ALWAYS visible as renderer in VLC. Problem solved! Hope this helps...

[simonirwin]

I am using 3.0.4 and the problem as described occurs as far as I can tell if the Chromecast device is not ready when you ***boot*** your PC. No amount of messing about in VLC or anywhere else seems to make any difference if you booted when it was not available. You just get "Scanning" stuck there. If you reboot the PC when the Chromecast is up and running on your LAN, then start VLC, I have found that it always finds it.

Good Luck....

[pen]

I went into exactly the same problem when I tried VLC with my Chromecast yesterday. I realised that this could be the same problem as I had for other applications with my Chromecas Audio previously and tried the same workaround and it worked also for VLC.

Here is what I found out when digging into my Chromecast Audio option (as I remember it):

mDNS is subscribing to a multicast stream (multicast IP address) via Windows
Windows keeps a list of all subscribed streams internally
If there is a change to the list - and only then - Windows probably call the network chip driver to push the complete list down
The network chip driver adds the list to the hardware multicast listening table
The network chip only deliver multicast packets whose IP address matches those in the table to Windows

If of some reason there has become a mismatch between the list in Windows and the table in the hardware AND
if there already exist an entry for the mDNS multicast address in the Windows table (but not in the hardware) AND
an application that needs to use mDNS call Windows to subscribe to the mDNS multicast address THEN
Windows recognise the address is already in its list and DOES NOT push the table down to the network driver SO
the mDNS packets just drops in the hardware.

The workaround I did was to make a script that subscribed to an arbitrary multicast address but not the one used by mDNS (or any other known to already be used) and then just unsubscribed again. Since the arbitrary address is not likely to already be in the Windows list - Windows will push not just the new address, but all subscribed addresses to the network chip driver including the one used by mDNS. After this VLC starts to work.

Typically the missmatch beteen Windows and the network hardware is generated when my PC goes to sleep.

[pen]

And here is my script

Code: Select all

@echo off REM Script to make a dummy join and leave of a multicast group REM Executes multicast receive program for 5s and then exits cd "C:\Program Files (x86)\<your folder for mcreceive>" set /a min = 100 set /a max = 199 set /a lowip = %RANDOM% * (%max% - %min% + 1) / 32768 + %min% echo 224.0.0.%lowip% Start "" /b mcreceive.exe 224.0.0.%lowip% 6000 timeout /T 5 /nobreak >nul taskkill /IM mcreceive.exe /F EXIT

You need to put the mcreceive.exe file somewhere and point it out in the script. The problem is that the site that provided the multicast toolbox where mcreceive.exe was part seems to have moved or disappeared. I dont know if I can somehow post my mcreceive.exe file here. But it's just an multicast receiver for testing purposes. Maybe there is a similar program somewhere.

[pen]

While this is a workaround, it's not a good solution. Trying to get Microsoft and/or the network chip vendor to solve the problem is useless. The better solution is that the application, once it has discovered the unicast address to a Chromecast device, NEVER EVER forget it again until it has been proven to be unreachable. I guess that this is how working applications (like Chrome) are implemented - first try to connect to already learned devices by unicast, second try to find new devices by mDNS.

[Namekuseijin]

I have the exact same problem and I was not able to solve the issue, can anyone help me?
tried installing on a different folder than 'program files' and downloading the bonjour thing...
also prepared the chromecast before booting the computer and didn't worked as well...

[pen]

Since it's not trivial for others to make my script above work (in absense of the needed program), please try the following instead. It will basically do the same as the script:

If VLC is stuck on scanning for renderer, then use VLC to open a random multicast network stream in the range of address 224.0.0.X, where X is between 100 and 199. You should notice there is nothing played (since there is no such stream available). Wait for a while and then check for available renderers again. Now they should show up (might take a couple of seconds but not more than a minute).

Note that once you have used a number X, you cannot use it again. A way to generate new numbers might be to set X to 100 + current date. If you get stuck more than once a day, then add 30 to the date or just use 100 + current minute as a random number. And when all numbers are exhausted, well then you have to powercycle the laptop unless that has already been done in a month.

The complete syntax for the multicast network stream to open is udp://@224.0.0.X:5000

Please let me know if it helps.

[unidan]

Different context from the previous message, but it could also be this issue: https://trac.videolan.org/vlc/ticket/17477

[pen]

Interesting observation. It might or might not be related.

The way I found the cause of my problem (and my family members as well) was that on the laptop under consideration not even wireshark was able to observe the reception of mDNS packets despite the fact that both VLC and Chromecast was represented in the Windows multicast subscription table. Other computers on the network received them. Eventhough no mDNS packets were received, Chromecast continued to work but not VLC. So somehow, Chromecast must have cached the unicast IP address of the rederers (the cache survived the root cause).