Fix shuffle

[tuvx 14]

I think over the last 2 years I have asked for this in one way or another, but am asking again that you please investigate and fix the shuffle issues, specifically with Playlists. I have playlists with multiple TV series giving over 1300 episodes. The shuffle feature seems to only shuffle certain shows, with some never being included. Even for the series included, 3 out of 5 times it shows the same shows included in the last 2 or 3 shuffles. Not sure if its related, but with Collections (as I have also noted many times), you are unable to see all the items as the list is truncated. Is it possible you have a small limit on Playlists like on viewing Collections?

[ebr 16212]

Hi.  This is not specific to this app and you recently had a discussion in the server forum about it, correct?

[tuvx 14]

No, I have had no discussions about it in over a year. Do you need me to repost there, or are you able to move?

[ebr 16212]

Okay, sorry, there was a recent discussion on this issue.

 

Right now it appears to be a limitation in the database implementation that we'll need to try and work around.  Computer "random" algorithms are notoriously bad at true randomness .

[tuvx 14]

I have not looked at the code, nor know what language you are writing it in, but I know with most random number generators there may be issues in using the system clock if you try to initialize each time. Would a possible solution be to keep a file of all entries indexes from the list and to use for selecting the play item? When an item is played (using shuffle) its index is removed from the list, thus preventing it from being played again. This process may have a reset after a certain number of days/shuffles (where all items are returned to the index list). Just a thought. 

[tuvx 14]

Another thought, in an attempt to play things that seem to always be missed, generate two random numbers with the first being the start for the second. For example, with 1400 items generate a random number between 1 and 1400. If the result is 400, then generate a second random number between 400 and 1400 to decide what to play. To further shuffle, reverse the order occasionally, where if item 800 is chosen actually play 600 (1400 - 800)

[ebr 16212]

Right now we're using the SQL sort order "Random" which, as we've recently discovered, is using an unseeded generator so it isn't a surprise that it is pretty bad at any sort of unrepeatable randomization.  

[tuvx 14]

When you create a playlist table on the fly, with an additional field populated using a linear congruential generator function? Then you could sort by that field.