lordchuffnel
New member
I would like to automate our station as much as possible. InsertTrack from the API works much better for us than the current request system, as I can choose the position in the current queue (playlist) it lands.
Leverage InsertTrack as Secondary Song Request Endpoint with Useful Response
- Thread starter lordchuffnel
- Start date
lordchuffnel
New member
Sorry... Session timeout 
.....
Anyway ....
However, no matter what the 'filename' is (any jibberish at all) will succeed and respond with OK and add it to the queue. RadioBoss does gracefully handle this by quickly playing the next track as it just Errors on invalid Song, (which is good behavior).
I would like to see the insertTrack api method query the database AND/OR default rules put in place by the RadioBoss admin to respond to the request with useful information.
I would assume this to be async behavior in the code base.
Here is an example ->
OK - successful
6xx - Invalid Path (song) / Invalid Requst (unknown error) <-- Fail Over Response
7xx - Song/Artist/Title recently played. <-- Default/Global Rotation Rules Enforced Response
8xx - Song already in queue/playlist to be played <-- Playlist Rotation Rules Response
9xx - Authorization failed. IP not in allowed list. <-- Request IP not whitelisted Response
Have the response codes be simple JSON. Or XML if you must. I figure start at 600 as to not ever be confused with HTTP status codes.
Also, have a whitelist of request IPs so people can ONLY request from my website.
This way, I can eliminate a lot of conditional session based rules on the frontend about WHY someone can't request a song, rather, the reason comes back in the response from RadioBoss. This would eliminate the need to store information about song history/rules in localstorage, or have rules reset on each page refresh.
Your consideration would be much appreciated
.....Anyway ....
However, no matter what the 'filename' is (any jibberish at all) will succeed and respond with OK and add it to the queue. RadioBoss does gracefully handle this by quickly playing the next track as it just Errors on invalid Song, (which is good behavior).
I would like to see the insertTrack api method query the database AND/OR default rules put in place by the RadioBoss admin to respond to the request with useful information.
I would assume this to be async behavior in the code base.
Here is an example ->
OK - successful
6xx - Invalid Path (song) / Invalid Requst (unknown error) <-- Fail Over Response
7xx - Song/Artist/Title recently played. <-- Default/Global Rotation Rules Enforced Response
8xx - Song already in queue/playlist to be played <-- Playlist Rotation Rules Response
9xx - Authorization failed. IP not in allowed list. <-- Request IP not whitelisted Response
Have the response codes be simple JSON. Or XML if you must. I figure start at 600 as to not ever be confused with HTTP status codes.
Also, have a whitelist of request IPs so people can ONLY request from my website.
This way, I can eliminate a lot of conditional session based rules on the frontend about WHY someone can't request a song, rather, the reason comes back in the response from RadioBoss. This would eliminate the need to store information about song history/rules in localstorage, or have rules reset on each page refresh.
Your consideration would be much appreciated
Yes, it's not supposed to check if a file exists or if the inserted item is valid.
"OK" response in this case means the insertion to the playlist was successful. Not that the inserted item will be playable.
The actual checks depend on the situation. You can get recently played tracks list using getlastplayed command, and playlist contents using getplaylist2 command. Then process results of those commands to check for repeats and other things, if needed.
We'll see if we can improve song request system to make it autiomatically check for repeats.
lordchuffnel
New member
Correct. Ideally, the request would check against default track, title, artist repeat rules. The lastplayed and playlist results are default and easy to check against.
I completely understand the current OK response from inserttrack is purposeful and that I am hacking it.
Thank you for your response. I really appreciate it!
I think that should be checked on playback, when using playrequestedsong command - it will decide what of the requested songs can be played. I added it to our to-do list, we'll work on it.
lordchuffnel
New member
Here's some context for my feature request:
We allow our users to search our catalog, select a song, and request it. By default, if the song exists in the Queue or History (say up to 20 tracks ago), then the request button is disabled.
If the button is enabled, we make a call to our software, and the software checks against the repeat rules and sends a response back in object format. {code: number, message: string}, we then use the message to tell the listener WHY this song cannot be requested, as indicated
Requested song is offline and can not be played
Song recently played
Artist recently played
Track recently played
Album recently played
Requested song ID invalid
and so on.
We strive to fully automate our station with the software, so having the requested songs only fail when they are the "currently playing song" or having the songs in a separate window to add as necessary is not the functionality we desire.
In our attempt to bring parity between our current software, and RadioBoss, we see that, for our needs, inserttrack works more akin to what we currently have than the RadioBoss song request feature/API endpoint.
Hope that helps understand where i'm coming from!
Thank you!
We allow our users to search our catalog, select a song, and request it. By default, if the song exists in the Queue or History (say up to 20 tracks ago), then the request button is disabled.
If the button is enabled, we make a call to our software, and the software checks against the repeat rules and sends a response back in object format. {code: number, message: string}, we then use the message to tell the listener WHY this song cannot be requested, as indicated
Requested song is offline and can not be played
Song recently played
Artist recently played
Track recently played
Album recently played
Requested song ID invalid
and so on.
We strive to fully automate our station with the software, so having the requested songs only fail when they are the "currently playing song" or having the songs in a separate window to add as necessary is not the functionality we desire.
In our attempt to bring parity between our current software, and RadioBoss, we see that, for our needs, inserttrack works more akin to what we currently have than the RadioBoss song request feature/API endpoint.
Hope that helps understand where i'm coming from!
Thank you!
If you do your own checks, then I suppose current API is enough for that. You can retrieve playlist contents, recent played tracks, and can insert tracks at any position - this is enough for use case you described.
What we are going to implement is to have some rules (repeat protection by artist, title etc) and have RadioBOSS check them when using playrequestedsong command. This will also be test-driven in RadioBOSS Cloud (the core is the same as RadioBOSS) and we'll see how it works.
So, using request song API will be a faster way to implement things, two simple API calls. But if you need more control (what seems to be your case) then you can use lower level APIs to control playlist directly.
