Page 16 of 64

Posted: Fri Feb 15, 2008 3:51 am
by Big_Berny
Here's a really small script that shows the rating. Just follow the instruciton below to install it. Then select one of these songs, go to Tools/Scripts and a Message with the Rating will appear.

Code: Select all

'1. Save this text as 'test.vbs' in the Scripts-folder of MediaMonkey
'2. Add this Section to Scripts.ini

'[Test]
'FileName=test.vbs
'ProcName=test
'DisplayName=test
'Description=test
'Language=VBScript
'ScriptType=0

'3. restart MediaMonkey
'4. you'll find "Test" under Tools/Scripts

Option Explicit 
Sub test
	Dim list,i
	
	Set list = SDB.CurrentSongList
	If list.Count = 0 Then
		i = SDB.MessageBox("There are no selected tracks.",mtInformation,Array(mbOk))
		Set list = Nothing
		Exit Sub
	End If

	Dim Song : Set Song = list.Item(0)
	i = SDB.MessageBox(Song.Rating, mtInformation, Array(mbOk))
End sub

Posted: Fri Feb 15, 2008 5:35 am
by spacefish
Big_Berny wrote:But as I said since 3.0 it's really easy to rate songs by accident - it happened here a lot and I needed some time to figure that out.
I appreciate that you believe I've accidently rated tracks but I haven't. Ratings aren't even visible in the window I use so I wouldn't click on that field by accident. And since the first time I reported this, there were over 11000 tracks with an MR code, I would have had to be a very clumsy clicker, not to mention a busy one.

I wish I still had those 11000 tracks to test but I don't now. I ran your little script and found that all the tracks leftover in the MR playlist have a rating of 50, 2.5 stars. It is absolutely impossible (yes, it is) that I accidently rated all of these myself. For the case of The Well-Tempered Clavier, I would have had to set the rating exactly the same on 48 tracks! My suspicion still stands: that something about the process of updating properties with a BR or AR present, while not touching the Rating drop-down, causes MM or the script or whatever to think that the rating was set manually when OK is pressed. I don't know if perhaps that's a bug in MM and the script picked it up or a bug in the script which hopefully you've fixed now.

I'll just keep don't overwrite manual ratings disabled until the script updates them naturally over time. Thanks for the update! I hope we're finally done now. ;)

Posted: Fri Feb 15, 2008 10:51 am
by Big_Berny
The problem with the 11000 tracks is a bug in the script. This has been fixed.

But the 48 tracks can't be rated by the script, I'm sorry! :) You can check the code, the script just can't put a rating of 50! Maybe it was a shortcut. For example everytime I wand to write an '@' MM rated a song with 2 stars for example. The problem is know by the devs. If it's really a bug then it has to be in MM... or another script... Because when updating the properties of a song my script doesn't run. It only runs when you start a song.

I'll wait one or two days anyway so that if there's really a bug it can't be fixed before 2.1 final.

Thanks btw! :)
Big_Berny

Posted: Fri Feb 15, 2008 12:35 pm
by spacefish
Big_Berny wrote:The problem with the 11000 tracks is a bug in the script. This has been fixed.

