Bugzilla – Bug 17100
Unable to play track from Playlist Panel Context Menu
Last modified: 2011-04-13 02:42:29 UTC
Eastman_r8317 Droid 2 Galaxy Tab Motorola Xoom HTC Inspire When playing an album or playlist, inside the playlist panel use press/hold to bring up the Context Menu on any track then select Play from the menu. In Eastman the track appears to begin playing but on the player, though it shows the track, the progress bar is not moving and the track is not playing. No music is heard. I have been able to duplicate this across several phones and players all with the same result. Though most people will simply select the track itself to start playing and not bother with the CM, since this function is available it should work.
Here's the error I get in SBS: [11-03-29 07:27:59.5228] Slim::Web::JSONRPC::requestMethod (376) Request failed with error: Bad dispatch! [11-03-29 07:27:59.5281] Slim::Control::Request::execute (1935) Error: While trying to run function coderef [Slim::Control::Commands::playlistJumpCommand]: [Can't use string ("useContextMenu:1") as a HASH ref while "strict refs" in use at /Users/mh/Documents/workspace/7.5/server/Slim/Player/Song.pm line 386. ]
Ben - it seems the playlist command handler can't handle the additional useCM parameter. What's the rule for adding it? There's a comment in the code which says: // we always push a useContextMenu flag at the end. // This is a flag to show the server we know how to deal with CMs // necessary e.g. for hiding the "Save to Favorites" item Quite obviously this is not a good comment...
...or probably more generically: how do we determine whether something is a command or a query (requiring the additional params)?
Michael, apologies for taking so long to reply to this bug. On Squeezeplay we determine command vs. query by what type of action it is. A 'do' action is a command, a 'go' action is a query. There may be exceptions to that when nextWindow params are used. I will check that now.
My assessment after looking at this with Eastman is that we can remove the useContextMenu:1 flag from all queries, it seems to be of no value. I've been looking through SP code and we're not tacking on useContextMenu in most cases now. Maybe where it still stays there it's cruft, I don't know. apologies for the bug, I take full responsibility for those lines in the code. My tests show removing it has no effect other than fixing this bug.
> On Squeezeplay we determine command vs. query by what type of action it is. A > 'do' action is a command, a 'go' action is a query. Heh... good to know, thanks! > My assessment after looking at this with Eastman is that we can remove the > useContextMenu:1 flag from all queries, it seems to be of no value. We can't: if I do this, then I'd get multiple "Play all" items in eg. an artist's album list. Might be a bug in the server, not sure, but for now I'll leave it in.
Ben - the case we're talking about here doesn't use the do action, but a go. But yet the additional useContextMenu parameter causes the issue as seen in my comment #1. Any idea how this should be handled?
== Auto-comment from SVN commit #8361 to the player repo by mherger == == http://svn.slimdevices.com/player?view=revision&revision=8361 == Bug: 17100 Description: do not only not add the range parameters, but the useContextMenu item neither
== Auto-comment from SVN commit #8363 to the player repo by bklaas == == http://svn.slimdevices.com/player?view=revision&revision=8363 == Bug: 17100 Description: Change comment about useContextMenu to reflect reality