Bug 113120

Created attachment 12708 [details]
patch to 1.3.2 to select playlists weighted by number of songs in each

I knocked up a little patch which does exactly as I mentioned above. 
It tests the number of songs in each of the potential playlists, then randomly
chooses a number out of the total, then figures out which playlist that
corresponds to, then randomly chooses songs from that playlist. 

Ideally we could implement this such that if we are choosing more than one song
they can come from different playlists. The trick is getting it to happen
without taking too much time. 

If you are testing this patch, consider implementing a way to cache the number
of songs in smart playlists (this would significantly increase the speed by
avoiding a number of select statements every time we want to add a song).

This problem is still present in 1.4-beta1

Created attachment 14796 [details]
Patch to 1.4-beta1 to weight playlists by number of songs

Basically the same as before, but count() is replaced with count(url).

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

it would be great if the percentage could be defined by the user not only by the lenght of the playlist. e.g. 15% HipHop; 30% Pop; Rest Rock.

Furthermore, dynamic list within dynamic list and shufle between lists only:
usage:
- dynamic list based on my favorites
- ordered list by last played
both combined into:
90% favorites (random play); 10% last played (oldest first)

That would also cover Bug 124763.

SVN commit 604494 by seb:

Refactor of dynamic mode. This revised implementation solves a number of bugs. The logic of adding tracks from a dynamic mode is now delegated to the DynamicMode object, and is not done within the playlist. When a dynamic mode is loaded, a cache of 200 elements is create from the playlist sources. By caching a subset of the possible tracks to be inserted, there is no longer a requirement to execute complex SQL statements on each track change or playlist repopulation. Additionally, by grabbing random tracks from this cache, items are no longer fetched from just one source, but all of them. Once these cached tracks have been inserted into the playlist, they are removed from the cache list in order to avoid duplicating song insertions. Once the cache has been depleted, it is simply regenerated. 200 elements is approximately 12 hours worth of music, so the set should be sufficiently large to handle the user's requirements.

I've done quite a bit of regression testing, but the more the merrier :). The only feature which needs to be fixed is the Suggested mode of dynamic playlists, but this should be easily rectifiable.

BUG: 134159
BUG: 137212
BUG: 107693
BUG: 130542
BUG: 133269
BUG: 113120


 M  +233 -14   dynamicmode.cpp  
 M  +51 -6     dynamicmode.h  
 M  +12 -204   playlist.cpp  
 M  +3 -4      playlist.h  
 M  +1 -1      playlistbrowser.cpp  

Is this cache really weighted by playlist length? It doesn't seem so. 

Yes, the creation of the cache does the weighting

Looking at line 139 of dynamicmode.cpp:

const int itemsPerSource = CACHE_SIZE / dynamicEntries.count();

It looks like the number of items added per source is constant. I can confirm that a dynamic playlist which chooses 2 sources - one with 72 tracks and the other with 4963 tracks produces a dynamic playlist with a roughly even number of each. 

Right, I think i misunderstood you. I'll have a think about this and
the best way of doing this.

On 13 Nov 2006 02:07:15 -0000, Bonne Eggleston <b.eggleston@gmail.com> wrote:
[bugs.kde.org quoted mail]

The way I did it in previous patches, was to find the total number of songs (add the length of each list together) and then randomly choose a list based on a weighted random number.
You could do a similar thing where you add length*CACHE_SIZE/total_length songs for each list when you rebuild the list. 
I would then add 1 if this number is 0 (because of integer division), so that small playlists don't always miss out. 

And how did you do it when there was a combination of static and smart playlists?

smart playlists don't have a defined number of elements.

I calculated the number of items in the smart playlist. From my original patch:

+//This subs the select part of the smart playlist sql statement for a count, then counts!
+int SmartPlaylist::length()
+{
+	QString sql = m_sqlForTags;
+	sql.replace(QRegExp("SELECT.*FROM",false), "SELECT COUNT(url) FROM");
+
+	QStringList result = CollectionDB::instance()->query(sql);
+	
+	if ( ! result.isEmpty())
+		return result.first().toInt();
+	else return 0;
+}
+

I submitted a change to SVN which has this functionality. Please test and let me know how it works for you. 

Reopen if necessary.

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