• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 8
"Music Party Mode", Jukebox feature!
#16
if the controls are exposed to python it would be easy enough to use the autoexec.py to auto start party mode.
read the xbmc online-manual, faq and search the forums before posting! do not e-mail the xbmc-team asking for support!
read/follow the forum rules! note! team-xbmc never have and never will host or distribute ms-xdk binaries/executables!
Reply
#17
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?



Reply
#18
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
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#19
(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 Smile

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



Reply
#20
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.
Philips TV with Kodi 20.2 with IPTV --- Orbsmart 500 Android 21 alpha/beta as Online-radio/TV in the kitchen
Reply
#21
Quote: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?
i kind of agree with the last poster, but i kind of think that select/play should play the selected song immediately and queue should put it next, right after currently playing song. or for future consideration, once you have a flag to know which songs are random and which songs are user-picked, queue would add to the bottom of the user-picked list (which may be at any position).

the reason i say select/play should play immediately is because if one of the random songs it picks sucks (limp bizkit hahaha), you can just find the best song in the list below it and hit play to play right now instead of having to wait for the sucky song to finish.
Reply
#22
the reason for
Quote:error party mode: cannot get songs from database. aborting.
in my case is because songs are picked random from 1 to nr of song in the database. i did a "clean database" recently because i renamed some music so those songs were removed from the database and readded after a new scan. so some songs it won't find because the id's don't exist in the database anymore and some songs it will never pick because those id's are higher then the nr of songs in the database.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#23
i put it in my skin aswell.. and i must say that i like it very much, thanks for making such a cool feature ..keep up the good work :thumbsup:
Reply
#24
to avoid playing the same file twice there will be a need of keeping track of what has been played.

to determine the number of tracks that should be kept track off, i i guess there should be taken a declining percentage of songs.

e.g. if i have a db of 50 000 mp3s i don't really mind if every couple of hours a song could repeat. but if i only have 50 mp3s i want to listen to all of them before they repeat. i know that this would mean that the second repeat (after all 50 mp3s were played) wouldn't be very random, it would be more or less a repeat of the first run.



Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#25
history:

i think a graded function with a set percentage of say 80% or whatever before 100 songs, and 80 after that would be ok. we can always change it as we find a good balance. the first query when starting party mode would determine the history size.

queuing vs playing:

i think play/select should always act as it does now -
it should play immediately. queue should queue up underneath the currently playing item. in addition, the queue option should be renamed "play next in party shuffle" in the context menu, and a "add to party shuffle" item added.

the future:

another good idea would be to allow for the future where we may have conditions applied to the database query. for instance, a "prefer unplayed songs" or "prefer trance" similar could be kinda neat (obviously the gui side of it would need to be well thought through.) doing this is trickier as we need to:

1. assemble the query. we can generate a random number to decide whether the "preference" is satisfied for this particular drawing of a song or not (eg 80% of the time we include the prefer as a restriction on the query, 20% of the time we include the complement). we can remove the songid's we don't want (history) in the query.

2. do the query to grab the count.

3. draw a random number from [1..count] and choose the random row.

this is more time consuming (first query could produce a lot of entries - not sure how smart sql is if we just want the count whether it's quicker - it probably is) than the current system, but allows nice flexibility in the future.

there's also the problem that conditions on the query will mean that nothing gets returned so we need to be prepared for this.

cheers,
jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#26
@alterior:
Quote: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.
yes, for two reasons... 1) the process is metered to run on a fixed interval and 2) once its going, it really only needs to get one random song. but, yes you are right that when you first enable it, its not that efficient. it could just as many songs as necessary every iteration to keep the song at a depth of 10.

