Posts: 5,008
Joined: Sep 2003
Reputation:
30
pike
Team Kodi Admin
Posts: 5,008
yes, the delay im talking about is purely ui. it would feel "nicer" if it was a bit snappier is all im saying. no biggie, guess it can be optimized at some time
regarding "unlistened tunes".
i guess what i'm wondering is:
say you have 1000 tunes in your library
you've listened to 500 -unique- ones, and are currently playing #501
now, are there 999 left to listen to (while current tune is playing) or are there 499 -unique- ones left in "playlist" ?
if 499, would be nice to show this number somewhere.
Posts: 7,172
Joined: Dec 2003
Reputation:
4
kraqh3d
Retired Developer
Posts: 7,172
ah. that's not possible at the moment. the only history kept is a rolling list of the last 25 songs to prevent duplicates within that window. i've been considering using a database table as the history in order to reduce memory.
i dont know how feasible this is, but i was thinking about using a table thats dropped and created everytime party mode is enabled in order to explicitly clear it. then as songs are picked, their id's would be pushed into this table. getting the total number of unique songs from this table would be trivial. then picking songs without repeats can be accomplished using a nested query, something like this:
select * from songview where songview.idsong not in (select partymode.idsong from partymode order by partymode.rowid desc limit 25)
Posts: 5,008
Joined: Sep 2003
Reputation:
30
pike
Team Kodi Admin
Posts: 5,008
i've noted that sometimes the currently playing tune in playlist view is using selectedcolor, then again sometimes it's not :nuts:
edit: found out that whenever you bring up contextmenu theh selectedcolor becomes active
another issue. i was in partymode. changed to fileview, choose 'queue item' on contextmenu. it disabled partymode and queued all 1200 tunes...
Posts: 1,473
Joined: Aug 2004
Reputation:
3
C-Quel
Retired Team-Kodi Member
Posts: 1,473
well spotted pike ill try this myself see if i can produce the same bug.
Posts: 5,008
Joined: Sep 2003
Reputation:
30
pike
Team Kodi Admin
Posts: 5,008
it would be damn nice if partymode could get its own window that replaces the "playlist window" while partymode is active.
all buttons to left are useless in partymode anyway :p
Posts: 1,473
Joined: Aug 2004
Reputation:
3
C-Quel
Retired Team-Kodi Member
Posts: 1,473
sorry mate try as i might with yesterday and todays cvs i cannot replicate bug of many queued items... you have all your music in 1 folder?
Posts: 5,008
Joined: Sep 2003
Reputation:
30
pike
Team Kodi Admin
Posts: 5,008
yes im only playing with 1 folder with 1200 items or so
Posts: 7,172
Joined: Dec 2003
Reputation:
4
kraqh3d
Retired Developer
Posts: 7,172
yes, while the buttons in the now playing window are useless while partymode is active, i still see no for partymode to have its own window. its nothing more than a dynamicly running playlist, and the now playing window provides all the necessary functionality to deal with a playlist.
actually, i just thought of something. i should set the buttons as disabled so they are unselectable. not sure why i didnt think of that before as i logically disabled the buttons functionality.
i'd check into that possible bug, but i'm in the midst of a modication so that i can use a database table to hold the entire history. and unfortunately, i've totally broken partymode in my local cvs. once i get it up and running again, i'll try to replicate this issue.
re: the highlighting... just so that i understand the circumstances... under normal conditions, the current playing song is highlighted, correct? it's not until the context menu is brought up and close that the highlighting disappears? (if so, this is because the new manager is action based and not timer based. this probably happened in the past but since the manager ran on a short timer, it would just fix itself almost immediately.)
Posts: 484
Joined: Sep 2004
Reputation:
0
i disagree, i think thoes ideas could be implimented in the mymusicnav window. perhaps when a user selects 'party mode' it reveals a context menu with your ideas insted (insted of genre/custom location use a 'party mode current directory')
i think the library window is exactly where partymode should display. perhaps the library window could be implimented differently, but thats another discussion.
Posts: 7,172
Joined: Dec 2003
Reputation:
4
kraqh3d
Retired Developer
Posts: 7,172
everything on your ideas list can be incorporated into the library, now playing, and visualisation windows. i see no driver for a new window. all we need is a new visbility condition of "musicplayer.partymode".
i've always thought that the options to restrict where party mode gets is songs from should be somehow added into the library window. i'm not sure how yet though. this is the hard part. for the first iteration, i was thinking about a simple genre restrictions using the context menu "restrict partymode to this genre". you can pick more than one. then you start party mode. and once partymode is disabled, the restrictions are lost.
i like the freshen idea. that's easy accomodated in the now playing window context menu.
hmmm. i kind of like the idea of allowing a "mostly" or "relax restrictions" option which would keep the song choices to the restriction 90% of the time or something around there. that, however, makes it more complex to compute the number of unique songs left to play. there's the number of unique songs which meet the criteria, and there's the total number of unique songs. the history would need to be able to distinguish between the two types.
while i'm on the topic of song restrictions, if we want the ability to keep track of the number of unique songs left in the database, then the restictions absolutely must be be defined before party mode starts. they cannot be changed dynamicly. or they can be changed dynamically, but party mode is "reset" at that time which means you may get some repeats right afterwards.
speaking of history, this needs to be tweaked. i was about to change the history so that its a function of the number of songs. this is what i was considering: if the db has atleast 50 songs, the history size is 1/2 the number of songs, up to some maximum value, 100, even as high as 500. if there's less than 50 songs, there is no history at all. today, with less than 50 songs, partymode cant be enabled. (that reminds me, all errors are logged, but there's no popup indicator. i need to get that into the system now.)
** edit **
jmarshall may have some idea on how to make the now playing window "dual purpose". there's already a few windows which are multi-id'ed. this could potentially work for party mode to allow the now playing window to be sufficiently altered and reskinned when party mode is active.
Posts: 7,172
Joined: Dec 2003
Reputation:
4
kraqh3d
Retired Developer
Posts: 7,172
i just committed some changes to party mode. the song history is kept in a database table now. the table is explicitly cleared whenever party mode is started.
there are two things on my todo list:
- "freshen"... i really like this idea but i have some questions... first, what should the context menu option be called? "freshen" doesn't cut it for me. "refresh songs"? something else? where should it place songs? should it always put its songs beneath the currently playing song, or should they go beneath the last user added song if there are any? and how many songs should it add? 10?
- very simple genre based filtering... i want to add a simple filter schema using a context menu option in the genre listing that the user can use to restrict party mode to particular genres. it'll be a single context menu option where the text changes. if the currently selected genre is not part of the filter, you'll see "enable in party mode". if the selected genre is already enabled, you'll see "disable in party mode".
so the user knows what was allowed and whats not, i was thinking that the allowed genres would be visually marked with the highlight color. but, here's the question... by default, all genres will be enabled. do you think that having the entire list displayed in the highlighted color would be too distracting? if so, i need to rethink how to mark the genres. simply adding an * after the genre name may be an alternative but i need to ensure that there's no code that does a string compare against the genre name.
and pike, i dont see any issues with the highlighting. the currently playing song is always highlighted. when you bring up the context menu, the selected item gets highlighted just to denote that its the item your context menu option will affect. as soon as the context menu is gone, the highlighting goes away.
Posts: 34
Joined: Jan 2005
Reputation:
0
couldn't see this suggested in my read through of the thread, so thought i would throw this in.
would be nice if you could have different label display formats in xbmc, one for when you are viewing by album (where track number etc make sense) and another for when you are in party mode, or browsing by artist etc (where the track number makes little sense)
