Nectarine

I was thinking about a way to add a new locktime variable based on "tune groups". Let me know what you think. In short: requests of a tune within a tune group affects the locktimes of all those tunes. This can be used to solve a bunch of longstanding problems:

Remixes group: The original tune and its remixes (and submixes) get a tunegroup.

Long group: a huge tunegroup for tunes with length over 7..9 minutes.

Gametunes group: All gametunes get a tunegroup.

GameRemix group: Some gameremixes don't have a remix group since we don't host or want the original here. This is effectively a catchall remix group for lonely gameremixes.


A new table (tunegroup) with songid to tunegroup records. A tunegroup record contains a list of "peers" (songid), "time", and a "dynamic" flag. The time value can either be used by the existing locktime algo as one more additive and/or added to locktimes of all others in the tunegroup at this time (effectively locking all others in the group on the spot for a time). Exact implementation is up for debate.

The dynamic flag is optional, but it could be used to determine if the time is set by the tunegroup creator, or adjusted by a function which observes existing locktimes among its group and decides whether tunegroup time should increase or decrease right now.

As far as remixes go, I'm not sure I would be in favour of doing extra locking based on one tune being a version of another. It's true that some tunes are practically cloned into other platforms, or have uninspired remixes that add an untz drum or something, but other remixes are heavily reinterpreted almost to the point of being a separate tune entirely. I might go for it on a very short-term basis, like to prevent remixes from being played within an hour of one another or something, as that's a little tacky. But we all know what we're really talking about here, which is Knucklebusters remixes and their incredibly long International Karate cousins. Read on...

Long ago, Starchaser devised an alternative locking algorithm which weights lock times according to rating and tune length, plus vote confidence (so a song rated one star but with very few votes is not penalised as heavily as a one-star tune with 150 votes). He did some updating of it recently and the sample locktimes computed by it look pretty good. So we might trial that and see if it has a good effect on keeping down the 15-minute mediocre troll tunage. Another nice aspect of it is that short, sweet tunes get locked for less time.

That vote-weighted mechanism by Starchaser sounds very good and makes a lot of sense. I'm not going to bother fleshing out this idea until that one is well seated and maybe after we can look at a group value as well.

The group discrimination value is merely one more value intended for an existing locktime calculation, not a replacement. Like you said, used to reduce "certain" sessions from mounting up all at once. Like you said knucklebusters, hyperbase, craptunes, long, etc. It's basically prejudice in a can.

It's also applicable to any other problematic sessions that requesting nectas can dream up. A tunegroup would be defined explicitly by a staff member for an "emergent" session. Nectas are a creative bunch. I couldn't possibly know of what tunegroups the future has in store. The tunegroup would need a backstory field for explaining what nectas did this time. Basically, the granularity of application is entirely manually driven. While automatic categorization is possible, it's just not necessary.