Re: [Banshee-List] Scoring question

[Isaac Witmer <isaaclw gmail com>]

On Thu, May 12, 2011 at 11:09 PM, Michael Martin-Smucker
<mlmartin13 gmail com> wrote:
>
> > I suppose PlayCount=1, SkipCount=1 results from a bug in handling EOS
> > (EndOfStream) while gapless playing.
> You had said in your test case that gapless was turned off, but it would make sense that gapless is causing this, because there are several known issues with gapless incorrectly increasing play count.
> > I wonder why there is a PlayCount value in database that doesn't contain the
> > count of plays. If I want to know the total count of plays I have to add
> > PlayCount + SkipCount.
> ...
> > PlayCount = PlayCount + SkipCount
> Your definition of a "play" is different from every media player I've used, and I think changing this would cause a lot of confusion.  I don't know of any player that will increment a song's play count if you only listen to the first 5 seconds of a 4-minute song. Last.fm requires you to listen to 50% of a song before it is considered played (same as Banshee), and IIRC, iTunes doesn't consider a song "played" until you've listened to about 90% (but that may have changed in the past 3 years).
> So while this could be a simple database migration, I think it would break a lot of users' expectations about what constitutes a "play."


Actually, with amarok (version 1.4), if a song starts playing and then
a skip/stop event happens (no matter where) it counts as a play. That
version of amarok doesn't store skip counts.
I'm not familiar with version 2, but I don't think they changed it.

To me this makes sense...but only because of how I organize my smart playlists.
If I skip a song several times, then i don't want it showing up in my
"low playcount" list, even if I never actually managed to listen
through it the whole way.
Songs like that I should probably delete, though, so I'm just throwing
my two cents in.

>
> > SkipCount = Playcount * (1 - Score/100)
> This seems backwards to me.  A song's Score should be based on the SkipCount (among other things), not the other way around.  Currently, the Score calculation is very simple: if you press the "next" (i.e. "skip") button and you've listened to less than half of the song, the skip count increases by one.
> > The idea to use percentage of played songs as Score value is not bad, but
> > the actual Score value only reflects the "mean played length" of a song in
> > percent. It doesn't take into account how often a song has been played.
> I agree that this isn't ideal.  I like the suggestion in Bug 638966.  Basically, if we treat each song as if it has been skipped once, then playing a song would gradually increase its score toward 100 without ever reaching it.  This would keep the score algorithm almost exactly the same, but a song with 30 plays and 1 skip would have a higher score than a song with 1 play and 0 skips.
> Michael
> On Thu, May 12, 2011 at 4:31 AM, Freddy-N <freddy-neumann arcor de> wrote:
>>
>> @ Brian Lucas-3
>>
>> I wonder why there is a SkipCount value in database that never is used in
>> calculation. The skip-event is not triggered after half of the song has been
>> played.
>>
>> I wonder why there is a PlayCount value in database that doesn't contain the
>> count of plays. If I want to know the total count of plays I have to add
>> PlayCount + SkipCount.
>>
>> The idea to use percentage of played songs as Score value is not bad, but
>> the actual Score value only reflects the "mean played length" of a song in
>> percent. It doesn't take into account how often a song has been played.
>> Therefore PlayCount and SkipCount should contain total count of plays and
>> total count of skips in order to get an easy and clearly system to select
>> preferred songs. In TrackInfo.cs the function OnPlaybackFinished() requires
>> a modification.
>>
>> It is also possible to migrate the database without breaking anything.
>>
>> PlayCount = PlayCount + SkipCount
>> SkipCount = Playcount * (1 - Score/100)
>>
>> From now on the values of PlayCount and SkipCount contain their total counts
>> in database.
>>
>>
>> BTW: Miscalculation of Score value results from bugs in event handling. That
>> must be fixed.
>>
>>
>> --
>> View this message in context: http://banshee-media-player.2283330.n4.nabble.com/Scoring-question-tp3497316p3516755.html
>> Sent from the Banshee Media Player mailing list archive at Nabble.com.
>> _______________________________________________
>> banshee-list mailing list
>> banshee-list gnome org
>> http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
>
>
> _______________________________________________
> banshee-list mailing list
> banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)