Bug 207155

Created attachment 37133 [details]
Amarok 2.2 RC1 screenshot

Sorry was planning to comment that attachment...

Anyway I had manually fixed all tracks and now in amarok 2.2 RC1 my negative scores are back... (also visible is bug 207153 in the form of tracks with a duration of 0:00 in the playlist)

The 0:00 duration bug is already fixed. Try do a full rescan of you collection and restart amarok. This might also fix the score problem. If not those two are unrelated.

Luca, you will need to upgrade, this should be solved in Amarok 2.2.1.
Once upgraded, do a full rescan of the collection, then restart Amarok, which should fix all score and track length problems.

I would, but I have hit a gentoo bug ( http://bugs.gentoo.org/show_bug.cgi?id=290662 ) which makes amarok crash at startup...  I will try to rescan as soon as the gentoo team get their issues sorted :)

Ok I have upgraded amarok, performed a full rescan of my collection and both bugs live on!!! :@  The 0:00 bug occurs in entire albums while the score bug is rather sporadic, but does tend to hit the 0:00 tracks.

Luca to which version of Amarok exactly did you upgrade? Also, it's not only the full rescan, you need to restart Amarok right after that.

Amarok 2.2.1, and I restarted.  Could it be that the scores are not being "fixed" but simply aren't being ruined anymore?  I'll try editing them all by hand and seeing if they behave.

(In reply to comment #8)
> Amarok 2.2.1, and I restarted.  Could it be that the scores are not being
> "fixed" but simply aren't being ruined anymore?  I'll try editing them all by
> hand and seeing if they behave.

Hm, I don't really understand what you mean with "aren't being ruined anymore".

Sorry.  Anyway what I meant is that tracks that had normal scores would suddenly turn into immense negative ones for no apparent reason.  I have now manually edited all scores to a normal value and I will wait and see if they turn negative again.

Thanks for the info.

Ok I can confirm that the bug is still present.  It seems to only strike tracks that have 0:00 length.  If I play a 0:00 track, and finish playing it, the score is updated normally.  If I skip the track in question (which in normal situations would slightly lower the score), the score becomes massively negative... :(

does it help to remove the database?
It's in $HOME/.kde4/share/apps/amarok/mysqle

Make a backup first: all the ratings will be lost.

It does not I am afraid.  I start Amarok, the database is scanned, I play any 0:00 length track (which are still there and are the same ones as before), skip it and voilà the score goes from 0 to something hugely negative.

Are you sure these files are not damaged? Is the right length showed in other players? Try eyeD3 or id3info if they are MP3s.

Hello,

I can also confirm this bug. Skipping a 0:00 length track causes negative score.

Seems that having a negative score in the database confuses random playing favoring higher scores. It will only play the first track in the playlist. Other random modes work fine.

This might be because of damaged file (can't confirm it anymore, deleted the file stupid me...) but anyway I think that Amarok should always check before saving insane scores to the database and random playing should not stop working because of invalid scores (different bug perhaps?).

I have done some testing and the 0:00 track length bug also exists in Juk, suggesting an underlying phonon issue.  The hugely negative scores must be due to some sort of misbehaviour in Amarok though.  In any case the tracks display correct length when opened in mplayer, for example.

Can you reproduce this with current Amarok 2.2.2 or latest git? Please all, do a full collection rescan, then restart Amarok again before testing.

Very much so.  Using amarok 2.2.2, after a full rescan and amarok restart, I skipped a track with duration 0:00 and surely enough said track now has a score of exactly -1073741824 :P

I just tried opening these tracks in mplayer again, and I noticed that while mplayer does provide a playtime, this playtime is most definitely wrong.  I suspect there is something wrong with my tracks, but there again that shouldn't ruin the scoring algorithm...

On a side note, any ideas as to what is wrong with these tracks??

No, not really, you should check those with a mass tagging software where you can make the necessary changes to the track length and see if this solves the problem.

*** Bug 226752 has been marked as a duplicate of this bug. ***

I have a suspicion about this:

EngineController.cpp:        m_currentTrack->finishedPlaying( double(pos)/double(length) );

if the length of the track is close to zero, then this division will become a very big number. Maybe even that big so we hit an overflow and the value gets negative.

From there we go to SqlTrack::finishedPlaying( double playedFraction ), where we hit setScore( Amarok::computeScore( score(), playCount(), playedFraction ) );

and there we end up in this:

-----
const int percentage = static_cast<int>(playedFraction * 100);
        double newScore;

        if( playCount == 0 )
            newScore = ( oldScore + percentage ) / 2;
        else
            newScore = ( ( oldScore * playCount ) + percentage ) / ( playCount + 1 );

        return newScore;
-----

Which will return a quite insane low value.

Can someone provide me with such a false zero length track?

I am afraid that I fixed all my b0rked tracks by running vbrfixc on them.  I believe it was all vbr tracks which were misbehaving, but no more!  Needless to say, it is all copyrighted material anyway...  Should have kept a broken one as a sample :S  Sorry.

I can confirm this bug too. Occurred at least in 2.2.2, upgraded to 2.3.0 today, did a full collection rescan and Amarok restart right after the rescan (had 1 track playing during the rescan though) and nothing changed.

A false zero length track for testing (see #22) can be found at: http://archives.bassdrivearchive.com/1%20-%20Monday/The%20Cycle%20Decompression%20Sessions%20-%20Spinn/2009/Oct/%5B2009.10.02%5D_The_Cycle_-_Spinn_%5Bwith_Deep_Z%5D.mp3 (<strong>Warning: 166MB file!</strong>)

Also just about any .wav file I used in Amarok (at least in recent months with 2.2.x) has a length of 0:00, so converting a file to .wav might also work. I just did a quick test with 1 mp3 converted to wav and it also had a length of 0:00; a quick conversion can be done using 'mpg123 -w out.wav in.mp3'.

I just tested this with Amarok built from GIT yesterday, and the one file I found with length 0:

Length:
0:00
Bit rate:
112
Sample rate:
44100
Size:
1.1 MiB
Format:
ogg


Score:
-1610611824
Rating:
3.5
Play Count:
1
First Played:
11/10/09
Last Played:
11/10/09
Collection:
Local Collection

What I did to get the score from 50 to -1610611824, was to start it playing a couple of times, then skip ahead to something else.

*** Bug 255366 has been marked as a duplicate of this bug. ***

*** Bug 266105 has been marked as a duplicate of this bug. ***

Will commit a patch against this today.