Start streaming immediately by clicking on a playable item (track, album, year, favorite list etc.) or use the queue
as an intermediate placeholder for tracks about to be played. Read more
How do I configure jukebox mode in AmpJuke ?
Just like anything else that operates on the "server" level, you get access to the configuration by logging in as a user with administrator rights and then click "Configuration..." on the "welcome" page.
On the configuration page there's a section labeled "Jukebox configuration". It can be expanded by clicking on the small +-sign next to it.
And there it is: A bunch of (19) related parameters (some of them with more than one setting) that controls the jukebox mode:
Image above may look slightly different on your installation
Let's take a closer look...
Enable jukebox mode: If checked (on), AmpJuke will operate in "jukebox mode". If unchecked (off), the rest of the parameters will not have any effect.
However, besides configuration (this FAQ), additional operations needs to be performed as well (see links below) before operating AmpJuke in jukebox mode (or as an online radio station).
Display this message on the "Welcome" page: Is an optional message that can be displayed on the "welcome" page to eveyone who logs in.
It's supposed to be used with the next setting. You can enter something like Jukebox mode: Click here to start listening!
Use this URL for the message above (on the "Welcome" page): Is an optional link for the previous message.
As seen within the FAQ-entry for "Setup/starting...", the URL to the music stream can seem a little complicated (portnumbers are used).
When providing a text + a link to the music stream on the "welcome" page, it's a little bit easier for users: They should just login to AmpJuke as usual and click the link in order to start listening.
The URL can be something like this example: http://www.my-ampjuke-server.org:8082/m.mp3
Jukebox user name: When AmpJuke runs in jukebox mode, some personal settings needs to be taken from a specific user-account and used in jukebox mode.
Please be sure to enter the username of a real, existing user on your own AmpJuke box - in the example above it's "hellsbells".
Important: You should check the personal settings of the username the jukebox will "run as". See link below.
What determines the identity of who requests a track: This setting is related to finding out who requests a track.
As you will see below, it's possible to set up various limitations in order to keep requests below certain levels.
There are two possibilities.
Normally "Username" is the best setting. When "Username" is used, a valid, logged-in user will be checked against the limitations (see further down this page).
"IP-address" can (should) be used, if the AmpJuke server's settings allows "anonymous" users to listen to music (see the FAQ), since it's no real username is available if "anonymous" users are allowed access.
My recommendation: Select "Username" in all cases except when allowing non-registered (aka. "anonymous") users access.
Probability of streaming a request (in pct.: 0-100): Should be more or less self-explaining: If there are pending requests outstanding in the queue this will be the %-chance for playing a request.
Sidestory: Back in the day (20+ years ago) I was DJ'ing on a free-/hobby-time basis together with a couple of friends.
We spent several hours each week working as DJ's on local gigs (youth clubs and such), a local radio station and a local bar. Almost all the money we earned was spent on LP's, maxi-singles and single-records (on vinyl, of course!), improving our equipment (cables, amplifiers, lights, pickups etc.etc.) and occasionally a new turntable/tapedeck/smokemachine.
Sometimes (often, actually) the audience would request something to be played.
That was OK, naturally, but bear in mind our music was on vinyl stashed away in several boxes. It would often take a little while to find the right box with the right record - provided the record was left in the right place according to the filing system we had - it was alphabetically by artist - imagine finding something from T or - even worse - being unsure about the artist/performer...
Assuming we did have the music being requested, it was also a matter of "timing" the request so it - more or less - fell in "naturally" with the other music being played.
For some strange reason (we still laugh at it today when we get together and occasionally talk about the "old" days), we got asked to play "Duran Duran - The Wild Boys".
Not only sometimes, - but more or less freakin' ALWAYS it was even remotely possible to make a request.
It almost ended up being an obsession for us to avoid playing the damned track, - we might even lie: "we forgot to bring that with us" , "the record was broken during transport" or "we don't have that".
However, we also always somehow "by accident" suddenly "recovered" the damned Duran Duran single and played it anyway.
As the very last one that evening/session/whatever...
Anyway, the probability setting in AmpJuke is supposed to be a "simulation" of playing requests from users (unless the request is "Duran Duran - The Wild Boys"!).
Setting this to a value of something between 70 and 90 allows other tracks to be played on occasion before playing requests, although 70-90 still gives a relatively high prioriry for tracks being requested by the users.
Setting it to 100 means that a request will be played almost immediately upon request (after playing the "current" track, naturally).
Setting it close to 0 means that almost no requests will be played, ever, and requests might pile up in the queue.
Requests will be picked as: Two options exists, - they should both be self-explaining.
"First-come-first-serve" will ensure that tracks are played in the same order as requested. This is the most "fair" setting for requests, - no request will be "forgotten" - not even "The Wild Boys"...
"Random" will pick a request by random (if there's more than one) and play that, no matter who requested what and when.
The next part of this configuration deals with limitations in requests.
Setting limitations will - for example -avoid a user requesting 150 tracks within 2 minutes (and, of the 150 requests, 45 of them have been played within the last hour)...
Feel free to experiment with the limitation, since this obviously depends on how many users are expected to make requests.
Maximum number of tracks that can be requested (for each user): Enter a number for the maximum number of requests a user (being a real username or IP-address - see above) can request. A value around 8 for every 60 minutes is fine if you expect 2-3 users to make requests on a frequent basis.
Please note that this a "dynamic" setting:
Let's assume that "Maximum number of requests..." is 8 and the time-frame is 60 minutes.
A user makes his/her first request at 2:00, the second request at 2:05, the third request at 2:10 and so on.
At 2:35 the last (8th) possible request is made. If the user attempts to make another request at - let's say - 2:38 then the request will be denied since this particular user have requested 8 tracks within 60 minutes (other users may still make requests, of course).
It doesn't matter if none, a few, some or all of the requests have been played already, since 8 tracks have been requested within 60 minutes, which is the limit in this example.
Now the user has to wait until around 3:00 before being granted one new request. If the user waits until 3:05 then he/she has the option to make two new requests, at 3:10 it's three and so on.
So although the setting is 8 tracks every 60 minutes, the check against number of remaining requests and timeframe is "dynamic" (ie. it will adjust according to what other requests are outstanding for this particular user).
Also note: In the example above, if the user still has 8 oustanding (not played) tracks at 3:00 then no new request will be granted, since this particular user already has 8 requests queued.
Maximum number of outstanding tracks (for all users): Is a limitation that may actually overrule the setting describes previously. It's a limitation of the total number of requests that can be pending/outstanding, no matter how many requests are granted pr. user (above). Setting this to f.ex. 5 means that there can only be 5 requests pending in total.
Minimum "age" (pr. track) since last streamed: Is a number (in hours) entered in order to avoid a given track (f.ex. "Duran Duran - The Wild Boys"...) to be played more often than desired.
The default value is 2, meaning that a track must "wait" for two hours before it is possible to request the same track again.
Minimum "age" (pr. performer/artist) since last streamed: Means you or whoever requests music to be played cannot have wo tracks from the same performer/artist played within the settings' timeframe, - f.ex. 2 hours.
The last part - "Messages" - is used for pure information to the users requesting tracks.
Note that you can use string substitutions for various messages - see below for more info.
The parameters in relation to "Messages" are:
Show messages in a pop-up window: If checked (enabled), the acceptance/denial of a request will be displayed in a pop-up window. This is the default (take care of pop-up blockers!).
Display this message when adding new track (SUCCESS): Enter a message that will be displayed when a request has been added to the request queue successfully.
You can use HTML-formatted text as well as substitution of certain values (see below for more info.).
The default is: Added <b>%p - %t %a</b> (%y) to the request queue.
Display this message when limit of tracks is reached: Enter a message that will be displayed when an attempt is made to request more tracks than permitted in the configuration.
You can use HTML-formatted text as well as substitution for certain values (see below for more info.).
The default is: Sorry. You have reached the limit of <b>%limit_tracks</b> tracks for every <b>%limit_minutes minutes</b>. Try again later.
Display this message when limit of outstanding (not played) tracks is reached (for each user): Enter a message that will be displayed if the number of outstanding tracks for a particular user is reached when requesting a track.
HTML-formatting and string substitution is possible.
Display this message when limit of outstanding (not played) tracks is reached (for all users): Enter a message that will be displayed if the total number of outstanding tracks from all users is reached when someone requests a track.
HTML-formatting and string substitution is possible.
Display this message when adding a track that was played "recently": Enter a message that will be displayed if a track is being requested that was played "recently" (according to the "Minimum age (pr. track)..." setting above).
HTML-formatting and substitution is allowed (like all the other settings in this section).
The default is: Sorry. This track have been played recently (within last %min_age hours). Try again later.
Display this message when adding a track that was played "recently": Same as previous setting, but this message is displayed if someone requests a track from a performer played "recently" (see above).
The default is: The artist/performer %p was played recently (within last %min_performer_age hours). Try again later.
Display this message when adding a track that is already in the queue: Enter a message that will be displayed if a track is being requested, but is already present in the queue.
HTML-formatting and substitution is allowed.
The default is: Sorry. %p - %t is already in the request queue. It will be played later!
Substitution/replacement of certain values:
As indicated above, it's possible to do a simple substitution of certain strings within the message-settings above.
In short, the following substitutions can occur:
%t will be replaced with "Track name".
%p will be replaced with "Performer/artist name".
%a will be replaced with "Album name".
%y will be replaced with "Year".
%limit_tracks will be replaced with "Maximum number of tracks that can be requested (taken from the configuration above)".
%limit_minutes will be replaced with "Maximum number of tracks that can be requested (also from the configuration above)".
%min_age_below will be replaced with "Minimum "age" (pr. track) since last streamed (from the configuration)".
%min_age_performer will be replaced with "Minimum "age" (pr. performer/artist) since last streamed (from the configuration)".
Bottom line: Experiment with the values to see what's best for your "radio station" / jukebox.
Documents related to AmpJuke's jukebox mode can be found here:
What is jukebox mode in AmpJuke ?
How to configure jukebox mode in AmpJuke. (this document)
Recommened settings for the jukebox user.
How to setup/start the jukebox mode.
How to connect to a jukebox stream.