Bugzilla – Bug 14100
context menu actions leave trail of bad screens
Last modified: 2010-05-27 14:46:42 UTC
When doing 'thumbs up' on Pandora, every time you do this action, it leaves screen artifacts in the breadcrumb trail so you have to back out once for every context action you've hit. I've only demoed this with Pandora, but is likely a broader issue related to CM and breadcrumb trail back.
Ben's on it...
sorry, once again I'm completely stymied by XMLBrowser. Andy, long ago as a "this is the best we can do" for jive we started pushing to a window after Pandora thumbs up. We don't need that window any more (the showBriefly we want though). How do I get rid of it? Maybe you can teach me to fish... the string for "Cool, we'll try to play more tracks like this" is PLUGIN_PANDORA_RATING_POSITIVE_LINE2 but nowhere in the Slim::Plugin::Pandora code is that string used. So...this comes directly from SN?
OK that menu indeed comes from SN, however it also includes the flag showBriefly => 1 which should cause it to not push. I thought we fixed this in SP a while ago and thumbs up used a showBriefly? I see code for this around line 948.
== Auto-comment from SVN commit #7370 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7370 == Bug 14100, set nextWindow => parent for Pandora trackinfo
There is an SP bug here, once that is fixed I will go through SN and add nextWindow values as needed.
Richard, I need one more set of eyes on this before I officially punt it off the P1 list because Andy and I have not been able to come to a workable solution. I'm going to ping you on this Friday and will see if you have any further wisdom. The desired behavior: play pandora stream on NP, bring up context menu select "I like this song" CM goes away showBriefly pops to screen saying "Cool, we'll play more tracks like this." The current behavior fixes everything except the showBriefly is now gone. The bug was open because a window that shouldn't be there ("trail of bad screens") is being created by the callback request. This is because it is a "go" action, which SlimBrowse always sends with a 0 200 from/qty param, which causes XMLBrowse on the SC side to in turn send back a chunked menu response, which Slimbrowse has a sink and a step for. We've stopped that behavior by adding a nextWindow => 'parent' flag to the thumbs up command. nextWindow is a way that you can have a 'go' action without forcing a step/sink chunked menu response (aka creating a new window and menu). So this gets rid of the "trail of bad screens" effectively, because the json request does not send any values for from/qty or create a sink/step for the response. But there's a bad side effect now in that the showBriefly is gone. The reason for this is that Slim::Control::XMLBrowser sends showBrieflies *through a special, single item, menu response*. Without sending a from/qty in the command, no showBriefly is sent in the response. I can fudge this by inserting 0 200 in the SlimBrowse json request, but not sending 0 200 is correct behavior for a request that isn't looking for a menu response. While many cli commands will continue to work correctly with the 0 200 in the middle of them, there is significant risk it will break some of them. some campfire discussion on it-- Ben K. We have a clear separation in the cli world of commands and queries. queries are chunked responses and take the 0 200 (or whatever) as initial from/qty params. commands, however, don't use that at all. A thumbs up/thumbs down is not really a query but only works if you treat it like one however, the nextWindow param makes the assumption (correctly) that you aren't looking for a chunked menu response, and rather are meaning to send a command. thus, no 0 200 and for everywhere else we use nextWindow, that's right. But in this case we get no showBriefly because we're delivering showBriefly in a 1-item menu, which IMO seems wrong Andy G. I built it that way so that the showBriefly was triggered after the response came back, because you could get an error message instead or even possibly a different menu that wasn't a showBriefly Ben K. without the 0 200 in the request, this loop: for my $item ( @{$subFeed->{'items'}}[$start..$end] ) { is empty and the showBriefly code is inside that item loop. so nothing
Ben I thought of a possible solution. What if we just have SC default to 0/200 if no values are provided?
== Auto-comment from SVN commit #28566 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=28566 == Fixed Bug: 14100 Description: Allow XMLBrowse queries to work when _index and _quantity are not sent in the request This is a hack fix, but a very effective one that should not impose outside risk
== Auto-comment from SVN commit #28567 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=28567 == Bug: 14100 Description: add detailed comment to hack code to describe why it was done
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.
These bugs have all been marked resolved and belong to a component which is being removed. Therefore they have been moved to the most applicable of the new components.