VLC has suddenly started refusing to play videos with the Chromecast renderer set.(This was working fine yesterday evening) Videos continue to play normally without any problems so long as the renderer is <local>. Reproducible: Always Steps to Reproduce: 1. Run 'vlc Aliens-1986-SpecialEdition-1080p.mkv' in command line as normal user. (replace with movie of choice) 2. Set 'Renderer' option to Chromecast device. ('Livingroom-TV', for example) 3. Press 'play' Actual Results: VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2) [000055ab0b888520] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [00007f86e0e9f600] gnutls tls client error: TLS handshake error: Error in the push function. [00007f86e0e9f600] main tls client error: TLS session handshake error [00007f86e0e9f600] main tls client error: connection error: No route to host [00007f86d4001af0] stream_out_chromecast stream out error: cannot load the Chromecast controller (Failed to create client session) [00007f86cc00d590] main stream output error: stream chain failed for `chromecast{ip=192.168.2.242,port=8009}' [00007f86dc000c90] main input error: cannot start stream output instance, aborting [00007f86dc000c90] main input error: Failed to start sout Expected Results: It should have began streaming my movie to the Chromecast connected to the TV. Firefox and Transmission(QT) were running also.
Created attachment 842721 [details] Output of 'emerge --info'
OpenSSL 3 would be a possible reason but you're on stable, so I guess it's not that. >[00007f86e0e9f600] main tls client error: TLS session handshake error >[00007f86e0e9f600] main tls client error: connection error: No route to host This makes it sound like it's networking though. What does qlop say changed in the last day on your system?
(In reply to Sam James from comment #2) The output of qlop is as follows: 2022-12-15T00:00:37 >>> media-video/vlc: 15′42″ 2022-12-15T00:38:03 *** gentoo: 12′46″
What does emerge -pvO dev-libs/openssl say?
(In reply to Sam James from comment #4) > What does emerge -pvO dev-libs/openssl say? Output: These are the packages that would be merged, in order: [ebuild R ] dev-libs/openssl-1.1.1s:0/1.1::gentoo USE="asm -rfc3779 -sctp -sslv3 -static-libs -test -tls-compression -tls-heartbeat -vanilla -verify-sig -weak-ssl-ciphers" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="(sse2)" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB
I seem to have discovered a workaround. I restarted wpa_supplicant and connected to my wifi network using ipv4 instead of ipv6, and now the problem seems to be gone. The only error thrown is; 'gnutls tls client error: Certificate verification failure: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.' When I disconnect and go back to ipv6, the problem returns. I hope this helps.
