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

[unidan]

It's disheartening that almost three full YEARS after this solution was provided -- and it works 100% of the time -- no official fix has been provided by the VLC team for this problem. I guess it's time I start researching an alternate video player.

That's not a fix, that's a workaround. It looks like a bug in the multicast group registration in microdns/other dependency lib, workarounded by registering a new time through VLC multicast layer. There's still a lot of time to spend to find a fix for this. But such workaround might typically not work reliably on apple/linux platforms.

[pierre2113]

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.

this post was very helpful, but the utility mreceive.exe is almost impossible to get. I have cygwin installed on windows 10,
which I used to install iperf.exe

I converted the cmd script into a bash script equivalent, I run the shell script in a cygwin terminal

you can use notepad and name the file mcast.sh into
open terminal
chmod +x mcast.sh
then
execute
./mcast.sh

I've had to do it execute ./mcast.sh multiple times

there is also a standalone iperf3 you can google and download, I didn't test that as it comes with a .dll file also
and that dll version would conflict with my cygwin version i already have installed

mreceive to iperf command argument comparison, i've added 30sec the other options i've found in google searches
the iperf with %lowip% is what you'd use if you tried to run iperf from a windows .cmd script from "pen" original post
if you are not familiar with cygwin, and linux paths/scripts in a windows environment
then going that route maybe your better option.

Code: Select all

mcreceive.exe 224.0.0.%lowip% 6000 vs iperf -c 224.0.0.%lowip% -p 6000 -u -T 32 -t 30 -i 1

Code: Select all

#!/bin/bash RANDOM=$$ min=100 max=199 DIFF=$((max-min+1)) R=$(($(($RANDOM%$DIFF))+min)) echo "ip= 224.0.0.${R}" iperf -c 224.0.0.${R} -p 6000 -u -T 32 -t 30 -i 1

[gweilo8888]

It's disheartening that almost three full YEARS after this solution was provided -- and it works 100% of the time -- no official fix has been provided by the VLC team for this problem. I guess it's time I start researching an alternate video player.

That's not a fix, that's a workaround. It looks like a bug in the multicast group registration in microdns/other dependency lib, workarounded by registering a new time through VLC multicast layer. There's still a lot of time to spend to find a fix for this. But such workaround might typically not work reliably on apple/linux platforms.

I'm well aware it's a workaround and not a fix. I'm equally well aware that if you had any interest in fixing the bug, you'd have done so after three years given that you've been given a 100% reliable workaround which can itself be used to figure out the source of the problem.

In the meantime, VLC users will find their own workarounds. I've certainly found my own, which was to switch to SMPlayer which has absolutely zero difficulty in finding my Chromecast first time, every time.

[unidan]

> I'm well aware it's a workaround and not a fix. I'm equally well aware that if you had any interest in fixing the bug, you'd have done so after three years given that you've been given a 100% reliable workaround which can itself be used to figure out the source of the problem.

Unfortunately we're flying blind here. It seems that we never reproduced and I personnally have little time experimenting on the network system from Windows. I mainly wanted to point out that it's a workaround, so it's hard to justify/merge into the required libraries especially since it would hide the real issue behind and introduce new issues.

No problem with you switching, but keep in mind that VLC is free because of people giving their free time. The very time I'm using to answer is time I don't spend with my family. In addition, you don't need to be angry to be able to switch or anything. You can spend time helping find the issue but if you cannot, that's fine, but there's nothing we can do for you right now.

[Toneplay]

I had this same issue and solved it by disabling IPv6 on my network card.

This worked GREAT for me. Also, as soon as it was working, I turned IPv6 back on, and VLC Renderer STILL worked. We'll see how long it sticks, but for now, I know how to fix the problem! Woohoo!