right, I know what the problem is, tho not sure yet how to fix.  The position IS
saved, but only on exit.  therefore,when you jump out via now playing or search
then it does not get saved (in fact, it will be the last value that was when
popping or pushing from the previous browse)

Created attachment 476 [details]
track selection by forcing an exithandler call on passback

here is one way to do this.  the exithandler needs to be run in order to keep
track of the selected item.  This patch reworks the ir map to a passback for
now_playing and search.  the handler is called from the passback, which the
handler can track properly.  Playlist.pm contains a commented line that is
responsible for breaking bug1370 so that the proper working of this patch can
be shown.  otherwise, left from now playing will return to now playing when the
home menu option doesn't actually contain now-playing.

Kevin:  we're trying to uynderstand your patch.  Why the change to playlist.pm?

Also, reading this makes me wonder if there's incorrect behavior when pressing STOP or PAUSE. Is this 
the case?

oh! er, that Playlist.pm section was part of something else, long since dealt
with now. My personal instinct on this was that the passback is the wrong thing
to do as a function on the whole.  Patching like this worked, but I was hoping
it would open a discussion, as it has.  

I was thinking getting rid of passback, and using exit for all woud then allow
the parent module to have more control.  I guess that is part of why Dave had to
create the INPUT.Choice mode (which creates events for each of the functions
that would normally be a passback) 

I agree, passback is a bad idea.  I like the idea of an exit handler.  
How big of a change is this in the context of 6.1?

first off, all existing uses of INPUT.List that rely on the passback need to
have that implemented in the exitFunction.  Then it should be possible to
interfere with those passbacks in order to capture the valueRef before
abandonning INPUT.List state.

Is that the sound of a volunteer?  :)

it could be.  I'm not sure how big a task it is, but if you have the time, I'll
take it on.

Fixed in change 3418

Note that passback is intended to give the parent mode more control, not less. 
Using passback plus a map for your parent mode lets you have functions in your
parent mode which are called just like if you hadn't used the INPUT.List mode. 
Without passback, you have to cover every possible scenario in your exit
function, which makes for one really big if ... elsif ...elsif ... else block.

The problem here was due to onChange not being used to keep external
dependencies up to date with the current state of INPUT.List, it had nothing to
do with passback.

This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!