Bugzilla – Bug 17030
menustatus updates broken
Last modified: 2011-05-14 02:20:37 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.
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.
*** This bug has been confirmed by popular vote. ***
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.
Sorry guys I'll get this fixed very soon.
== 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
Something is still broken with streaming Comet...
== 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
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.