Limit the amount of items a user can have in the queue

[mintopia]

Add a configurable option to the party to limit how many songs a user can have in the queue at any one time. For example if the limit is set to 5, they can add 5 things to the queue and then no-more until they have some songs played (or deleted).

Separately, allow an override on party members for 'trusted' people.

[VibroAxe]

My concern with this change is that it penalises "good" DJ's who are producing music people like. A large complement of songs at slan were added at the beginning. Perhaps an alternative solution could work here, a couple of options provided for comment looking at the track selection phase rather than the voting phase

For the purposes of the examples, consider the following example data for the queue

ID	Song	Author	Vote Count	Last Vote Time
1	Song A	Author A	6	12:01
2	Song B	Author A	2	12:09
3	Song C	Author A	2	12:06
4	Song D	Author B	5	12:02
5	Song E	Author B	2	12:03
6	Song F	Author B	2	12:08
7	Song G	Author C	2	12:04
8	Song H	Author C	2	12:05
9	Song I	Author D	2	12:07

Option 0: Current

Behaviour

• Select highest voted track, ordered by added date (/record ID i suspect)

Pros

• Current implementation

Cons

• Generally people are putting tracks in together, this increases the likelihood of a "block" of content from one author once the list gets low

Track Selection

ID	Song	Author	Vote Count	Last Vote Time
1	Song A	Author A	6	12:01
4	Song D	Author B	5	12:02
2	Song B	Author A	2	12:09
3	Song C	Author A	2	12:06
5	Song E	Author B	2	12:03
6	Song F	Author B	2	12:08
7	Song G	Author C	2	12:04
8	Song H	Author C	2	12:05
9	Song I	Author D	2	12:07

Option 1: Order by Last Vote: FIFO

Behaviour

• Select highest voted track, ordered by last voted ascending

Pros

• Easy to implement, just requires a sort order in the code
• Based on secondary activity so things will probably separate from the author
• Ascending means that the older stuff will play first, this is effectively a first in, first out

Cons

• FIFO means people are likely to "forget" about voting for the song by the time it comes around

Track Selection

ID	Song	Author	Vote Count	Last Vote Time
1	Song A	Author A	6	12:01
4	Song D	Author B	5	12:02
5	Song E	Author B	2	12:03
7	Song G	Author C	2	12:04
8	Song H	Author C	2	12:05
3	Song C	Author A	2	12:06
9	Song I	Author D	2	12:07
6	Song F	Author B	2	12:08
2	Song B	Author A	2	12:09

Option 2: Rotate by author

Behaviour

• Select highest voted tracks, round robin allocation based on author
  • When selecting a track, check to see if the highest track has the same vote count as the current track
    • If different
      • clear the list of "played authors"
    • If equal
      • select the highest track which is from an author not in the played authors list
        • Add the new author to the played authors list
      • If not track available not in the played authors list
        • clear the list of "played authors"
        • select a new track (possibly according to Option 0 or Option1)
        • Add the new author to the played authors list

Pros

• Guarantees splitting the authors up unless they are first in subsequent tiers:
  • Could be mitigated by only resetting the played authors list if there are no available tracks at the current vote tier, meaning it would move between tiers

Cons

• Harder to implement

Track Selection

ID	Song	Author	Vote Count	Last Vote Time
1	Song A	Author A	6	12:01
4	Song D	Author B	5	12:02
2	Song B	Author A	2	12:09
5	Song E	Author B	2	12:03
7	Song G	Author C	2	12:04
9	Song I	Author D	2	12:07
3	Song C	Author A	2	12:06
6	Song F	Author B	2	12:08
8	Song H	Author C	2	12:05

[mintopia]

So, we already have an option we can use - 'raffle mode'. In this mode, we don't play the most upvoted track, instead, we pick a track at random from the queue, weighted by number of votes. So a track that has more votes will be more likely to be played, but not neccesarily.

My original thought for this particular issue raised would be to allow the party admins to assign people as VIPs who would bypass limits like this.

The other option is to also finish the Eigenkarma system that Cwis was working on where we give each person a trust score and votes are worth more or less based on how well trusted you are by the community based on your existing song choices and popularity.

The final idea is one of gamifying the system where tracks cost credits based on their length; you earn credits for upvotes, lose them for downvotes, and they refill slowly over time to a maximum.

[mintopia]

Initial attempt at doing something basic with a max per-user limit is now in.

[mintopia]

There's also now a VIP category who currently is exempt from this. Will most likely extend it to allow them to override everything - or even have it configurable what a VIP user can do.