The !Song Command: Show What's Playing in Chat

What Does the !Song Command Do?

The !song command posts whatever track is playing on your stream right now, usually as artist and title, sometimes with a link. A viewer types it, your bot reads the current track from wherever your music is coming from, and chat gets an answer without you pausing what you're doing to squint at a taskbar.

It solves a specific, constant annoyance. Music is background for you and foreground for anyone who happens to like the track, and they'll ask — repeatedly, at different times, as new people arrive. Answering by voice works once for the people listening at that moment and not at all for the person who joins ninety seconds later. A command answers everyone, individually, forever.

Under the hood this is a live-data command, not a text one. Something has to know what's playing: either your bot is the thing playing the music, or it's connected to the service that is. That distinction determines everything about how you set it up, and it's why !song is more involved than a static trigger like !rules but less involved than something that has to authenticate and write, like !clip.

A common addition is !previoussong or !lastsong, for the viewer who was away making tea when the good one played. It costs nothing if your bot tracks history, and it catches the request you'd otherwise have to answer from memory.

Now Playing vs Song Requests — Not the Same Thing

These get conflated constantly and they're different features with different risks. Now playing is read-only: the command reports what's currently on, and chat has no influence over it. Song requests are write access to your stream's audio: viewers type !sr followed by a link or a search term, and their choice goes into a queue that actually plays.

Now playing is safe to hand to everyone on day one. Song requests are a moderation surface. Open a request queue on a channel with any kind of hostile audience and you will, eventually, get something that plays audio you very much did not want broadcast — which is why most bots gate requests behind a user level, cap the queue length, and give mods !skip and a ban list.

If you do run both, keep the triggers unambiguous. !song for what's playing, !sr or !songrequest to add one, !queue to see what's coming, !skip for mods. Streamers who use !song for requests and !nowplaying for the current track spend the rest of the stream correcting people, because chat's instinct for what !song means is near-universal.

One structural note if you're deciding between them: song requests are a genuine engagement mechanic — they give viewers a lever that visibly changes the stream, which very few things do — but they demand attention for the whole session. Now playing demands nothing. On a channel where you're already juggling chat from several platforms, start with the one that runs itself.

Music Licensing: What !Song Can't Save You From

Playing commercial music on a live stream is a copyright problem regardless of whether a command announces it. Every major platform runs automated audio matching against VODs and clips, and the consequences range from a silently muted section of your archive to a formal copyright strike against your channel. Streaming a track does not become licensed because you credited the artist — that's a persistent myth and it has cost people their channels.

What the command does affect is discoverability of the problem, in both directions. A chat log full of track names makes it trivially easy to see what was played. It also, more usefully, makes it easy for you to audit your own habits: if !song keeps returning major-label releases, you have a licensing exposure you can measure rather than guess at.

The clean fix is stream-safe music. Several services license catalogues specifically for live streaming and clear the VOD and clip usage that gets ordinary music flagged — the labels and playlists built for streamers exist precisely so this stops being a decision you make per track. Switch your background playlist to one of those and the !song command becomes a straightforward promotional feature: chat discovers artists, the artists get named, and nobody is muting your archive.

If you keep playing commercial music anyway — plenty of people do, with eyes open — at least keep it out of your permanent record. Disable VOD publishing on music-heavy segments, and be aware that on YouTube in particular the archive is the point of the platform, so the trade is worse there than on Twitch. See the YouTube live chat commands guide for more on how much longer YouTube content stays in circulation.

Making !Song Work Across Every Platform

Music setups are personal and fiddly — a desktop Spotify client, a browser tab, a hardware mixer, a playlist running in OBS — and the number of moving parts is why a !song command that worked last month sometimes stops. The most common failure is a broken link between your music source and the bot: an integration whose authorisation lapsed, or a now-playing bridge that quietly stopped updating.

The second most common failure only affects multistreamers, and it's more annoying: the command works on one platform and not the others, because the bot answering on Twitch is a different bot from the one answering on YouTube, and only one of them is connected to your music. Running a single command list across Twitch, YouTube Live and Kick avoids that split — the music connection is configured once and every platform gets the same answer.

Build a habit of testing it during your pre-stream check, alongside your audio levels. It takes four seconds, and the alternative is finding out mid-stream in front of the person who asked.