I mainly use the web player, so I’m not sure if this feedback applies only to that or if all the platforms work the same way.
I’m a former Grooveshark developer, so my expectations for how a player should work may be a little biased, but one of the things I feel we got really right, is shuffled playback.
Plex seems to use a naive approach to shuffle wherein no state is maintained, so back and next always move on to a random song, meaning if you accidentally skip a song, you can’t go back to it! Here’s how I think shuffle should actually work:
-
Remember state. When shuffling through a queue, the future should be a mystery - who knows what will play next! - but the past is still the past, it should be fixed. If I want to go back to that song that played 5 songs ago, I should be able to do that by hitting back 5 times. Then if I let it keep playing it’ll go through the remaining songs in the same order they played, until it “catches up” to the point of unknown and has to randomly select which song to play next.
-
Guarantee that each song will only play once, unless repeat is also turned on. If repeat is also turned on, guarantee that each song plays once until all songs have been played, then make them all eligible to be played again until they’ve all been played another time, etc forever.
-
Use a good randomizer and seed it properly. Hopefully you already do, but if not and the order becomes easily predictable, people will be annoyed.
-
I don’t recommend trying to be varied vs random. i.e. if you try to make sure that you never have the same artist playing within 2 songs of each other or something like that, and the user hasn’t built a really varied playlist, you’ll end up spacing the artists out nicely at the beginning and then end up with nothing but one or two artists to play at the end, far more jarring than if the occasional back-to-back playback happened. This is definitely not a problem now but if the todo for you guys turns into “overhaul shuffle” I want to make sure this one doesn’t sneak into the spec.
-
Gracefully handle new songs being added to the queue mid-playback. Adding new songs to the queue should make them eligible for future random playback but should not reset the state of already played songs.
If Plex developers would like to hear more about the data structures we used to solve the somewhat complex state problems, I’d be happy to share what I remember from the initial implementation as well as get you in touch with the front end developer who maintained that functionality.
+1. Your current random implementation of using epoch can become repetitive and is generally frowned upon in the cryptography community. Here’s a few good article on various methods of generating good random numbers. Cryptographically secure generators are the way to go.
cs.yale.edu/homes/aspnes/pinewiki/C(2f)Randomization.html
en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Standards
@lucasz@hotmail.com said:
+1. Your current random implementation of using epoch can become repetitive and is generally frowned upon in the cryptography community. Here’s a few good article on various methods of generating good random numbers. Cryptographically secure generators are the way to go.
cs.yale.edu/homes/aspnes/pinewiki/C(2f)Randomization.html
en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Standards
Did you reverse engineer their binary to figure out they’re using the epoch? This instantly explains the reason why the episodes are so consistently the same. Most of the epoch hasn’t changed day to day.
Without doubt they’re already using a crypto library. Just a matter of using one of its ‘get_salt’ functions for some lovely truly random bytes, I suspect.
@deed02392 said:
@lucasz@hotmail.com said:
+1. Your current random implementation of using epoch can become repetitive and is generally frowned upon in the cryptography community. Here’s a few good article on various methods of generating good random numbers. Cryptographically secure generators are the way to go.
cs.yale.edu/homes/aspnes/pinewiki/C(2f)Randomization.html
en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Standards
Did you reverse engineer their binary to figure out they’re using the epoch? This instantly explains the reason why the episodes are so consistently the same. Most of the epoch hasn’t changed day to day.
Without doubt they’re already using a crypto library. Just a matter of using one of its ‘get_salt’ functions for some lovely truly random bytes, I suspect.
I read it in another forum post where an employee said it’s based on epoch. I could attach a debugger and step through, but I’m afraid of what I’ll find. It’s enough to know their PRNG is junk and needs to be done properly.
Old problems never answered: https://forums.plex.tv/discussion/213877/music-shuffle-criteria#latest
Again I agree on tne need of a better shuffle handling.
I use shuffle on a specific kid show to play episode randomly to my kids and keep noticing the same episodes playing on the Apple TV. Out of 60 episodes, about 10 get chosen to by played randomly, and always the same 10 episodes on each new shuffle, so I never get to see the rest of the episodes. This is not the case on the Roku, so I was wondering if the shuffling gets done client side.