@pike:
Quote: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
yes, i skipped over the stop action because i wasnt sure what it should do. should it completely disable party mode? this is a minor bug that can be corrected when we decided what stop should do. if you play a movie while party mode is playing, it should work correctly. and disabling and re-enabling party mode from the library window should get it going again. (i'm assuming in this particular condition the button still shows it active, right?)

@reddington:
Quote:the reason i say select/play should play immediately is because if one of the random songs it picks sucks (limp bizkit hahaha), you can just find the best song in the list below it and hit play to play right now instead of having to wait for the sucky song to finish.
this is one of the reasons why i think play should interrupt.

@charly:
Quote: in my case is because songs are picked random from 1 to nr of song in the database. i did a "clean database" recently because i renamed some music so those songs were removed from the database and readded after a new scan. so some songs it won't find because the id's don't exist in the database anymore and some songs it will never pick because those id's are higher then the nr of songs in the database.
thanks for pointing this out. this is something i didnt consider. in your case, the number of songs doesnt match the existing id's. hmm. i have to think about how to compensate for this. maybe if the picked id doesnt exist, keep incrementing by 1 until a valid id is found?

@jmarshall:
Quote:i think a graded function with a set percentage of say 80% or whatever before 100 songs, and 80 after that would be ok. we can always change it as we find a good balance. the first query when starting party mode would determine the history size.
sorry, i dont follow. the first query being what?

Quote:i think play/select should always act as it does now -
it should play immediately. queue should queue up underneath the currently playing item. in addition, the queue option should be renamed "play next in party shuffle" in the context menu, and a "add to party shuffle" item added.
i agree with this logic. so the "add" item would function like queue does today and adds the item at the bottom of the queue?

and i forsee a problem with your future ideas. during the initial startup, the amount of returned rows can be huge, potentially the entire song table. today, this presents a problem for the "songs" node off the root of library. this, in particular, is why i coded it the way i did. it didnt want to get a large returned list and then pick from it. but, as charly has already identified, theres a flaw in this logic because it assumes that the song ids are consecutive.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#27
Quote:yes, i skipped over the stop action because i wasnt sure what it should do. should it completely disable party mode? this is a minor bug that can be corrected when we decided what stop should do. if you play a movie while party mode is playing, it should work correctly. and disabling and re-enabling party mode from the library window should get it going again. (i'm assuming in this particular condition the button still shows it active, right?)
yes you are corrent in describing its behavior. i believe party mode should simply be disabled and playlist cleared. this is consistant with general xbmc usage

Quote:this is one of the reasons why i think play should interrupt.
very much agreed. queue action is there for a reason

Quote:this, in particular, is why i coded it the way i did. it didnt want to get a large returned list and then pick from it. but, as charly has already identified, theres a flaw in this logic because it assumes that the song ids are consecutive.
why not select all ids insted of the full songview. after id's have been selected then go and fetch the needed information (path, title, etc) from the db. though it sounds like you may have already coded something completely different, i dont want to poo poo your method.

regarding queue action. some are describing it as 'add enqueued song after current playing' which would result in something likes this

Quote:[current playing] song 12345
--another enqueued song would be added here--
[enqueued] third enqueued
[enqueued] second enqueued
[enqueued] first enqueued
[random] song1
[random] song2
[random] song3

where as i feel enqueued song should follow currently playing and after all user enqueued songs as shown here

Quote:[current playing] song 12345
[enqueued] first enqueued
[enqueued] second enqueued
[enqueued] third enqueued
--another enqued song would be added here--
[random] song1
[random] song2
[random] song3

but thats for another day

tanks
loto
Reply
#28
queued stuff:

2 actions:

1. "add song to party mode" - behaves exactly as "queue" does now - adding to the end of the list.

2. "play song next" - adds to the playlist as the next item to be played.

i think 1. should be the default "queue" action (ie as it is now), and context menu for "play song next", but that's an opinion without having tested it, so it might change Wink

as for how to handle the "future stuff" etc:

1. when party mode is started, the history is initialized to empty, and we ask for the count of the number of songs from whatever source we are using - this shouldn't be an issue memory-wise as it is literally a count we are asking for - no need to retrieve each row. based on the number it returns we can setup the length of history to keep.

2. we then generate our random number r between 1 and count - history.size() and grab the r-th row from the query. we can use the offset and limit commands to just get the one. this song (it's songid) is added to the history and used in the subsequent queries to rule out particular songs.

would that work?

jonathan (sql noob)



Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#29
wishlist : a pary mode for us music video lovers .........
Reply
#30
Quote:maybe if the picked id doesnt exist, keep incrementing by 1 until a valid id is found?
a few options:
-read all id's from the database
or
-do a "select max(idsong)" and loop in getrandomsong if a random id isn't in the database
or
-do a "select max(idsong)" and return a statuscode (tryagain) from getrandomsong and let checkmusicplaylist try again @ next call.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 8

Logout Mark Read Team Forum Stats Members Help
"Music Party Mode", Jukebox feature!0