This is already implemented, but it's not a great solution. Consider an empeg all of which you've heard about 100 times -- then synchronise a new song on. You'll hear that song 100 times before it bothers playing any of the others.

Perhaps I wasn't making myself clear. You're assuming that I was talking about a "number of times this song has been played" counter, which would indeed produce the undesired result you just cited. But that's not what I meant.

I meant a "what sequence have the songs been played in" counter. This would be a single, unique, static value that was global to the entire unit. Sort of like the odometer on your car. Each time a song was played, this "odometer" value would be incremented. Each song would get that odometer value recorded with it as soon as it was played. Every song on the unit would have a unique odometer value (once it had been played at least once). As soon as a song was played, all the other songs with lower odometer values would suddenly take a higher weight for the next shuffle. A newly-synched song would indeed come up first in the shuffle, but it would only play once before it was weighted to the back of the shuffle again.

Thinking in more detail about the implementation, you would probably have to seed the value of all new songs with the highest possible number. Either that or seed them with 0 and have the counter count down towards 0. Either way.

___________
Tony Fabris