I also see that the Zapped Songs functionality still works with an ir remote but not with Controller.

This might actually be a SqueezePlay issue not just a Controller issue.

It appears that holding the add key while in the playlist is delivering add-status instead of add-status-hold which is why it doesn't zap.  Hacking SlimBrowserApplet to call zap on add-status makes it work, so zap itself is alive and well.

A press of add key brings up the drill down menu for the current item in the playlist.

Presumable this is a fumble which will get fixed?

It's hard to report problems without knowing what the key assignment design is, by the way.

Ben/Tom: your thoughts?

Need to meet with Ben/Tom and get a clearer understanding of zapped menus...

The zap function remove the selected entry from the now playing playlist and puts it into the zapped playlist, creating the zapped playlist if necessary.

I use this to drive an outboard process that either deletes the track or moves it to a different folder.  I don't know how others use it, but I'm not the only one who misses it.

See my comment above - there is no problem with the function - it's still in and works.  The problem is with key assignments.

This had been hanging around too long, considering that until the key assignments get sorted out, it can be hacked by just moving the zap function under add-status (instead of add-status-hold) in SlimBrowserApplet.lua.

Moving Matt Weldon bugs

What would you think about putting it into the context menu? Not as easily accessible, bit it could probably easily be put back this way, as the underlying command is still around ("playlist zap [index]")

I assume the "context menu" is the one you get by pressing + on the controller.

I think there are two downsides.  For the apparent minority of users it's slightly less convenient.  More important I think, it may confuse the majority of users who don't know what it means, and will make the already long context menu longer.

That's why I thought that adding it to the list of actions in the customize key mechanism would be better.

But as a heavy user of the function, I'll be happy with what I can get :-)

Context menu makes the most sense to me, although it is starting to become a dumping ground for everything that can't be put anywhere else. It's getting to the point where I feel like I need a way to organize the context menu. 

Now that the Playlist Manager plugin is updated I can add to the zapped playlist from there, but something is still needed for people who don't use that plugin.

"it is starting to become a dumping ground for everything that can't be put anywhere else. It's getting to the point where I feel like I need a way to organize the context menu."

that's very true, but in a way that's the whole point of the context menu, to relieve the unwieldy over-subscription of the physical buttons for a feature-rich product. I was one of the two big proponents of the CM, but not because it's a more elegant UI than assigning button events for actions (because it's not), but because it scales well.

I'm no longer with Logitech and what small power I had for product definition is now completely gone, however I can almost assuredly guarantee that Logitech's product marketing focus for any future UI will be: simplify, simplify, simplify. So while I understand that there are some users that are fans of the zapped feature, realistically I'd expect very little traction at getting this on any part of the UI other than the CM.

executive summary: let it go into the CM, because that's the only place it's ever going to go :)

Unassigned bugs cannot have a priority.