Song Requests
With every version update to Mix It Up, we take some time to evaluate where we are currently with features and any changes we might need to make to them. This is done to ensure that we are consistently keeping the application as useful and relevant as possible, while also ensuring that any work we’ve done can continue to be sustainable for the future. Very rarely do we remove features, as once something is available, users will start using it and take a dependency on it. So we usually avoid working on things that we might feel will be removed at some point. There are some exceptions to this however, as we have removed 2 services in the past, but this was due to the actual companies themselves shutting down and no longer supporting them. That said, removing the Song Requests feature has been a very large and thought-out process over the last 6 months, but ultimately was one that needed to be done.
Below you’ll find information about the reasons as to why we’re removing the Song Requests feature, what you can expect timeline-wise, and what alternatives you can use if this feature is still important to your stream. We know that this sort of decision is not one that users will be happy about, no one likes getting something taken away that they use and we do understand that. However we hope that after reading the following information, you’ll get a better understanding of why we are making the decision we are and possibly re-evaluate your own usage of Song Requests on your stream as a result.
Why We Are Removing Song Requests
There’s a multitude of different reasons as to why we are removing the feature that we’ll attempt to detail out below. It’s not any one specific reason as to why however, it’s the fact that there are just so many different reasons as to why we should remove it that it simply overpowers any reasons to not remove it. We’ll also try to include info about a lot of “But what about…?” questions you may have on the various reasons below. Do note that this decision is decided and final, so even if you have a counter-argument to one of the below reasons, that will not change what our plan is:
User Scaling & API Usage Issues
Mix It Up has seen a large boom in users over the last year and we have only you to thank for continuing to support us and spread the word. However, with more users, unfortunately comes more problems. Many of the online services we work (Mixer, Twitter, Spotify, Streamlabs, etc) allow us to access and use their services via APIs, which are how we send your requests up and get data down. However, these APIs often have limits to how much you can use them within a certain time frame and will block requests if you go over that limit.
As more users use a service, this increases the change of our requests getting blocked. Since we are a desktop-based bot, we don’t have quite the same luxuries that an online-based bot has when it comes to one central place that everything goes through. All of your interactions with anything come directly from your computer, there is no Mix It Up online service that does all the work. This works to your benefit as it means things will happen super-fast for you and you never have to worry about anything being “down” on our end for your things to work. However, this also means that we have no good way to control how many people are using different things.
Song Requests are generally one of the most intensive services that is used in our program and as a result, is the one the most prone to having issues with being blocked. This is because everything that we do in it has to interact with either Spotify or YouTube depending on which you are using. Every time we look up a song, change the volume, play/pause, or even just get the status of your player, it involves a call to those APIs. So this is why sometimes hiccups can occur when trying to look up a song or why playback doesn’t work.
Although we’ve done the best we can to reduce the amount of calls we need to make down to the bare minimum, this is also resulted in other undesired behavior. For example, we used to continuously get info on your music playback to make sure it was still working and fix it if it wasn’t, but this resulted in too many calls. So we stopped doing this, but now if you leave a song paused for too long, our connection will get broken and you’ll need to skip to the next song. So it’s very much a rock and a hard place when it comes to trying to balance everything.
We’ve experimented with allowing users to create their own API access information with our Discord service and it has worked out fairly well to lighten the load for most users while also allowing more heavier-usage users to continue doing what they’re doing. However, we have no plans to do that for Song Requests due to the other reasons listed below.
Spotify Terms of Service - https://www.spotify.com/us/legal/end-user-agreement
Spotify’s terms of service have the following statement under its user guidelines:
The following is not permitted for any reason whatsoever:
1. copying, redistributing, reproducing, “ripping,” recording, transferring, performing or displaying to the public, broadcasting, or making available to the public any part of the Spotify Service or the Content, or otherwise making any use of the Spotify Service or the Content which is not expressly permitted under the Agreements or applicable law or which otherwise infringes the intellectual property rights (such as copyright) in the Spotify Service or the Content or any part of it;
Generally speaking, the concept of allowing people to pick what song you listen to isn’t really the bad part; the bad part is the broadcasting of the actual music itself being played on your stream.
Now, one could argue that if you set it up so that the music that Spotify played did not end up being captured as part of your stream’s audio and only ever played for you on your end, then you would be compliant and should be fine (it’s a bit hard to determine exactly, we’re not lawyers). Although that could be true, let’s be honest and say we know that very few if any users would end up doing this. So realistically we can’t maintain a service for something where our argument for keeping it around is not the majority of the actual usage of it.
YouTube Terms of Service - https://www.youtube.com/static?template=terms
YouTube’s terms of service have the following statement under its permissions and restrictions:
The following restrictions apply to your use of the Service. You are not allowed to:
1. access, reproduce, download, distribute, transmit, broadcast, display, sell, license, alter, modify or otherwise use any part of the Service or any Content except: (a) as expressly authorized by the Service; or (b) with prior written permission from YouTube and, if applicable, the respective rights holders;
9. use the Service to view or listen to Content other than for personal, non-commercial use (for example, you may not publicly screen videos or stream music from the Service); or
Rather than repeat what we’ve already said, please read the above info under Spotify Terms of Service argument above for our stance on this.
Copyright Ownership
Ignoring the terms of service for both Spotify & YouTube for the moment, let’s briefly talk about copyright ownership and the ability to play content. When you purchase a CD, buy a song of iTunes, or stream a song from YouTube; you are typically granted a personal, non-commercial use license for that music (though there are sometimes exceptions to this). However, generally this means you are allowed to listen yourself, maybe with a few friends or relatives in the same household, but you’re not allowed to start playing that music as a DJ for something like a wedding for example.
DJs, radio hosts, and other similar groups acquire special licenses from the major music licensing bodies. These allow them to play that music publicly and make money off of it, but they are also expected to pay royalty fees and also still need to physically own the music itself (streaming services typically don’t count). However, even if you were to acquire the necessary licenses to play this music publicly, you would still be using two services that do not allow the broadcasting of it.
So to even support this very out-there scenario, we would need to essentially build a way for you to import a music library you own, catalog it, search it, etc. This is also ignoring the idea that we would need to do any sort of verification that you have the proper licensing. So the costs of the licensing + the royalty payouts + the purchasing of the individual music + the development time to support this new scenario just make it something too unlikely and unreasonable to support for users when hardly 1% of current Song Request users would go through the steps necessary to do this.
User Acknowledgement of Risks
One of the arguments we’ll hear a lot are along the line of “Well, I’m ok with taking on the risks of breaking these terms of service, so you shouldn’t get rid of it as long as we accept the risks.” However, it’s not as straight forward as that. You’re perfectly in your right not follow the terms of service for something and continue to use it, however we do not have the luxury of taking that at face value as a means to protect us.
Because we are providing a means for you to use these services via their APIs, we can also be caught in any issues that might arise and that’s not something we want to be put into a position for. If anything, the individual users are not who they would care about, but the source in which they are accessing it would be. Very much a “kill the host, kill the colony scenario”, where stopping our access will very easily stop access for everyone else.
No Compatible Alternatives
Currently there do not exist any alternative music services that allow you the depth of access that we would require to support our current song request functionality. Two of the most popular, streamer friendly music services are Pretzel Rocks & No Copyright Sounds. However Pretzel does not provide any API access to interact with their service (only a very simple way to display what you’re currently playing via it) and No Copyright Sounds mainly uses Spotify & YouTube as its distribution methods (see earlier reasons about Spotify & YouTube).
Mixer Doesn’t Takedown / Block Content (Yet)
Presently, Mixer does not have any formal system for detecting or blocking copyrighted content in a stream. A stream has to be manually reported on for it to be either stopped or for the VOD to be removed, but this is not a very common occurrence. However, for Mixer to stay in good graces with large media companies, it most certainly will roll out some level of functionality for this in the coming years. So it not being a thing currently doesn’t mean it won’t be in the future.
What to Expect & Timeline
So what can you expect for the removal of Song Requests? Well, the next major update to Mix It Up, version 0.5.5 will be when it is removed publicly. If you are a Preview Program user, expect it to be removed as part of the first Preview update that will happen within the next month or so. In the changelog information that appears when you get an update, we’ll make sure to post in large and bold text when the feature is being removed.
If you are part of the Preview Program and want to remove yourself to continue using Song Requests for a bit longer, you can cancel the update & disable the option after logging in by going to the Settings menu. We won’t be actually disabling our API access for Spotify & YouTube, so technically if you never update Mix It Up again, you can continue to use Song Requests for as long as you would like. However, you won’t be able to receive any future updates for new features or bug fixes; so do so at your own discretion.
Since we also don’t like the idea of hard work simply getting blown away, we will be making an effort to document and tag all of the code that we made for the Song Requests feature and will be available to view up on our GitHub page. Anyone is welcome to use the code for whatever they would like and if someone else wants to build a stand-alone application that uses our Song Requests code to tackle on the mantle of it, they’re welcome to it. However it won’t be something we will provide any support for.
Once the feature has been removed, the Song Requests page in the app will be changed to a message giving a brief description of the removal of the feature and a link to this page for more information. The Song Request action will be removed from being usable and all commands that have this action in it will simply not run that action, but everything else in the command will continue to work as expected. Song Request Special Identifiers will no longer be processed and all other feature areas that used Song Request information (Overlay Widgets, Dashboard, etc), will be either removed or simply will no longer work. Additionally, the Spotify action will also be removed, since there is significantly less value to keeping it once Song Requests are removed. We will however be keeping the ability to show YouTube videos via the Overlay, as that falls into a different sort of bucket than simply playing music-based videos.
Alternative Song Request Options
For those users who feel that Song Requests are such a vital part of their stream, there are alternatives you can look at to give you some of the functionality we have provided. You’ll find a full list below:
Chat Bots that support Song Requests:
Streamer-friendly music services: