"Music Party Mode", Jukebox feature!

regarding the randomness, i don't think that calling srand(timegettime()); rand() is necessarily a reliable random sequence - the "random" number is tied to close to the current time. it gets even worse if you modulo it as the low bits of rand() are less variable than the high bits. this is used elsewhere in xbmc as well and is the reason for a number of other phenomena such as the slideshow random angles not being particularly random.

perhaps we could have a random number class that seeds once and then uses the one sequence (up until a set number of drawings, then re-seed it) so that we can get reasonable randomness? i think using srand() and rand() is fine as long as we do it sensibly.

also, we could have a history vector of song ids for database::getrandomsong() to eliminate the issues pike is seeing for say 100 songs or so.

party mode looking great though - i like it

cheers,
jonathan

i agree that the randomness isnt that good, but its the same randomness thats used elsewhere. but, lets put the randomness aside for now. there is a larger question to answer which can mask the problem.

today, the only check is that the user has atleast one song in the database which is why there's no duplicate stripping yet. i like jm's idea of keeping a history of the last 'x' songs but it still presents a question... what should be the minimum number of songs in the database to enable party mode?

once this question is answered, we can figure out what history size to use for duplicate detection to strip them out.

kragh3d, thanks for this great job. i am very happy with this.

but the way of adding songs to the list is not right for me. now the playing song stops and the added songs plays. this will interupt the party everytime adding a new song. my suggestion is to add a new song to the second place. the next to the third place and so on.

i have also a feature request: is it possible to enable partymode with boot? i like an option for this in settingsmenu.

thanks for all,

sollie.

sollie,
please read the entire thread. it works like that because that's all that was relatively easy to do at the moment. (relatively easy... it took me a week to shoehorn this feature into xbmc and have it work as good as it does for the first iteration.)

trust me, its not as simple as "add a new song to the second place, the next to the third place and so on" as you describe. not only is there a timing issue as the list dynamicly shifts, there's no way yet to determine what's a randomly added song, and whats a user added song. so, if you dont like it, then dont use select/play today. use queue which will not disturb the currently playing song, but the songs will go to the bottom of the queue.

but, this presents some questions for discussion... how should select/play and queue ultimately work during party mode?

should select/play put the selected items beneath the currently playing item as sollie suggests, or should it interupt the list as it does now? (i really think that select/play should work as it does today. if someone plays something, it means they want to hear it immediately.)

where should queue put the items? underneath the currently playing song, underneath the last user added item, or at the bottom like it does today?

** edit **
regarding a "start party mode on boot" option... i dont know. right now, i tend to say no as it can conflict with an autoexec.py script. though, at some point, an autoexec.py script may be a way to start it on boot.

Quote:use queue which will not disturb the currently playing song, but the songs will go to the bottom of the queue

i am sorry, this is good enough for me. i didnt know the "queue" function worked that way.

thanks, sollie

ps: its fine this way, now i use the "remove" (contextmenu) function to delete songs from the list.

if the controls are exposed to python it would be easy enough to use the autoexec.py to auto start party mode.

can i say great work, cause that's what this is...

thanks again as always.

kraqh3d,

i didnt look at athe code yet but it feels that its grabbing the files one by one from the db. perhaps it should calculate all the random file ids first and grab then all at once from the db, however, i am being very picky now, as it works well now, as the list is small.

*edit*

i also vote for putting the user selected sons bellow the currently playing one.

and i love the idea of keeping a file to prevent repeating of songs. i suggest the system keeps a list 75% of the currently queue list, maybe more. but if it's a 100% then towards the end it's predicatble what will be played. what do yo think?

small bug, party mode doesnt disable automatically when you stop playback. maybe this is intended, but if u eg. watch a video and then return to partymode without disable/re-enable it doesnt work

(jmarshall @ feb. 21 2006,01:01 Wrote:regarding the randomness, i don't think that calling srand(timegettime()); rand() is necessarily a reliable random sequence - the "random" number is tied to close to the current time.  it gets even worse if you modulo it as the low bits of rand() are less variable than the high bits.  this is used elsewhere in xbmc as well and is the reason for a number of other phenomena such as the slideshow random angles not being particularly random.

perhaps we could have a random number class that seeds once and then uses the one sequence (up until a set number of drawings, then re-seed it) so that we can get reasonable randomness?  i think using srand() and rand() is fine as long as we do it sensibly.

also, we could have a history vector of song ids for database::getrandomsong() to eliminate the issues pike is seeing for say 100 songs or so.

party mode looking great though - i like it

cheers,
jonathan

agreed, jonathan, but more importantly, even if you had a truely "random" distribution, without protecting against it, you could have a legit double hit of one song in a 10 of 38 selection...just making a point that pure random distributions won't prevent something selected once from showing up again until all possible values have been populated.  in this case, i think a check needs to be made not to add the random song to the queue unless there are 10 or fewer files to pick from (at which time you just fall into randomizing the order of the files that you do have) if it is already in the queue.

time for a random number populator to select all possible combinations without repeats increase exponentially, as you approach selecting 100% of the files for your list, unless coded for.  i've found that it is pretty fast if you have at least 125% of the population available for selection without too much extra case coding (i.e. maintaining a hash or array of files selected and only randomize the picking of the new reduced array is optimal if you have to approach 100% random selection).  so, if you didn't want to have your randomized function take too long, but also didn't want to have to maintain a "files left to add that have never been picked yet" for your selection, you would just mandate that there be at least 125-150% of the files in the library (that means >12 to 15 files in the library to compile a random unique list of 10).  sorry, that is probably more complicated of an explaination than it needed to be, but i'm a bit strung out right now with other issues.  :o

-jm

thx kraqh3d! :bowdown:

i think "play" should move the song on second place of the list, so that it´s played after the current song. "play" means play immediatly, but on a party it´s "interrupting" dancing people if the song is cut off.

"queue" should move the song to the end of the list.