But the 48 tracks can't be rated by the script, I'm sorry! :) You can check the code, the script just can't put a rating of 50! Maybe it was a shortcut. For example everytime I wand to write an '@' MM rated a song with 2 stars for example. The problem is know by the devs. If it's really a bug then it has to be in MM... or another script... Because when updating the properties of a song my script doesn't run. It only runs when you start a song.
It's impossible that all these were manually rated 2.5 stars with a hotkey since it would have taken 2 combinations to achieve the half-star. Even if my Danish keyboard (Alt-Gr) triggered it, which I doubt, I would have expected a lot more than 53. I press that key fairly regularly but not in combo with the 7 key '{' which is where the half-star would come.

Note that all of them have 0 playcount. They did at one time have a BR since I rated nothing manually in my library, and my BR is 2.5 stars. There's no way I clicked on 2.5 stars for all these tracks. /shrug

Anyway, hopefully once they get played, the MR will disappear. I guess that's it.

Posted: Fri Feb 15, 2008 1:05 pm
by BerniPi
I figuered out, that the "1/log(Played+1.01)" caused the overflow problem.

So the formula without it, is:
10000000000 * (log(Played+1.01) - (log(Skip+1.01))^1.7) / DaysSinceAdded^0.125 / 1.001^( DaysSinceLastPlayed)
I tried to find a formula, which can differ nonplayed-songs with different skips, and which not only give them 0 points.

A possible solution is:
500000000000+10000000000*(log(Played+1.01) / 1.001^( DaysSinceLastPlayed) - (log(Skip+1.01))^1.7) / DaysSinceAdded^0.125
@Berny: I had to move the DaysSinceLastPlayed to the Played, because it isn't defined for never played songs. A redefinition to 0 for 0-played songs in the script would solve that problem.

Berni

edit: I just tried with the greatest possible values of plays and skips.
I chose the offset of the formula in such way, that it can't get negative with 9999 skips.
Also i tried to simulate an overflow with very much plays, i gave up at 10^999 (that is a number with 999 zeros, for comparison: we think that our universe contains 7*10^22 stars) and i didn't reach 9999999999999999. my calculator can't handle more :lol:

edit2: the customfield has place for points till 10^16-1, but in the script the bound is set to 10^15-1. Is that for purpose or a failure?

Posted: Fri Feb 15, 2008 3:24 pm
by Big_Berny
@spacefish: You're right, with one click you can't do an half-rating in MM without additional script.
Anyway I don't think that that bug is still a problem anymore. But I'll check it again the next days.

@BerniPi: Yes, I had to limit it to 10^15-1 because MM rounds after that number and returns 10E15 and stuff like that. Unfortunately I saw that bug after I set the length in the customfield to 10^16-1. But it's not really a problem.
EDIT: And thanks for the formula and the thing with never-played songs. I'll have look. But the formula itselfs I'll implement in the next version after some tests. Because I'm quite happy that all is working now! :)

Big_Berny

Posted: Sat Feb 16, 2008 5:44 am
by Guest
thank you Big_Berny.
the "rate all my library automatically the first time I play" feature is great

Posted: Sat Feb 16, 2008 6:17 am
by BerniPi
I just discovered a new use for the offset-formula:
if the skipcount^1.7 is greater than the playcount, the song gets 0 points from a formula without offset. dayssincelastplayed and dayssinceadded can't have any influence on the rating. with the new formula the script can differ in this cases...

of course the offset can also be implemented for the "regular" formula, but the dayssincelastplayed have to operate directly on the playcount...

an example:
5000000000000-100000000 * (Played / 1.01^DaysSinceLastPlayed - Skip^1.7)^3 / DaysSinceAdded^0.5
the problem is, that the influence of the skipcounter grows with the dayssincelastplayed. so the solution is not ideal.

Posted: Sat Feb 16, 2008 8:27 am
by BerniPi
I have discovered an error in reasoning:
There should be brackets around the formula before divding through dayssinceadded, for having the correct effect (decrease the points, not increase)

(500000000000+10000000000*(log(Played+1.01) / 1.001^( DaysSinceLastPlayed) - (log(Skip+1.01))^1.7)) / DaysSinceAdded^0.125
edit: Is the influence of DaysSinceAdded too great? What are your experiences? I'm now testing with 0.05 instead of 0.125. Maybe it's better. (I try this, because I try with a new built database and a song with 2 skips was better rated than a 1 time played songs, because the dayssinceadded was one less!!

Posted: Sat Feb 16, 2008 9:43 am
by Big_Berny
I haven't tested that formula yet, but I don't see the logic behing it.

My formula was first:
Played^2 * PlayedPerDay (=Played/DaysSinceLastPlayed)

That's why the formula is "Played^3/DaysInLibrary". Then I introduced the Skip so that it became (Played-2Skip)^3/DaysInLibrary. And after that I intruduced DaysSinceLastPlayed so that the values get a bit mor variance which specially is important if you have low numbers and all points are very similar.

I'm now developing a linear formula as I said already before. Because this solves most problems and because the ratings aren't calculated directly anyway (because the points are simply here to create the list) it's just important what the different weights of the different variables is.

EDIT: I use a statistic program to create that formula. If someone wants his own formula based on his own manual ratings just contact me!

Posted: Sun Feb 17, 2008 1:31 am
by spacefish
Something is definitely going on.

After playing The Well-Tempered Clavier yesterday, my MR autoplaylist got down to 5 files. I though yay! It's working. BUT...

This morning there are 15 files in this list: 10 new ones! All of these new tracks I edited in some way yesterday. They all have 0 plays and a (base) rating of 2.5 stars. These are also tracks I edited individually and not as part of a multi-track edit. There's something about that last bit. I also tagged The Well-Tempered Clavier track by track and all 48 tracks were originally on the list. I wonder if editing tracks individually via the properties window is causing the BR to be resaved and so the next time ARA passes over the track it sees that updated rating and sets an MR to it.

Update: The latter is indeed what's happening. I tested this with a few tracks and got the same result each time.

Select a track with a BR code.
Edit track properties.
Click OK.
Run AutoRate via toolbar button.
That track now has an MR code.

The above is also occurring on startup the first time ARA runs and it only happens on tracks with Base Ratings that I can see. I tested on tracks with AR and they retained the AR code even after recalibrating.

Posted: Sun Feb 17, 2008 2:42 am
by Big_Berny
@spacefish: Thanks, I'll try to reproduce it later. I have an idea now. To be honest I don't know why I didn't get that idea before. Maybe i'ts really a bug in MM which causes that a song with a rating of 48 (2.5 stars) for example after editing get's saved again with 2.5 stars but tis time MM sets it to 50. It interpretes the rating and saves it again which results in other ratings afetr editing. If this really is the cause then it's a bug in MM. It's only strange that it only seems to happen with BR songs and not AR.

Posted: Sun Feb 17, 2008 3:37 am
by spacefish
It's probably got something to do with the base rating itself. Is it possible that MM does not see your Base Rating and therefore thinks there is none until OK is pressed? My thought is that the AR is fixed when the track plays; probably a function sets the rating just as if I had set it manually. When ARA sets a Base Rating, it is only for tracks with 0 playcounts. Since a track can never be set to BR once played (without clearing the ratings or playcounts), perhaps the communication about that rating is different from AR. Something to think about.

Posted: Sun Feb 17, 2008 5:30 am
by spacefish
Something I noticed when looking at MonkeyRok statistics for ratings.

I've got 3 entries listed for 2.5 stars
20 tracks
421 tracks
10863 tracks
Now, assuming MonkeyRok would only display each rating once, I thought "Hmm... 3 listings for 2.5 stars. ARA has 3 ratings codes. Hmm..."

So, in addition to my existing MR autoplaylist, I made autoplaylists for AR with 2.5 stars and BR with 2.5 stars and this is what I got:
20 tracks <-- MR with 2.5 stars
421 tracks <-- AR with 2.5 stars
10863 tracks <-- BR with 2.5 stars
The numbers are exactly the same. Something is different about each instance of a rating with 2.5 stars, just as if they are different ratings. I don't know if this would affect actual manual ratings (i.e. tracks would appear twice in MR's ratings list) as I don't have any of those. I do however think this is very interesting. All things being equal, shouldn't an autorating of 2.5 stars be the same as a base rating of 2.5 stars or a manual rating of 2.5 stars? What is it about the different ratings codes that causes these to be displayed as unique ratings in MonkeyRok? I only have one node for 2.5 stars in the MM default tree but we've already seen that editing the properties of a base rated track causes the script to see it as a manually rated one.

Curiouser and curiouser!

Play History and Autorate Script Conflict

Posted: Sun Feb 17, 2008 11:01 pm
by nynaevelan
Berny:

I am getting some kind of conflict between Autorate and Bex's Play History script, this is the error I get when I have both scripts active. I get the error with v1137 and v1140.

Image

I am posting this same message here as well as in the Play History forum because I do not know how to resolve or which script is the culprit. Although the error message is from the PH script, the next message says it is line 29 of the Autorate script. I did not get this conflict with the previous version of PH. Help please.

Nyn