User Menu

Notification settings

Currently Playing

AMIGA-MODPophuora Have video by flag Groo (Sami O. Järvinen)
Requested By: djrandom

Time Left: 2:56

- Streams

Important Links

Please report any bugs to this forum thread!
> Bug Reporting Thread <
Song, artist, etc. corrections go here instead:
> Correct DB Info <
Broken tunes can be reported here:
> Report Broken Tunes Here <


Site Development » New Feature: Random fav req button

Pages: 1 2
Author Thread

290 Posts
#2056 (2 weeks, 3 days ago)
Hi Robot2037 - this is working as intended, so not a bug. The rand-req button does not recalculate lock times, though it does avoid queueing tunes which have been queued within the past few hours.

I don't think it's a problem to hear some fav tunes more than once in a 24-hour period, but if people think this is a problem, I could expand the no-dupes window.

290 Posts
#2057 (2 weeks, 2 days ago)
  • Randomness improved
  • Button will avoid requesting tunes that were requested very recently
  • Rand-req'd tunes are locked for a short time, to prevent accidental re-queuing "by hand"
  • Dice icon added in the req info, just for fun

symptomless coma

339 Posts
#2058 (2 weeks, 2 days ago)
Additional mirrorbird features
  • Randomness improved (now uses Mechanical Turk)
  • Can't request songs composed by your mum or dad
  • Final Hyperbase is actually Final. Bye bye, nice knowing you.
  • Won't play two songs with the same swear word, in a row^

^ experimental

16 Posts
#2059 (2 weeks ago)
This feature is genius (though obvious in hindsight).
I listen to the stream quite a lot during the day, especially at work, but it is too distracting to go to favs and search which song to queue while working so I almost stop requesting anything. Now it's super fast and I finally do request something. Thanks a lot!

And about this bug which allows requesting several songs in a row if you smash the button quickly enough: imho this should become a feature. Putting 3-4 songs in a queue makes it sooooo much better. Exploiting this results in a decently long queue of random quite nice tracks which increased overall stream quality A LOT.

290 Posts
#2060 (2 weeks ago)
Rumpel: you make an interesting point about the multi-click bug. I would like to know what others think!

Personally, I agree with you that multiple "rule-breaking" reqs in a row is not necessarily bad for the stream, as these are all coming off of ppl's favourites, and tend to result in a high-quality session, as you say.
Unplayed Requester™

66 Posts
#2061 (1 week, 6 days ago)
Does that mean I have to wait until 15 favorites by 3 users have been played until I get another tune in when I am not using the "Queue Random Fav" button?

290 Posts
#2062 (1 week, 6 days ago)
Well, they'll probably be short... but yeah maybe I should fix that bug
[Yes Info Line]

1 Posts
#2064 (1 week, 4 days ago)
Ive been testing this bug with button spamming. I use Firefox and fast autoclicker. After a certain speed (like 10 clicks per second or so) it consistently requests 8 songs and no more. Increasing clicking speed seems to increase the chance of requesting the same song twice (or even 3 times) for whatever reason.

290 Posts
#2065 (1 week, 4 days ago)
Regarding this spamming bug - I have not been able to reproduce it on my test instance. I added some code on the client-side to debounce the button, so maybe that will help. I will look at doing something on the server side as well, but JS debouncing should be sufficient.

MMX: have you tried clicking normally, without the auto-clicker? I'm interested to know whether this is a deliberate exploit, or if users are actively trying to spam the button.

"Button reqs locked tunas!" - yes, the race condition people are exploiting (?) defeats the various checks in the code about the status of the queue and whether a tune was req'd too recently, because all the reqs are processesed simultaneously.


13 Posts
#2066 (1 week, 4 days ago)
Spamming still works for me: Just clicking fast (manually, no tool) several times onto the button (Chrome-derivate browser). The random generated also queued Space Deliria, which was requested only a few hours before and should have been locked (note that this has nothing todo with parallelism of spamming the button, see

290 Posts
#2067 (1 week, 4 days ago)
It actually is related, but indirectly. I'm surprised people are still having problems, but it's probably due to a caching issue. Stay tuned.
All I ever wanted was some Sunshine.

86 Posts
#2073 (3 days, 11 hours ago)
Quote: "The idea is that if you press the button today and it reqs one of my favourite tunes, but I'm asleep, I can still req it off my own fav list manually tomorrow."

I read this as describing some sort of sleepwalking request forgiveness.

16 Posts
#2075 (1 day, 11 hours ago)
Now with only 1 req limit the queue is too short and the stream is constantly dropping to djrandom :/
Can you make kind of compromise and implement a variable limit? Let's say if a queue is less than 4 songs long allow 4 random reqs in a row (or even not random and do all reqs this way), if less than 8 allow 3, if less than 12 allow 2 and 1 otherwise. The numbers are somewhat arbitrary but can be a starting point for testing.
Queue length may be conditioned by total play time (if you have this data available in a script). This actually may be a more optimal approach.

290 Posts
#2076 (1 day, 8 hours ago)
I like that idea, Rumpel. I think we all benefit if the queue is full of decent reqs, and the less we have of djrandom, the better.

Also, someone (Accidental, perhaps?) mentioned that it might be good to have a button that queued a lesser-played tune at random. The "queue random fav" button implements the idea of "play me something I like". This other button would implement the idea of "play me something we haven't heard much". Thoughts?

Pages: 1 2

Post a Reply

Please log in to post a reply.