i added initial support for music party mode. it requires a music database. enable it from the "party mode" button found in the library window.

it's integrated into the music now playing window. when party mode is enabled, the shuffle, random, and repeat buttons in the now playing window are disabled.

when enabled, xbmc will ensure the now playing window has at least 10 songs in the playlist at all times, by randomly picking songs out of the database. the currently playing song is always at the top of the list. when its finished, its removed from the list, a new song is added, and the top song plays.

from within the now playing window, you can select another song thats already in the queue. this song will start playing and get moved to the top of the list. the previously playing song will be removed.

from the files and library window, you can select/play a song and it will become the currnetly playing song. (autoplay next item is effectively disabled while party mode is enabled.)
play on a folder or playlist is currently ignored during party mode. queue, however, works as normal. the items are added to the end of the playlist.

if something switches or clears the playlist, party mode is disabled. examples: you start a movie, you initiate playback from the web interface, from an http api command, from the internal command, or from python.

there are going to be bugs! there's alot of interaction with other parts of xbmc which i likely missed. start posting the bugs here. please do not post feature requests yet. the system needs to be stabalised first.

comoer : mymusicsongs is the file view. as stated party mode uses the database hense only in mymusicnav.

ahhh very nice work kraq.

ive had a couple hard lockups when i first tried it. i have a log of only the 2nd one. i 'selected' a song from the library with party mode on. i then entered the playlist window and watch the song roll over to the next... until it locked hard just as was changing.
the files involved playback fine when tried again. it only happened twise and hasnt occured since.

@coemr
it could open up the now playing window when first enabled. thats easy. i'll throw that in. the reason i didnt put the button in files view is because its library view dependant.

and what you mean by "@ bugs.. disable party mode..."? you can certainly disable it, but you need to do it from the button library view. i'll add a context menu option of "cancel party mode" to the now playing window context menu. that's simple enough.

@loto
you've experienced this lock up twice out of how many times? it looks like something could be wrong with the stink finger file, but you said it plays fine. its as if the file got to the top of the playlist, and it kept trying to repeatedly play it but couldnt. in this case, you should get a message that the item is unplayable.

an unplayable song should be reaped from the list after it errors and party mode moves onto the next song. i've noticed some quirks with the paplayer related to how it loads the next song outside of the playlist player and then just tells the playlist player to move ahead. it could be related.

please double check that this file plays ok outside of party mode. queue up some files, and put this one in the middle.

and definately explain these interface quirks you've found. i'm interested in those to.

** edit **
i just threw in those two suggestions. now, when party mode is enabled, xbmc switches to the now playing window, and you can watch it get populated. there's also a "cancel party mode" option in the context menu so you can turn it off without going back to the library window. i also added some code to disable the "move" options in the now playing context menu when appropiate since party mode moves stuff on its own.

kraq, i'm absolutly positive the file plays properly when added to a queue. it has worked 20+ times since.

regarding little quirks, they were feature requests is why i omitted them.
could 'enqueue' add items in front of the randomly populated items? i think this is more usable because users would want to listen too their selectedf songs before all the random songs.
the ability to specify the 'source' of the randomly selected songs is needed as well. otherwise songs like limp bizkit - stink finger come up being able to use playlists, genres, or specific artists as sources would be neat. perhaps a context menu item 'party this directory'

Quote:could 'enqueue' add items in front of the randomly populated items? i think this is more usable because users would want to listen too their selectedf songs before all the random songs.

eventually. right now there is no way to easily push more than one song to the top of the list, nor is there a way to distinguish between user added songs and randomly added songs. so for now, queue puts items at the bottom as it does normally, play on a folder/playlist is completely ignored, and select or play on a file makes that file the current song.

Quote:the ability to specify the 'source' of the randomly selected songs is needed as well. otherwise songs like limp bizkit - stink finger come up. being able to use playlists, genres, or specific artists as sources would be neat. perhaps a context menu item 'party this directory'

unfortunately, this requires a database update. all songs will be available by default with a context menu option to both enable or disable a file/folder. and i dont see playlists ever being used as random sources as they are still outside of the database.

@charly: when did you last sync with cvs? there was a bug that existed in cvs for a short while yesterday which could cause this.

that error is supposed to only be generated when getrandomsong fails. since i dont see the accompanying getrandomsong failed error message, it looks like you may have synced when the bug existed.

and the reason why no more songs are added, and no songs are removed is because it aborted. if party mode encounters any errors, it disables itself to prevent it from getting stuck in a spiraling loop of errors.

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.

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.

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.

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.