instead of having the 2 options that jmarshall suggested, i honestly think that the queueing only needs to be one action. do we really need to have a distinction (and separate context items) for adding to the middle of the list vs. adding to the end of the list?

i don't think so... i think party mode suggests that multiple people will be queuing up songs - which means that they want to hear those songs - so why would you even want to muck it up with an 'add to end' function?

like in the code box above, songs as they are queued should form their own ordered list with the first queued on top (next to be played) with random songs filling out the list. this of course also relies on the ability to flag queued songs vs. random songs.

select/play (from either the library or the party mode list) will drop the currently playing song and begin playing the selected song as number one. the rest of the list remains the same....

re: stop:
i'll add the code to make stop disable party on the weekend. if any dev wants to do it sooner, please feel free.

re: queuing:
i agree with this strategy as well. i dont see any need for two types insertion.

to do this requires two changes to the playlist class... 1) ability to identify randomly added and user added songs, and 2) a way to insert items into the middle of the playlist.

right now, the play function is using a hack -- it's using the "move item" function found in the now playing context menu. when you play a song, the position is noted, and its moved into position 0. this definately needs to be changed so that the songs are just inserted directly at the correct position in the list.

kraqh3d: yep, that's what i was suggesting (count then grab single random row using limit + offset) earlier - works for restrictions on the searches as well at a later date.

regarding the marking of random vs queued items, one possible idea could be to have a party mode playlist and use the normal playlist for the queued items - the list we show in now playing is the normal playlist with the random playlist tacked on the end - saves special case stuff in the actual playlist player, and makes it trivial to queue. only difficulty is you can't move songs around as easily (is this even easy anyway - what would happen if you queued up 4 songs then moved one of the random songs up to the top - would you mark that as queued rather than random?)

just my 2c: if you're looking for a good randomness source, you might want to consider... xnetrandom. it returns raw bytes but that's easily castable into a integer.

from the xdk docs: "xnetrandom uses an algorithm for generating random bits based on rfc 1750 (randomness recommendations for security; see http://www.faqs.org/rfcs/rfc1750.html). randomness is not based on predictable pseudo-random mathematical number generators. instead, randomness is generated using a combination of random input sources, including physical sources of entropy such as hard disk seek time."
additionally, does it make sense to simply check that the song about to be added isn't already in the previous x playlist entries (if the library has more than x entries)?

last night i started a complete rewrite of the function in order to make it easier to extend its functionality. the rewrite will make party mode respond to actions as opposed to being exclusively timer based. some changes and additions will include:

- when songs need to be added, it'll add as many songs as necessary to make the queue 10 songs deep at once (as opposed to adding them one per timer iteration like it does today.)

- a simple history feature to prevent duplicates over the last 25 songs (aka, 2.5 random queue iterations). to allow this, i've decided you need to have more than 50 songs in the database to enable party mode, otherwise it'll abort.

- user queued songs will go underneath the last user queued song (or under the currently playing song if there are none.)

sounds like it. playing anything else is *supposed* to automatically disable party mode. i cant really debug the issue as my local sources are now entirely different from whats in cvs. for now, just dont do that anymore