We are in the process of migrating the Spacial Wiki content to our new Help Center at spacial.com.
Please visit the Help Center for latest Tips and Tricks, Documentation and Troubleshooting.
spacial.com/help-center

SAM Request Policy

From SpacialAudio

Jump to: navigation, search

SAM Broadcaster allows your listeners to make requests in real-time. SAM Broadcaster automates the entire request process - from logging the request to finally adding the request to the queue and playing it.

This is by far the most popular activity performed by visitors to a SAM Broadcaster powered website and it is what keeps most visitors coming back for more. Thus, it is highly recommended to use of the power of SAM Broadcaster's request function.

Contents

History

Another big improvement in SAM Broadcaster is the way requests are handled. In the past you had two options - enable requests, or disable requests. When requests are enabled, requests can be inserted into the queue at any random time which in many cases can have an undesired effect on your rotation logic. A good example is when you have a 4 part show, and a request is suddenly inserted between part 3 and 4 of the show, breaking the flow of the show. The only way to avoid this was to completely disable requests for the duration of the show. Thus during this time none of the listeners could make any requests.

Another option was to set the request policy to "Leave requests in list" for the duration of the show, but this usually caused all the requests made during the show to be inserted back-to-back in the queue as soon as the policy is changed again to move requests to the queue.

Even during just normal usage, requests can severely compromise a well-thought out station programming rotation logic. To solve all of the above problems it is now possible to take complete control of when and how requests are inserted into the queue.

Basic Configuration

SAM Broadcaster's Request Configuration
SAM Broadcaster's Request Configuration

The first step is to enable requests, but set the policy to Leave requests in list and optionally also delay requests for xx minutes. Thus ALL requests made will stay in the request list - unless we specifically add requests as part of our rotation logic.

To do this you can use two methods:

  1. Category based rotation
    • Under SAM->Config->Playlist rotation rules select the Clockwheel (Category rotation) logic module and hit the configure button.
    • Now modify your rotation clockwheel to insert requests at specified intervals.
    • Just hit the [+ Request] button to insert the appropriate clockwheel command.
  2. PAL scripts
    • The other method is of course using PAL scripts. Here is a simple example of a PAL script that will insert a request every 15 minutes, if a request is available.
PAL.Loop := True;
var Song : TSongInfo;
Song := Req.QueueTop;
if Song <> nil then
begin
writeln('Added request to queue:');
writeln(Song['filename']); 
Song.Free; {Dispose of the song object}
end;
PAL.WaitForTime('+00:15:00');

With this new process you can now accept requests from your listeners 24/7, but still have FULL control over the format of your station.

Request Rules

The same viewer can vote [aa] times every [bb] minutes, but no more than [cc] times per day.

This rule above will prevent the same listener controlling the playlist by making too many requests. It also gives other listeners an equal opportunity to make requests and hearing them play.

Delay request [xx] minutes and then: a) Leave request in list b) Put request at bottom of queue c) Put request at top of queue

If the delay is zero ("0") then requests will be placed directly into the Queue. If the delay is one ("1") or more minutes the requests will be kept inside the Request list until the delay has expired and then placed inside the Queue. Both the Delay & Instant modes are useful. Please read the "To Delay or not to Delay requests?" section below for detailed information.

Check against album repeat rule: - Check to apply the "Do not play the same artist within [xx] minutes" rule as specified in the Playlist Rotation Rules section.

Check against artist repeat rule: - Check to apply the "Do not play the same artist within [xx] minutes" rule as specified in the Playlist rotation rules section.

Check against title repeat rule: - Check to apply the "Do not play the same title within [xx] minutes" rule as specified in the Playlist rotation rules section.

Check against track repeat rule: - Check apply the "Do not play the same track within [xx] minutes" rule as specified in the Playlist rotation rules section.

Only accept requests from these IP addresses: This is the list of IP addresses and hostnames SAM Broadcaster recognizes as authorized request processors. This is to prevent automated scripts abusing the request system.

  1. If you handle requests yourself (via a PHP script, for example) you need to add the IP address or hostname of the webserver running your PHP script.
  2. If AudioRealm.com is handling your requests, you need to add the IP address or hostname of the www.audiorealm.com webserver.
    • Note: Just to clarify - this is NOT the list of IP addresses of listeners that can make requests. This is ONLY the list of authorized request handlers. (The application, script or program that delivers the actual request to the SAM application - which is 99% of the time a webserver).

To Delay or not to Delay requests?

In order to answer that question we first need to explain the operation of each mode:

Instant requests (Delay = 0)

The requests will be added to the queue (To the top or bottom as specified) as soon as the request is made. If you have enabled the "check against ..." rules, SAM Broadcaster will look at the Queue and History to see if the requested song/artist is:

  • a) not already in the queue or
  • b) has recently played.

If (a) or (b) is true, then the request will fail and an error will be reported to the requester. Thus, only tracks that have not recently played or are in the queue to be played will be accepted as valid requests.

  • Advantages:
    1. Requests are instantly added to the queue, resulting in a better interaction with listeners.
    2. Listeners know if their request has succeeded and that it will play shortly.
  • Disadvantages:
    1. Listeners might have to make various attempts to request a valid song since many requests will fail.
    2. DMCA or other laws might not allow for instant requests. (See bottom)

Delayed requests (Delay > 0)

If a request is made, it will be added to the request list - where it will reside until the song can be added to the queue.

A request will only be added to the Queue if:

  • a) It has been delayed for at least the time specified
  • b) The song/artist is not currently in the Queue to be played
  • c) The song/artist has not recently played

So if (a), (b), and (c) are satisfied the request will be added to the queue (top or bottom as specified).

The advantage is the request will never fail because it has been recently requested by another listener or because the song has recently played. All requests are accepted as valid and put into the request list until ready to play (and follow all the playlist rotation rules).

As soon as a requested song plays it will remove ALL requested songs from the request list which matches the current song's ID. In other words, say "Dido - Thank you" has been requested 5 times in the last hour by various listeners and there are now 5 "Dido - Thank you" requests waiting in the request queue. After a few minutes, the first "Dido - Thank you" request gets added to the queue. The other requests stay in the request list because (b) is no longer satisfied and they can not be added to the queue. The current track ends and "Dido - Thank you" starts playing - at which point the remaining 4 requests in the request list will also be removed.

  • Advantages:
    1. Very few requests will fail, so listeners feel like their request for the songs they REALLY want to hear most are granted.
    2. More DMCA friendly.
    3. Works much better with the current playlist rotation rules, inserting requests only when they satisfy the rules.
    4. Allows the DJ to view the request list and manually select requests for playing.
  • Disadvantages:
    1. Listeners might be under the impression that their request will play "soon" but it might in fact take hours, even days in rare cases before it will actually play.
    2. I want to use the Instant request logic - but DMCA requires me to delay requests. How can I delay requests but still use the Instant request logic?

The solution is a simple one. If you keep enough songs in the queue and put all requests to the bottom of the Queue the instant they are requested, all requests will effectively be delayed. (Because all the songs above the request must play before the request will actually play).

See the Playlist Rotation Rules section for more details on how to keep a certain count of songs into the Queue.

  • Note: Alternatively, you can use a PAL script to keep the queue full.

Note: USA users should review the DMCA to make sure your request policy conforms with the current legal requirements. The DMCA only applies to the USA. Other countries might have simular laws though.

Personal tools