Change rating according to popularity

[staubi]

Hi Quentin, just had the idea in mind for quite a while, but I think an adjustment of the rating like ex.
every time a song is heard: +1
every time it's skipped -1

Cause I think most of us don't spent the time to manually rate a couple of thousand songs, do we?

Greetings, staubi

[Quentin Sculo]

Yes, it's not the first time someone asked this, I think some players do that.
I plan to do something more generic (let the user define a command to be executed after a given event) but it might be some time before I do that.
So I'll make a quick plugin to do that in the meantime. I'm in the middle of too many things right now, but remind me in a few weeks if I haven't done it by then.

Cause I think most of us don't spent the time to manually rate a couple of thousand songs, do we?

I rate them while listening to them, with the traytip, you could also configure keyboard shortcuts.

[staubi]

Don't worry! I'm already amazed on how You do all the programming alone and still try to integrate all the wishes...

Big Thanks!

[ochosi]

hm, to be honest i'm not sure whether this way of rating is a big improvement. in a way you can already look at songs that way by sorting them by play count / skip count... sometimes i guess i'd like to rate a song very high even though i've only heard it once. maybe a combination of play count plus manual override for the rating?

[Nyzek]

Orospakr and I have been working on implementing this as a plugin as part of a larger project.

Github page:
http://github.com/orospakr/gmusicbrowser-epicrating

Direct download of plugin:
http://github.com/orospakr/gmusicbrowser-epicrating/raw/epicrating/plugins/epicrating.pm

Currently this project has the following working:

-add/remove X amount of rating to on a fully-listened song
-add/remove X amount of rating to a skipped song
-set X number of seconds "grace" period on the rating change for skipping a song
-add/remove X amount of rating on songs skipped within grace period

-checkbox option for allowing the plugin to change the rating away from "default" when a song is heard
-checkbox option for allowing the plugin to change the rating away from "default" when a song is skipped*

*Notes:  If a song is set to "default" and is skipped, the default value is put in place, and no further rating changes are done, as long as the checkbox is enabled.  If the checkbox is not enabled, the rating will stay at "default", and changes will only be made to songs that have a rating already.

ToDo:

-better customization via GUI (perhaps an interface similar to the editing function of Weighted Random)
-Normalization project (system to auto-adjust all ratings to fit into a specified rating distribution to maintain statistical "meaning" in large libraries.  Intended for use with customized Weighted Random systems.)

We look forward to all feedback.

[Quentin Sculo]

nice to see a contributed plugin :)

A few small things :

- Author names :
you should them in the header part (=gmbplugin) as multiple :

Code Select Expand

author yourname <youremail>
lines, they will be ignored for now, but I'll add something to use them

- this line :

Code Select Expand

CLIENTID => 'gmb', VERSION => '1.1',
is not needed (it is the info the audioscrobbler uses as identification)
if you want to include a version number for your plugin, put in in the header, it will be used in the future

- for numeric options, use ::NewPrefSpinButton instead of ::NewPrefEntry
the arguments are :
1) option key  (OPT."GracePeriod")
2) minimum
3) maximum
followed by optional arguments such as : text1=> _"Grace period before applying a different differential"
'text1' for the text before the number
'text2' for the text after the number (such as a unit)
'sizeg1' and 'sizeg2' : sizegroups to add the left or right part
'tip' for tooltip text
'digits' for number of decimals (0 by default)
'step' for amount by which the number is increased/decreased (default to 1)
'page' for amount when pageup/pagedown are used (default to step*10)
'cb' for a callback function called when the number is changed

- you forgot a "_" before a string on line 124 to make it translatable

- check if the rating fall below 0

- default
Songs::Get($ID, 'rating'); returns "" for default, which is different than 0 which really means 0
(I know it makes things a bit more complicated, but I like being able to set a song rating to 0)
when doing if(!$song_rating) it will be true in both cases, so you need to do if($song_rating eq "") instead.

- making the field "rating" an option would be nice in the future when users will be able to add custom fields of type "rating", of course $::Options{"DefaultRating"} will have to change then (probably to $::Options{fields}{rating}{default}) so it can wait.

