[pike]

scenario:

you got some music files you sort a-z
you start playing the very first tune
you reverse the sorting order to z-a
(for simplicity's sake) enter fs music and goto next track
you return to my music filelist

observe now how the virtual playlist hasnt recogniced the reversion and the wrong file is shown as currently playing

[pike]

and... :bump:

[kraqh3d]

i'm working on it...

** edit ** fixed in cvs

[pike]

thx, i'll give it a try

[pike]

ok this solves:

observe now how the virtual playlist hasnt recogniced the reversion and the wrong file is shown as currently playing

but there's more issues

* the virtual playlist is unaware of the change (should it be ?) it happily continues to play in the "old" direction
* after you reversed the filelist and go right with cursor, it doesnt land on the previosuly selected file
* the sorting routines arent the same for playlist and filelist (timewise) 2 files can have same timestamp (down to the same minute) but they are not in the same order (playlist/filelist)

[kraqh3d]

* the virtual playlist is unaware of the change (should it be ?) it happily continues to play in the "old" direction

its not supposed to. the "autoplay next item" option merely creates an adhoc playlist based on the filelist at the time you started playback. if you change the sorting of the directory, it doesnt know, nor did it ever.

* after you reversed the filelist and go right with cursor, it doesnt land on the previosuly selected file

not sure what you're talking about here. it seems to work fine for me. when i go back to the left column and reverse the sort, then return to the filelist, the correct item is selected.

* the sorting routines arent the same for playlist and filelist (timewise) 2 files can have same timestamp (down to the same minute) but they are not in the same order (playlist/filelist)

ok. but thats always been the case then. ** edit** i just checked. if i sort by time, then queue a folder, the now playing window is in the same order, and i have items with the same extact timestamp.

[Bobbin007]

* the virtual playlist is unaware of the change (should it be ?) it happily continues to play in the "old" direction

its not supposed to. the "autoplay next item" option merely creates an adhoc playlist based on the filelist at the time you started playback. if you change the sorting of the directory, it doesnt know, nor did it ever.

the adhoc playlist is rebuild when the "sort by" button is pressed but not on the "sort asc" button. the adhoc playlist should be rebuild in both cases.

[pike]

its not supposed to. the "autoplay next item" option merely creates an adhoc playlist based on the filelist at the time you started playback. if you change the sorting of the directory, it doesnt know, nor did it ever.

i get your point, but for me autoplay next item is just that, next item relative to currently playing file. maybe a new "virtual playlist" should be created when you change sortingorder ?

not sure what you're talking about here. it seems to work fine for me. when i go back to the left column and reverse the sort, then return to the filelist, the correct item is selected.

i just doublechecked. if cursor previously was in position 2 from top, it still is in position 2 from top after i change sorting order. (but now on a completely different file)

ok. but thats always been the case then. ** edit** i just checked. if i sort by time, then queue a folder, the now playing window is in the same order, and i have items with the same exact timestamp.

first im talking sort by date in filelist, i assume you mean the same and arent talking about a library view.
and say i have 4 files with the same timestamp in filelist. hh:mm
the previously created filelist (in reversed sortingorder) plays file from down to up, but when it reaches files with same hh:mm (i have not checked the exact timestamp) cursor goes up, then down, then up again, ie not sequential anymore.
this tells me that the way the 2 lists are sorted arent identical.

[Bobbin007]

kraqh3d: the checkin you made about the currently playing item. it doesn't catch the case when you would add two identical files to the same playlist (eg. to the playlist window). imo we must use the item index of the playlist.

[pike]

it also seems like the "now playing" highlight is b0rking out. it shows more than one file as highlighted if i manually start other files in same folder. going to home and back to filelist fixes the issue temporarily

[kraqh3d]

bobbin,
but the index isnt good enough. the previous version used the index and when resorting the filelist, the wrong item would be highlighted when the song changed. using the path corrects that, except in the condition where there are two identical files as you've mentioned. now, its better. before it would select the wrong song more often. obviously, this needs further work. any ideas?

** edit **
wait a sec. there cant be two songs with the same exact path in the filelisting. the fix affects the code which selects the currently playing song in files view, not in the npw playing view. in the now playing window, the selection has be done based on the index.

pike,
oops. i can fix the issue where more than one file is selected when you click a new song. the entire list needs to be unselected before selecting the playing song. switching windows forces this to happen and so it cleans up the display. ** edit: fixed in cvs.

and i can confirm the highlighted song doesnt update correctly in music when changing the ascending descending sort. ** edit: fixed in cvs.

[Bobbin007]

bobbin,
but the index isnt good enough. the previous version used the index and when resorting the filelist, the wrong item would be highlighted when the song changed. using the path corrects that, except in the condition where there are two identical files as you've mentioned. now, its better. before it would select the wrong song more often. obviously, this needs further work. any ideas?

one idea: if the adhoc playlist is recreated when clicking "sort arc" button, (just like the "sort by" button handler) the index will be the right one. as the playlist should be in sync with the fileitems, so it should be save to use the index again.

[jmarshall]

the path check doesn't work for .cue sheets. perhaps path + title (or path + track) would suffice?

also, use of the string version of guiviewcontrol:etselecteditem() might help clean up the code a bit and centralise the code for this (and enhance this for the condition above?)

cheers,
jonathan

[kraqh3d]

bobbin,
where is the code that re-orders the adhoc playlist when the user changes the sort criteria?

one idea: if the adhoc playlist is recreated when clicking "sort arc" button, (just like the "sort by" button handler) the index will be the right one. as the playlist should be in sync with the fileitems, so it should be save to use the index again.

this would only work for playlists using "autoplay next item", and not true queue'd playlists. whatever's done needs to accomodate playlists in general. the current implementation seems to work reasonably well now, with the exception of cue sheets as jm pointed out.

jmarshall,

the path check doesn't work for .cue sheets. perhaps path + title (or path + track) would suffice?

thanks. i hadnt thought about cue sheet items. a combination of path + title would work. this requires tag reading be enabled or for the path to have been previously scanned. assuming cue sheets require the same conditions, it's ok. what about offset? cue sheets use an offset value to mark where the track begins. non cue sheet items just use offset of zero. would this be sufficient and not require tag reading or scanning?

also, use of the string version of guiviewcontrol:etselecteditem() might help clean up the code a bit and centralise the code for this (and enhance this for the condition above?)

that's a good idea. it cleans up the code.

[Bobbin007]

where is the code that re-orders the adhoc playlist when the user changes the sort criteria?

you'll find the code that reorders the adhoc playlist in cguimediawindow::onmessage() at the control_btnsortby control handler.

this would only work for playlists using "autoplay next item", and not true queue'd playlists. whatever's done needs to accomodate playlists in general. the current implementation seems to work reasonably well now, with the exception of cue sheets as jm pointed out.

the playlist used in a window is read from the guiviewstate. imho these routines will work for both cases, adhoc and true playlists.