[Feature Request] HTTP radio streams

[paidlowered]

I want to play web radio on the music bot. It should be relatively easy to implement with FFMPEG (other than the fact that you have to support livestreams)

[iotku]

I think yt-dlp could mostly just work via similar routes to youtube/soundcloud links via its generic downloader. (matching !play http[s]://.... for streams like icecast and simular.

Right now we have a rudimentary hard-coded whitelist for URLs to avoid leaking the bot's IP (or otherwise make arbitrary requests), perhaps it could be sensible to load something like a urls.txt from disk to allow the operator to add additional domains.

mumzic/youtubedl/youtubedl.go

Lines 18 to 21 in 9c65990

	// IsWhiteListedURL returns true if URL begins with an acceptable URL for ytdl
	func IsWhiteListedURL(url string) bool {
	// ! Don't forget to end url with / !
	whiteListedURLS := []string{"https://www.youtube.com/", "https://music.youtube.com/", "https://youtu.be/", "https://soundcloud.com/"}

Its been a good while so I don't remember entirely how gumbleffmpeg would handle a livestream over a static file. (Would it start playing immediately when receiving audio data through the stdout pipe?)

mumzic/youtubedl/youtubedl.go

Line 63 in 9c65990

return gumbleffmpeg.SourceExec("yt-dlp", "--no-playlist", "-f", "bestaudio", "--rm-cache-dir", "-q", "-o", "-", url)

[paidlowered]

I'll see what happens when I whitelist the domain and try playing a radio stream

[paidlowered]

It works fine, we just need to list the stream URL in the status and chat, and change the whitelist thing

[iotku]

I think I got a half sensible whitelist.txt system working, currently it's still prefix based so you would need to stop at for instance http://domain.tld:8000/ rather than further down the full url (e.g. http://domain.tld/somename would rewrite to http://domain.tld/somename/ which might be invalid on the host.)

Currently whitelist.txt is just read when the bot first starts so would require a restart to add new entries, I might change it to read it every time for convenience at some point.

I'm not entirely sure what you are looking for listing the stream URL, as far as I can tell it still takes the general path title (e.g. somename from http://domain.tld/somename, but I suspect if the stream was just at http://domain.tld:8000/ it wouldn't show anything of note.

While keeping track of track metadata changes and such would be neat I don't think that would be very trivial to implement.

[paidlowered]

While you're here, although this would be difficult to implement, some sort of ACL would be nice for this

[iotku]

I haven't really considered much in the way of ACLs to be honest so that's probably a bit of an undertaking and not super high priority for myself given I've only used it with close friends, but if we could get some sort of verification system going there it would have to be via mumble certificates I imagine.

As it stands currently we can't really add a commands for stuff like modifying the whitelist because that would be an obvious bypass.

[iotku]

Recently I added a !reload command to force a refresh of the whitelist.txt file without resetting the bot and lessened the restrictions on urls in whitelist.txt so they don't have to explicitly end with a / so you can add whole radio stream URLs into whitelist.txt on a newline (though it's still a good practice for whitelisting domains as a whole to end with /)

So as it stands now you can add a full URL to the whitelist.txt, do a !reload (inside the mumble chat) to reload the whitelist and then add that to the queue and that should work without having to restart the bot entirely.

Long term I think it would be nice to have an ACL of some sort to only have server/bot admins to be able to manipulate the queue or otherwise have a way for the bot to just play a specific URL and ignore commands (e.g. having a channel in a mumble server that only plays a particular radio stream 24/7)