On the now playing screen, down arrow appears to be a rewind function.  Up arrow appears to be ffwd.  I'm not sure what right arrow thinks it's doing, but it doesn't work.

Vic, do I recall correctly that rewind and ffwd should be disabled for Pandora?  If so, I will just get these commands disabled during Pandora use.

Thanks for any info!

For Pandora: rewind and ffwd should not be available. By ffwd I assume you don't mean "skip" which should be available. "skip backward" should NOT be available.

QA to retest this after Ben's recent changes

I will file new bug for skip not working when using remote.

On r8470 firmware, here's what happens:

Right arrow: Audio skip or cut-out
Down arrow: Audio skip or cut-out
Up arrow: Audio skip or cut-out
Left arrow: Goes back to previous screen

REW button: Nothing
FWD button: Audio skip or cut-out

Here's what happens on Radio and should happen on Touch:

Right arrow: On Radio, brings up Pandora context menu (I like this song, etc.). Think this should happen on Touch too.
Down arrow: Nothing
Up arrow: Nothing
Left arrow: Goes back to previous screen. Also brings down Pandora context menu.

REW button: Nothing
FWD button: Skip to next track

No need to file new bug -- have re-titled and changed this one.

Bug 15573 is very closely tied to this. It's likely to be one fix for both bugs.

For clarity, this is not a Touch only issue and comment #5 is incorrect in saying that it works in Radio. This can be reproduced in Radio as easily as Touch, but on neither platform is it a 100% reproducible issue.

Steps to reproduce:
1. Play a Pandora station
2. Verify that + button or right arrow will bring up context menu
3. Navigate back and select another Pandora station
4. Verify that + button or right arrow does not bring up CM and causes audio to skip

mapping of actions in NP applet appears broken under certain conditions.

100% of the window listeners are lost under certain conditions, including in the previous comment.

There is nothing in the code to remove those window listeners, so there must be an underlying lower level bug causing the linkage of the listeners to the window to be lost.

Still investigating...

Further info, it's the use of this code that causes the listeners to be lost:

    if not self.snapshot then
                self.snapshot = SnapshotWindow()
        else
                self.snapshot:refresh()
        end
        --temporarily swap in snapshot window of previous track window to allow for fade transition in to new track
        self.snapshot:replace(self.window)
        self.window:replace(self.snapshot, _nowPlayingTrackTransition)

Ignore comment #9, I've reproduced the issue with that code block commented out.

I've determined the self.window listeners table in NowPlayingApplet is not lost by the applet, even after this behavior is seen. Still unknown why the actions in the window listeners are not being obeyed.

another data point-

I turned my attention to _updateButtons() and disabled it as a debug to see whether any of the calls in that method are the cause of the issue. This includes things like remapping button styles and callbacks, replacing window widgets with other widgets, etc.

The problem is fully reproducible when the _updateButtons is disabled.

 == Auto-comment from SVN commit #8518 to the  repo by bklaas ==
 == https://svn.slimdevices.com/?view=revision&revision=8518 ==

Fixed Bug: 15339
Fixed Bug: 15573
Description: fully replace NP window on track change. This is a workaround to the fact that window listeners are being lost in particular situations (e.g., a new pandora station being selected and updating an already drawn NP window).
add log debug messages in notifications
don't take action on notifications not intended for the current player
restyle the rbutton widget rather than replace the whole title group widget set

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!