Nectarine
Site Development » New Feature: Random fav req button
| Author | Thread |
|---|---|
 nyingen323 Posts #2056 (11 months, 2 weeks 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. |
| Quote | |
|
nyingen 323 Posts #2057 (11 months, 2 weeks ago) |
Updates:
|
| Quote | |
 mirrorbirdsymptomless coma 383 Posts #2058 (11 months, 2 weeks ago) |
Additional mirrorbird features
^ experimental |
| Quote | |
 Rumpel 17 Posts #2059 (11 months, 1 week 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. |
| Quote | |
|
nyingen 323 Posts #2060 (11 months, 1 week 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. |
| Quote | |
 AccidentalUnplayed Requester™ 81 Posts #2061 (11 months, 1 week 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? 
|
| Quote | |
|
nyingen 323 Posts #2062 (11 months, 1 week ago) |
Well, they'll probably be short... but yeah maybe I should fix that bug 
|
| Quote | |
MMX [Yes Info Line] 1 Posts #2064 (11 months, 1 week 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.
|
| Quote | |
|
nyingen 323 Posts #2065 (11 months, 1 week 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. |
| Quote | |
 platon4215 Posts #2066 (11 months, 1 week 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 https://scenestream.net/demovibes/song/2104/queue_history/ |
| Quote | |
|
nyingen 323 Posts #2067 (11 months, 1 week 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.
|
| Quote | |
 velusip All I ever wanted was some Sunshine. 89 Posts #2073 (11 months 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.
|
| Quote | |
|
Rumpel 17 Posts #2075 (11 months 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. |
| Quote | |
|
nyingen 323 Posts #2076 (11 months 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? |
| Quote | |
 Wirlaburla3 Posts #2077 (10 months, 3 weeks ago) |
Quote: "It won't work if you have fewer than 100 favs or so. (You will get a message if this is the case. Add more favs!)" This doesn't seem to work (the message). I have less than 100 favs and I just thought it was broken for me. Only knew I needed more favs by this thread. |
| Quote |
Post a Reply
Please log in to post a reply.