Stats capturing

[pironic]

This will capture important information for various commands and stats.

This will be a collection of modules that have various functions:

• User levels active forwarded to External RRD API.
• Number of times each command is used captured internally.
• Number of users that are active and afk.
• WritheM Score, captures the amount of grab/meh/woot while djing and does some math to provide a single number that represents how likely they are to play well received songs.

[pironic]

We're going to need to put more thought into this one i think... what the data package/payloads look like for updating.

It'd be nice to capture a list of everyone that was present at the end of a song, what they voted, and if they were the dj, in the waiting list, or just an audience member.

a user object has a vote object on it,

a play object has a song object, an audience array (which contain user objects), a dj array (which contains one user object), and a waitlist object (which contains user objects)

with that we could track writhem score, basic stats about when the last time a user was seen doing something, how often they do stuff, the votes they make, as well as the votes they receive.

[ylt]

Wondering, should we count users votes if they left before the end?

[ylt]

How about something like this for the payload: Its been kept very closely to the structures used by plugapi so minimal work needed.

{
    "media": {
        "id": 282801560, /* youtube id */
        "duration": 262,
        "author": "TVDS",
        "title": "TVDS - Black Sky [Monstercat EP Release]",
        "image": "https://i1.sndcdn.com/artworks-000026017510-81e667-large.jpg?d8c2b3b",
        "dj": 6405247,
        "timestamp": "2015-06-11 00:15:00"
    },
    "votes": [
        { "id": 6591703, "woot": true, "grab": true, "meh": false, "val": 1 },
        { "id": 6405374, "woot": true, "grab": false, "meh": false, "val": 1 },
    ],
}

and then in the database, those two keys can just be tables.

Main issue may be building up the users table in order to map ids to usernames(, etc), we could just send every user entry every track (which is inefficient but allows for recording changes of avatar, badge, etc)

[pironic]

i think it'd be nice to know how many songs a user has heard vs voted on in order to calculate the writhem score. so we'll need to know the number of users too... we should be capturing the data for the duration a song is playing and then send the culminated data at song change, that way we get both the users that left but still engaged in the song and the users that are still there and didn't engage.