-better customization via GUI (perhaps an interface similar to the editing function of Weighted Random)

Do you mean with different saved profiles ?

-Normalization project (system to auto-adjust all ratings to fit into a specified rating distribution to maintain statistical "meaning" in large libraries.  Intended for use with customized Weighted Random systems.)

When do you want this normalization to occur ? each time a rating is changed, periodically, on demand ?

Don't hesitate to come in the irc channel to ask me questions, or you can of course post them here.

[Nyzek]

Thanks!
gmb is the best music player I've ever found by leaps and bounds, and I'm slowly picking up converts :)

- check if the rating fall below 0

- default
Songs::Get($ID, 'rating'); returns "" for default, which is different than 0 which really means 0
(I know it makes things a bit more complicated, but I like being able to set a song rating to 0)
when doing if(!$song_rating) it will be true in both cases, so you need to do if($song_rating eq "") instead.

I fully agree about the use of a rating of 0  :)  I figure that we'll put in place a system where it sees if the rating change will put the value below 0 it will just set it to 0, same for the high end.

- making the field "rating" an option would be nice in the future when users will be able to add custom fields of type "rating", of course $::Options{"DefaultRating"} will have to change then (probably to $::Options{fields}{rating}{default}) so it can wait.

I expected as much, and love the custom rating field idea :D

-better customization via GUI (perhaps an interface similar to the editing function of Weighted Random)

Do you mean with different saved profiles ?

That's a fine idea, as well!

I'm expecting that we will be putting in options so that users can create custom rating modification rules, likely with an interface similar to the Edit option for the Weighted Random play order.

-Normalization project (system to auto-adjust all ratings to fit into a specified rating distribution to maintain statistical "meaning" in large libraries.  Intended for use with customized Weighted Random systems.)

When do you want this normalization to occur ? each time a rating is changed, periodically, on demand ?

Now for the fun part  ;)  Most likely the normalization will happen after a song finishes playing or is skipped, after rating modifications are provided.  At the moment I'm trying to get some data from a smaller library to decide on how to model the normalization.  My goal is that eventually the ratings modified by normalization and play/skip etc can be a good indicator of what songs are currently most appreciated.  I'm also looking at tracking related information, like highest rating achieved, rating decay rate, and probably a few others for individual songs, and attention spread over [period] for libraries.  I'd be using these for various custom Weighted Random systems.

[orospakr]

EpicRating now has a much nicer rule editor, and CSV dump of rating populations.



It's up on github as a branch of all of gmusicbrowser; the whole thing as tested together.  Bear in mind there's a change to gmusicbrowser core in the form of a new event, Skipped.

GH: http://github.com/orospakr/gmusicbrowser-epicrating

git: git://github.com/orospakr/gmusicbrowser-epicrating.git

source of latest ER plugin only (NB. won't work on stock): http://github.com/orospakr/gmusicbrowser-epicrating/raw/epicrating/plugins/epicrating.pm

The astute reader might notice another plugin, "DACP Server".  Hopefully something will come of it, soon.

[ochosi]

this looks really nice!

will the change that is necessary for the plugin be integrated into main-gmb or will this stay a separate branch?

[Nyzek]

Now for the fun part  ;)  Most likely the normalization will happen after a song finishes playing or is skipped, after rating modifications are provided.  At the moment I'm trying to get some data from a smaller library to decide on how to model the normalization.  My goal is that eventually the ratings modified by normalization and play/skip etc can be a good indicator of what songs are currently most appreciated.  I'm also looking at tracking related information, like highest rating achieved, rating decay rate, and probably a few others for individual songs, and attention spread over [period] for libraries.  I'd be using these for various custom Weighted Random systems.

Ok, so I've been working on my datasets, and I'm quite happy with the data model.  The current theory is that after EpicRating changes a rating (it should not be done after a manual rating change) that calculations will be done to adjust ALL ratings.  This will very likely be done with some fairly simple calculations (mean, std dev, z-score, percentile re-conversion).

