Summary: | Automatic play list is not very random or mixed | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | BK <bk+bugzilla> |
Component: | Playlists/Automated Playlist Generator | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | stharward |
Priority: | LO | ||
Version: | 2.3.1 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 2.5 | |
Sentry Crash Report: | |||
Attachments: | Preset |
I haven't been able to reproduce the lack of balance when selecting a small number of artists, but I'll keep it in mind when doing some future tweaks to the Generator. Have you tried different sets of artists? What about two artists that are pretty evenly represented in your collection? Could you do a chi-squared analysis of at least 1000 playlist generations, with appropriate multiple-testing corrections (eg, Bonferroni)? Just kidding on the last one. The "% of playlist matches" is possible to implement, but unlikely, because I agree that it's counterintuitive. If the current Bias system is ever removed, I'll consider putting it in. So, to sum up, I'll keep this bug open as "wishlist" items. Git commit 98b561e2b738b55e3b9d94b4e6c6cd28f73261c6 by Soren Harward. Committed on 30/09/2011 at 17:24. Pushed by stharward into branch 'master'. Overhaul of Automated Playlist Generator algorithm Completely rewrote the ConstraintSolver to use a genetic algorithm rather than simulated annealing. This trades off some speed for a vast reduction in the amount of code needed to write individual constraints, and makes the whole component less prone to crashing. BUG: 240927 BUG: 240301 M +4 -0 ChangeLog M +0 -3 src/CMakeLists.txt M +1 -14 src/browsers/playlistbrowser/APGCategory.cpp M +1 -1 src/browsers/playlistbrowser/APGCategory.h M +2 -2 src/playlistgenerator/Constraint.cpp M +1 -1 src/playlistgenerator/Constraint.h M +19 -270 src/playlistgenerator/ConstraintGroup.cpp M +9 -23 src/playlistgenerator/ConstraintGroup.h M +2 -8 src/playlistgenerator/ConstraintNode.cpp M +6 -23 src/playlistgenerator/ConstraintNode.h M +206 -209 src/playlistgenerator/ConstraintSolver.cpp M +34 -21 src/playlistgenerator/ConstraintSolver.h D +0 -55 src/playlistgenerator/ConstraintTestWrapper.cpp D +0 -44 src/playlistgenerator/ConstraintTestWrapper.h D +0 -335 src/playlistgenerator/ConstraintTester.cpp D +0 -85 src/playlistgenerator/ConstraintTester.h M +1 -1 src/playlistgenerator/Preset.cpp M +3 -3 src/playlistgenerator/TODO M +128 -188 src/playlistgenerator/constraints/Checkpoint.cpp M +20 -66 src/playlistgenerator/constraints/Checkpoint.h D +0 -321 src/playlistgenerator/constraints/CheckpointSupport.cpp M +1 -1 src/playlistgenerator/constraints/Matching.cpp M +5 -5 src/playlistgenerator/constraints/Matching.h M +18 -136 src/playlistgenerator/constraints/PlaylistDuration.cpp M +3 -22 src/playlistgenerator/constraints/PlaylistDuration.h M +14 -82 src/playlistgenerator/constraints/PlaylistLength.cpp M +4 -22 src/playlistgenerator/constraints/PlaylistLength.h M +74 -322 src/playlistgenerator/constraints/PreventDuplicates.cpp M +2 -94 src/playlistgenerator/constraints/PreventDuplicates.h M +6 -101 src/playlistgenerator/constraints/TagMatch.cpp M +2 -15 src/playlistgenerator/constraints/TagMatch.h M +1 -1 src/playlistgenerator/constraints/TagMatchComparer.cpp M +1 -1 src/playlistgenerator/constraints/TagMatchSupport.cpp M +25 -289 src/playlistgenerator/constraints/TrackSpreader.cpp M +6 -62 src/playlistgenerator/constraints/TrackSpreader.h http://commits.kde.org/amarok/98b561e2b738b55e3b9d94b4e6c6cd28f73261c6 |
Created attachment 47540 [details] Preset Version: 2.3.1 (using KDE 4.4.3) OS: Linux I've created an automatic playlist preset as per the included screenshot, basically asking for a playlist of around 1 hour (but don't seem to matter if I increase this), no duplicates, at least 3 star from two artists, X and Y. On generating playlists, the resulting playlists tend to have at most one or two tracks by artist Y, and all the rest by artist X. Now, granted, that _technically_ meets the _constraints_ specified (as there is no way to specify what fraction of the total each artist should represent). It does, however, not meet _expectations_. Now, in my database I have about a 3:1 ratio of artist X to Y, but the ratios in the generated playlists are fairly consistently worse than that, and besides, if I list two artists in the preset, I would _expect_ that they would be represented in the generated list in (roughly) equal proportions. This said, my preferred solution would be if I were either permitted to specify a fraction, or if the playlist length could be specified per subgroup, i.e.: "Match all" group playlist length: 2:00:00 "Match all" group local playlist length: 0:45:00 tag artist: "X" "Match all" group local playlist length: 0:30:00 tag artist: "Y" tag rating: >2.5 and get a 2 hour playlist of 3-star or better tracks consisting of 45 minutes of artist X, 30 minutes of artist Y, and the remaining 45 minutes mixed music by artist other than X or Y Of course, I would rather have it be something like: "Match all" playlist length: 2:00:00 40% tag artist: "X" 30% tag artist: "Y" tag rating: >2.5 ...but having the fraction generated by "tag artist" be a function of either its position in the preset, or the number of matching fields in the database is rather counterintuitive. Reproducible: Always Steps to Reproduce: Well, not _quite_ every time, but damn near. 1. Create preset. 2. Generate playlists. 3. Boggle over the result. Actual Results: Playlist looks like: X X X X X Y X X X X Expected Results: Ought to look like: X X Y X Y Y X Y Tried swapping order of "tag artist" entries, same result, so does not seem to be due to order in the preset. Also tried changing artist X for artist Z, where the ratio of Y to Z was 3:1, and then Y was wildly overrepresented in the generated lists. It appears that the generation somehow magnifies the ratio in the database. I.e., a ratio of 3:1 in the database often generates a playlist where the ratio is 6:1 - 9:1.