Casting does not work even when chrome://flags/#cast-media-route-provider and set the flag to Enabled. (It does work in standard Chromium and Chrome on same computer/network.)
https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq#how-do-i-enable-chromecasting
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Expect the browser to find the same casting devices that all the other apps find on the network.
Environment (please complete the following information):
Hmm, perhaps casting behaves differently on Linux than Windows? @bigmudcake @leso-kn Any ideas?
Does a packet capture reveal anything? I think you should see some mDNS traffic.
mDNS is definitely making it to the machine... when I used standard Chromium it works. While ungoogled-chromium couldn't find any of the casting devices, I opened up chrome on the same computer and it connected to casting devices immediately.
I tested on Windows 64bit build 84.0.4147.105 and casting is still working. Maybe some library or make flag is missing on the Linux build. I will try and test a Linix build in a Virtualbox (Ubuntu) at some point.
For me it's working on Linux (Ubuntu 20.04, with the latest version from the apt repo)
@Eloston Yes, capturing the mdns traffic should in theory reveal packets related to chromecast, but I did not check for the alternative cast method with chrome://flags#cast-media-route-provider enabled.
I just tried it again with and changed "chrome://flags#cast-media-route-provider" from enabled, to disabled, and to default, with a relaunch in between. I still got the "No devices found" message after each attempt. I checked in my Chrome browser and it was set to Default.


This is probably related to patches/extra/ungoogled-chromium/fix-building-without-mdns-and-service-discovery.patch and GN flags enable_mdns=false and enable_service_discovery=false. In addition, #1152, will further break Casting. These changes fall under the objective for privacy enhancement.
To fix Casting, I think we need to re-enable those GN flags and add a new flag to chrome://flags so we have the option to satisfy privacy and Casting use-cases. For the time being, I am inclined to leave Casting and related technologies broken because we've already been doing so for a while.
Help would be appreciated to write the patch for chrome://flags.
I don't disagree with leaving it broken. I only brought this up not working specifically because the FAQ instructions for enabling casting wasn't working for me. Thanks for looking into this though.