When i try to create a dynamic playlist by Last.fm similar songs creation takes a lot time
Steps to Reproduce:
1. Drag one song into you playlist, play it and stop playback
2. Create a new dynamic playlist with "Last.fm Similarity"
3. Select Similarity by "previous song" or "previous artist" (both did not work here)
4. Click populate playlist
The progress is shown in left bottom corner and the creation of the dynamical playlist takes very long.
Amarok uses the last played track, and retrieves a number of similar songs by Last.fm's API
I guess Amarok analyzes the whole collection for similarity rather than the one song.
I did some further research on this issue, it seems that Amarok tries to populate the playlist with last.fm similarity but instead of using the previous song it uses some random tracks.
Also the when new similar tracks are appended after playing one song it definitely does not use Last.fm similarity engine because for example when I play ACDC it appends something like Rihanna.
Can someone confirm this issue too ?
Seems that this issue is related to these bugs (that are eventually duplicates):
Amarok tries to generate a similar playlist by the last played song, but it cannot determine the last played song, because of the bugs above, thats why he takes a lot of random songs and sends them to last.fm (debug confirms this here). after a lot of time, a broken similarity playlist by the random songs is created.
Well spotted, thank you. Marking the dependency.
I checked the lastfm bias and have some fixes ready for commiting.
It seems that there were several issues, but nothing specific with the "similar to last track".
If you look at the debug output you will see that lastfm takes around 1 second to reply with a similar track. I don't now if they are slowing down their responses but I would do that.
So in order to fill a list with 50 songs it will take at least 50 seconds.
That is if you have the similar tracks available and the generator don't need to go back to try some other songs.
At least I fix the progress bar so that it shows what's going on and the generation doesn't stop if you don't get a valid response.
One point I forgot.
The results will be cached, so bit by bit the generation will get faster until you have similar tracks for everything in your collection.
FIxed by Ralf, commit hooks were apparently disabled when he pushed. :-(
I cannot confirm this behaviour. Creating an initial dynamic playlist takes over 300 seconds for me in Amarok 2.7. Maybe i am doing something wrong here....
Steps to reproduce this:
1. Listen to a song you want similar tracks for. Wait till it is finished. Ensure that only this song is in your current playlist.
2. Create a dynamic playlist based on last.fm similar to the previous track.
3. Double click the playlist for 1 previous and 10 following tracks.
The generation starts and takes very long (~300 seconds) for 10 tracks. With the result, that the created playlist is absolutely not similar to the track you listened previously.
Sighting the debug it seems that the dynamic playist at first creates a random playlist with about 200 songs and then gets the similar songs for this playlist. I will also add the debug file in this report.
Created attachment 76859 [details]
The debug output can be a little bit confusing but you see that the optimizer is starting up asking a lot of songs with no cached "similar".
A line like this gives a number of the cached queries:
amarok: similarArtists: 0 similarTracks: 341
That is actually the end result. So the optimizer actually ended up creating a playlist without first getting all the information.
I can see from the debug that you started out with 270 cached similar tracks.
As I wrote above it will get faster as soon as you have enough cached results for the tracks.
Git commit 093177d4d8f86098b75d4a2ff28e23d4d0ceba6d by Ralf Engels.
Committed on 06/02/2013 at 18:38.
Pushed by rengels into branch 'master'.
Update Dynamic playlist. Get rid of energy optimizing code
The dynamic playlist always used to optimize the generated tracks
by different ways.
However the new biases all have hard conditions. The user also
used to see it like this and was confused if a "pretty good" result
The new algorithm will generate an empty list if the conditions
cannot be fullfilled
Related: bug 286642, bug 292648, bug 304374
M +4 -0 ChangeLog
M +10 -37 src/dynamic/Bias.cpp
M +17 -31 src/dynamic/Bias.h
M +46 -411 src/dynamic/BiasSolver.cpp
M +21 -69 src/dynamic/BiasSolver.h
M +6 -7 src/dynamic/BiasedPlaylist.cpp
M +2 -1 src/dynamic/BiasedPlaylist.h
M +7 -2 src/dynamic/TrackSet.cpp
M +9 -7 src/dynamic/biases/AlbumPlayBias.cpp
M +2 -2 src/dynamic/biases/AlbumPlayBias.h
M +14 -15 src/dynamic/biases/EchoNestBias.cpp
M +2 -3 src/dynamic/biases/EchoNestBias.h
M +7 -11 src/dynamic/biases/IfElseBias.cpp
M +3 -4 src/dynamic/biases/IfElseBias.h
M +51 -39 src/dynamic/biases/PartBias.cpp
M +3 -5 src/dynamic/biases/PartBias.h
M +5 -4 src/dynamic/biases/QuizPlayBias.cpp
M +2 -2 src/dynamic/biases/QuizPlayBias.h
M +4 -5 src/dynamic/biases/TagMatchBias.cpp
M +2 -2 src/dynamic/biases/TagMatchBias.h
M +6 -6 src/services/lastfm/biases/LastFmBias.cpp
M +2 -3 src/services/lastfm/biases/LastFmBias.h