Bug 17030 - menustatus updates broken
: menustatus updates broken
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 7.5.4
: PC Other
: P1 critical with 8 votes (vote)
: 7.5.x
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-06 06:44 UTC by Stefan Hansel
Modified: 2011-05-14 02:20 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Hansel 2011-03-06 06:44:02 UTC
Andy, I realize you did a lot of changes in cometd-code in the last week (starting on 25.02).
Since last week users also report severe problems with SqueezePlay menus running iPeng or SqueezePad together with 7.5.4 or 7.6.x nightlies.

I did install 7.5.4 - r31995 now (on a Mac) and realize that the server indeed doesn't send any menuupdates to the clients any more.
This can be reproduced with SqueezePlay as well: if you try to turn on/off a SqueezeBox via the Controller then the menuitem-text ("turn XYZ on/off") does not update anymore. Guess other menuitems are affected as well.

SqueezePad and iPeng don't issue a direct menu request ("menu 0 100 direct:1") to retrieve the initial menu like SqueezePlay but instead expect the menu to be send via the "menustatus" subscription on the channel "/slim/menustatus".  Nothing arrives on this channel anymore (neither the initial menu nor any updates), so neither SqueezePad nor iPeng is able to render any menuitem.

It's easy of course to use a "menu 0 100 direct:1" request to retrieve the initial menu and I'm also willing to change my code if needed.
But with the missing menuupdates I'm a bit reluctant yet to submit any codechange to Apple as maybe this is a more fundamental problem in your current changes.

---
After digging deeper in the code, I think the problem starts in CometD.pm:requestCallback (line 942).
In my logs I can see the line
"[11-03-06 15:31:16.6560] Slim::Web::Cometd::requestCallback (947) requestCallback got results for /3e03aa69/slim/menustatus/c8:bc:c8:97:98:5b / 4"

This refers to a menustatus-request (id:4) issued earlier:
[ {  channel => "/slim/subscribe",
    data => {
          request  => ["c8:bc:c8:97:98:5b", ["menustatus"]],    response => "/3e03aa69/slim/menustatus/c8:bc:c8:97:98:5b",
      },  id => 4,  }, ]

So the server still wants to send an event to the subscription, which is just not delivered. I can see that in this method you also did a change, trying to batch some responses. Guess this is where one should start to look if the batching actually works.
Comment 1 Stefan Hansel 2011-03-06 07:19:13 UTC
rolling back the changes done in 7.5.4 r31961	

"Fix bug where multiple comet callbacks can be triggered by a single event such as 'power', both results are now sent together"

fixes the bug for me.
Comment 2 Mike 2011-03-06 08:14:25 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Joerg Schwieder 2011-03-08 15:21:49 UTC
This bug is getting annoying on the service side of things!

Andy, have you seen Stefan's proposed fix here:
http://forums.slimdevices.com/showpost.php?p=615856&postcount=576

Just to add here for the record:
The diagnosis that batching changes up causes the issues matches what I see in the logs:
Actually updates that should go to different clients are being batched up so only one gets alls the updates, the others don't.
Comment 4 Andy Grundman 2011-03-08 15:34:45 UTC
Sorry guys I'll get this fixed very soon.
Comment 5 SVN Bot 2011-03-08 19:07:54 UTC
 == Auto-comment from SVN commit #32020 to the slim repo by agrundman ==
 == http://svn.slimdevices.com/slim?view=revision&revision=32020 ==

Fixed bug 17030, request->connectionID is not always available, so cannot use it for event queue
Comment 6 Andy Grundman 2011-03-09 06:46:54 UTC
Something is still broken with streaming Comet...
Comment 7 SVN Bot 2011-03-09 11:36:10 UTC
 == Auto-comment from SVN commit #32040 to the slim repo by agrundman ==
 == http://svn.slimdevices.com/slim?view=revision&revision=32040 ==

Fixed bug 17030, turns out connectionID is actually needed for something
Comment 8 Joerg Schwieder 2011-05-14 02:20:37 UTC
I'm sorry, but I'm still seeing this.

I'm getting reports from users, especially with ReadyNAS and I've seen it myself a few times in 7.6 trunk (which seems to be not 100% identical to onebrowser right now).

I've seen this with iPeng SqueezePad and my Controller.

It's not a permanent but infrequent issue (for me) and in iPeng it goes away when you switch players (which will make iPeng re-subscribe to menustatus updates and re-request the main menu), I had to restart SqueezePad and I believe I rebooted the Controller, but I'm not sure, I may have done a server restart instead.