No longer recognize username:password in stream .m3u

I have m3u files that were playing out username and password-protected Icecast streams without issue on 2.x.x. When I updated to 3.0 they broke. I'm currently on 3.0.1 (latest release as I write this) and thy still do not work. They now prompt for username / password. When they prompt, the username and password start the stream.

Here is an example or the m3u file I made:

#EXTM3U #EXTINF:-1,(THIS-STREAM) http://USERNAME:password@10.10.10.10:9025/THIS-STREAM

Cannot reproduce. Username and password are carried from M3U to HTTP query just fine here.

Interesting. I just had someone else show me they were on 2.2.8, open the stream without issue, update to 3.0.1, and watched it behave as I described. I can reproduce the issue on demand.

We then both downgraded to 2.2.8, and the issue goes away.

added Status::works for me label

closed

Please share the logs when it fails in 3.0.1

This is a regression I tried to fix a while ago. I can reproduce it.

removed Status::works for me label

reopened

See https://patches.videolan.org/patch/18477/ and https://patches.videolan.org/patch/18479/

A bit more context for what happens:

When the server is a Icecast server or behaves like one, VLC will fallback to the other (old) http module to be able to handle icy metadata (even if the stream does not use icy metadata, there is no easy way to know). This causes the auth information provided in the URL to get lost.

When no auth info is provided in the URL, VLC will ask for auth info (user/pass), if they are correct, the server response will contain the relevant Icecast headers which will cause the fallback and VLC will again ask for auth info (user/pass) using the old http module.

added Component::Input: network streams label

marked this issue as related to #19941 (closed)

marked #19941 (closed) as a duplicate of this issue