The issue is that songs that hold the same rating have nothing to distinguish them from each other, so the results aren't as spread as they ideally would be for a sustainable rating system.  The conclusion that I've reached is that statistical diversity needs to be introduced, and done in such a way as to keep the differences meaningful without them being large. (call it RatingScore?)

At the moment that would likely mean using a meaningless measure rule 2 (below) to resolve rating-space conflicts.  My hope is that once GMB starts keeping a log of activities, the rating normalization can pull some information from logs to resolve the issue.

Example:
Let's say 5 songs have a rating of 75.  In order to place them properly, ideally we want them each to have a different number.  If GMB does not have a log of events, then any statistical spread would need to be introduced through the Most Recently Played (say, have it add some small decimal number based on how recently it was played).  This will not resolve ALL conflicts, but should resolve most of them.

The most meaningful resolution would be if GMB does keep a log.  Current theoretical model:

1) If multiple songs are rated "75" -> Check to see if they have a "trend" (previous rating change).  If they have a positive trend history (song used to be rated lower, is now rated higher), add 0.1 to the Rating Score.  If they have a negative trend history, subtract 0.1 from it.

In plotting how to change a rating, previous rating changes are the most relevant modifier available.

2) If there are still multiple songs with the same rating score (which means they share the same trend/lack of trend with the other "conflicts), decide the matter by adding 0.09 to the most recently played, 0.089 to the next most recent, etc, until conflicts are resolved.

3) If there are STILL songs with conflicts, it means they have no trend and have not been played (IE, rating was set manually, song was not played/skipped) then add 0.005 to the song that has been modified (in any way) the most recently, 0.0049 to the next, etc.

4) If there remains any conflict, it means that the songs in question have been set manually as a group (modified at the same time) and have never been played/skipped.  In this case, add 0.0001, 0.0002, etc based on some arbitrary value (hash of song?  file name?)

What this will do is create a set of rating scores that are not shared by any 2 songs, allowing us to take full advantage of the z-score normalization.  Small differences (decimal) will have a minor impact, and the more/longer this system is used, the less later rules will be called on to resolve conflicts.

Hopefully we'll be getting the non-log version of this up and running soon, and get in some actual tests to make sure that it follows the data models.  This has been tested on a library of 10k songs in the following play configurations:  random, weighted random, filtered to play specific range of rating, filtered to groups of artists, filtered to specific album(s)/artist(s), and a few others.  I'm keeping my fingers crossed.  Hopefully some good news soon!

Dan

[ochosi]

i suggested this on irc already, but i thought i'd put it here again to keep it in mind:
i would suggest to make an action to convert the already-gathered play/skipcount to a rating. this way users wouldn't have to start from zero when starting to use your plugin. also: it would be good to not only make this a first-run option, because this way people could test different differentials etc for rating.

one more thing: the error message when libtext-csv-perl is missing could be a bit more verbose about the package that's missing.

[Nyzek]

i would suggest to make an action to convert the already-gathered play/skipcount to a rating. this way users wouldn't have to start from zero when starting to use your plugin. also: it would be good to not only make this a first-run option, because this way people could test different differentials etc for rating.

I'm still working on the model for this.  Most likely we'll get an option for unrated songs to be given a rating based on your EpicRating rules calculated with play/skip counts.  I don't know if there is a real scenario where you would want this to modify songs that already have a rating (let me know if you have one!).

D

[ochosi]

hey dan,
well i guess an option for unrated songs would be good.

reading your post from before again i have to say it sounds like you will work out a model that users won't have to customize (which is good imo). with my comment i was more targeting the current state of the plugin, where options have to be set by the user in order to make the plugin work with your listening-habits. that's why i thought that a function to reset the rating or recalculate it after tinkering with those options might be helpful.

[cardiacanesthesia]

hi
my first post
i was looking for a linux replacement of mediamonkey for 1 yr and finally got it. Thanks
i am not very good at commandline
i got this message while trying to activate the epic plugin
Can't locate Text/CVS.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.

pls help
Dr Subodh

[ochosi]

unfortunately the epicrating-plugin needs an additional package which is called "libcvs-perl" in many distributions, try to look for something like this in yours and install it, then the epicrating-plugin should work.