Bugzilla – Bug 8310
Not so random random selection
Last modified: 2016-11-27 21:10:32 UTC
I have noticed that the random selection feature is not very random -- at random times that is. I have about 1400 tracks in my system and understand that there will be a greater random representation for artists that I have more CDs for. However, this doesn't explain the fact that I noticed when I use a pretty broad random selection of genres (probably 20+), I still see a repetition of the same artist (sometimes same album) and notice a clustering around a relatively small range of letters. I have also noticed that many tracks selected are delightfully random. So, with the Squeezecenter, randomness itself seems to be somewhat random. I would like to understand better how the random function works and if there is any way to modify it so that it treats my entire catalogue in a more random way.
Your best approach is probably to discuss this in the forums if you haven't already, John. The url for our forums site is at http://forums.slimdevices.com. If you can better define the behavior you're looking for, or get more people interested enough to vote for this bug, we'll have another look.
The random problem is common to many people as far as I know. For example see the following thread on the forum: http://forums.slimdevices.com/newreply.php?do=postreply&t=55513 I vote for its resolution. Thanks.
I also do experience that the same albums and artist is prefered to others in the random mix. New tracks aalso seems to be prefered. An that is not random. I vote for this bug!
Hi, I know there have been some talks about randomness and the difficulties to handle it. Some improvements could be added rather easily I think. For example a test could be done to check when a candidate song is provided by "pure randomness" whether: - this song has been played in the latest x songs, - a song from the same album has been played in the latest x songs. This could allow to avoid to get 2 or 3 songs from the same album at a few songs interval. I thank you in advance.
*** Bug 17872 has been marked as a duplicate of this bug. ***
I'd like LMS to treat my music collection as nnn tracks and then randomly choose tracks. My experience is like many others here and in the forums, some artists and specific albums are greatly over-represented when LMS generates a random songs playlist. One artist in particular, for whom I have one 4-CD collection plus 6 other CDs, recurs every few listening sessions - but almost always with one of the tracks from the 4-CD collection. That's far more frequently than I feel a true random selection would bring up. My collection today is reported as containing 38746 tracks and 2764 albums.
Did anybody try 7.8? I've done some work on the RandomPlay plugin. I didn't address the randomness in particular, but some re-factoring and simplifications might have had an influence anyway.
Thanks for suggesting 7.8. I've upgraded 2 days ago, and the randomness seems to have improved. I am hearing tracks I haven't heard in ages, and no repeats from the same album yet.
After a while of running 7.8.0 - 1371043781 the problem re-appeared, just with different songs/albums than before. It seems the problem went away after installing http://www.issihosts/haveged/ on my NAS (QNAP TS-459 Pro+). Before /proc/sys/kernel/random/entropy_avail was always below 200 bits and with haveged running it never drops below 1024. I've made the haveged software into a ipkg which makes it easy to install if you have a x86/i686 based NAS like me: http://goo.gl/lT0lw4
I don't understand why haveged fixes the problem. RandomPlay's random track selection seems to be performed by sorting tracks in random order and then selecting the first "n" of them. The random sort uses sqlite's built-in RANDOM() function, and that function (RC4) is seeded just once -- the first time it's called -- with 256 bytes from /dev/urandom when it's running on Unix. After that initial seeding, /dev/urandom is never read again. (At least, that's the way it looks to me. The sqlite3 source is hard to read -- there are multiple layers of abstraction in front of every symbol -- but it seems clear that sqlite3_randomness() only seeds the PRNG when its static "isInit" flag is clear, and that it sets the flag after seeding.) When entropy_avail is very low, as it usually is in a NAS or other headless server, the /dev/urandom output might not be particularly random. But it SHOULDN'T HAVE TO BE for this purpose; I don't see how improving the randomness of that initial seed will directly affect the predictability of the random track selections produced by "ORDER BY RANDOM()". Nevertheless, I've tried increasing the available entropy on my ReadyNAS via haveged, and I agree with Richard van den Berg that doing so seems to make RandomPlay (and other random and semi-random playlist plugins) play a wider selection of music... So I've followed his lead and built a haveged addon for the OS4-based x86 ReadyNAS devices (Pro and Ultra): https://www.dropbox.com/s/m3mob6firvpw24o/HAVEGED_1.7b-x86-1.0.bin
That is the way I read the sqlite source too. Perhaps the sqlite database is reopened often within LMS, causing the sqlite RANDOM() function to be reinitialized.