hopefully this will be a quick fix...

Couple of notes:

first try for context menu on a Pandora track via Now Playing screen is blank
second try yields the correct menu

this is the command for "Thumbs up" that's being sent and is failing:

{ --[[table: 0x16de89b0]]
  "trackinfo",
  "items",
  0,
  200,
  "type:link",
  "menu:trackinfo",
  "favorites_url:http://www.test.squeezenetwork.com/api/pandora/v1/opml/trackinfo/rate?trackId=5e40e780066610b5917932f3c978080c40c316d7702a805756ccaee4eba0193fe0519e1b73245a3f&stationId=92769322246837542&rating=0",
  "item_id:4e08ef85.1",
  "favorites_title:I don't like this song",
  "useContextMenu:1",
}
20090828 21:38:42.178 WARN   net.comet - Comet.lua:874 Comet {mediumspicy}: _response, /slim/request id=21 failed: request failed with error: Bad params!

I'm seeing the same with Last.FM, except that even subsequent presses fail. Painful when "Recommended Station" is playing "Just gotta love christmas" by Peter Cetera...

Heh... the count again?

Sep  3 17:26:45 squeezeplay: ERROR  net.http - RequestHttp.lua:67 Response sink:/usr/share/jive/applets/SlimBrowser/DB.lua:106: chunk must have count field
Sep  3 17:26:45 squeezeplay: stack traceback:
Sep  3 17:26:45 squeezeplay: 	[C 0x4e305]: in function '_assert'
Sep  3 17:26:45 squeezeplay: 	/usr/share/jive/applets/SlimBrowser/DB.lua:106: in function 'updateStatus'
Sep  3 17:26:45 squeezeplay: 	/usr/share/jive/applets/SlimBrowser/DB.lua:172: in function 'menuItems'
Sep  3 17:26:45 squeezeplay: 	...share/jive/applets/SlimBrowser/SlimBrowserApplet.lua:374: in function '_stepSetMenuItems'
Sep  3 17:26:45 squeezeplay: 	...share/jive/applets/SlimBrowser/SlimBrowserApplet.lua:1134: in function 'sink'
Sep  3 17:26:45 squeezeplay: 	...share/jive/applets/S

Count is reading as zero because the response data from Pandora for the context menu is ridiculously slow, many seconds at least.

Initial request/response looks like this, with the response blank. Then after a long wait I see a response with data, but Squeezeplay has already balked and showed an empty CM window. After the data from SC finally returns, it is possible to close and open the CM window again and the items are there.

[09-09-04 15:31:42.3960] Slim::Web::Cometd::handler (143) Cometd request: [
  {
    channel => "/slim/request",
    data => {
          request  => [
                        "00:04:20:1e:00:8b",
                        [
                          "contextmenu",
                          0,
                          200,
                          "playlist_index:0",
                          "menu:track",
                          "context:playlist",
                          "useContextMenu:1",
                        ],
                      ],
          response => "/b62412f9/slim/request",
        },
    id => 38,
  },
]
[09-09-04 15:31:42.4008] Slim::Web::Cometd::handleRequest (822) Request for /b62412f9/slim/request / 38 is not async
[09-09-04 15:31:42.4016] Slim::Web::Cometd::Manager::deliver_events (214) Sending event on channel /b62412f9/slim/request to b62412f9
[09-09-04 15:31:42.4028] Slim::Web::Cometd::Manager::deliver_events (228) Delivering events to b62412f9:
[
  {
    channel => "/b62412f9/slim/request",
    data => {},
    ext => { priority => "" },
    id => 38,
  },
]
[09-09-04 15:31:42.4036] Slim::Web::Cometd::sendHTTPResponse (669) Sending Cometd chunk:
[{"data":{},"id":"38","channel":"/b62412f9/slim/request","ext":{"priority":""}}]
[09-09-04 15:31:42.4047] Slim::Web::Cometd::sendHTTPResponse (662) Sending Cometd Response:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 73
Content-Type: application/json
Expires: -1

[{"clientId":null,"id":"38","channel":"/slim/request","successful":true}]

Ben K.	
Andy, I'm investigating the blank context menu with Pandora bug...what I'm seeing is that the response data comes back super slow (many seconds), but it does eventually come back. What this means is that the first time you bring the context menu up for a pandora NP screen it's blank, but works after that. Does this make any sense? Why would it delay like that?

Andy G.	
usually a delay like that can mean memcached isn't working

Ben K.	
I wasn't aware we were using memcached for stuff like this
is there anything further I can do to investigate/fix?

Andy G.	
yeah otherwise it has to re-login to Pandora for every request
what's your timeout?

Ben K.	
timeout for what? the contextmenu?

Andy G.	
yeah before you show a blank window

Ben K.	
problem is that a response is sent back immediately and it has no data. squeezeplay balks because it can't setup a menu renderer without count information
so it's not actually hitting a timeout, it's failing

Andy G.	
hmm ok that sounds like a bug

Ben K.	
View paste 
[09-09-04 15:31:42.4028] Slim::Web::Cometd::Manager::deliver_events (228)
Delivering events to b62412f9:
[
  {
    channel => "/b62412f9/slim/request",
    data => {},
    ext => { priority => "" },
    id => 38,
  },
]
that's what causes SP to barf

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

Fixed bug 13744, support async requests made via contextmenu

This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.