This is reproducible, the workaround is to use the web UI.  Andy notes that as serious as this appears to be, it has existed since the launch of SB Radio and does not seem to have generated a lot of complains, so I'm not going to delay the release for it, but instead give it top priority for a follow-on release.

I'm assigning this to Felix for now since Ben is out of town.  :)

I can reproduce it too, but I found that it doesn't matter whether one chooses 'Add shortcut to home menu' or 'Don't add shortcut to home menu'. After selecting either of the two the App is installed (you can check that on the Web-UI), but if one then selects 'Return to App Gallery' it gets removed again. If one selects 'Launch ...' or uses the back button the App stays installed.

LaRon, this bug seems to have been around for quite a while in Radio, have you seen it there in support?

Before selecting 'Return to App Gallery' the new app is in the JSON response and this in the log (i.e. 'from' and 'qty' are defined):

    Apr  1 09:44:08 squeezeplay: DEBUG  applet.SlimBrowser - SlimBrowserApplet.lua:698 _performJSONAction(from:0, qty:200):


After selecting 'Return to App Gallery' the new app is _not_ in the JSON response anymore and this in the log (i.e. 'from' and 'qty' _not_ defined):

    Apr  1 09:45:02 squeezeplay: DEBUG  applet.SlimBrowser - SlimBrowserApplet.lua:698 _performJSONAction(from:nil, qty:nil):


'Return to App Galley' uses a function called _hideToX() which is called if nextWindow (line 1995) is defined in function _actionHandler() in SlimBrowserApplet.lua. Later on _performJSONAction() (line 2032) is called but as stated 'from' and 'qty' are nil.

If I change the code to define 'from' and 'qty' (0, 200) for this case the installed App stays installed.

Created attachment 6729 [details]
Define 'from' and 'qty' to 0 and 200 respectively

This fixes the 'Return to App Gallery' case, but I am not sure it is the correct patch.

Ben, do you know this are of code? Does the patch look reasonable or do you think it will break other stuff? Thanks.

Update hours

hi Felix-

There's a small risk to the patch. Let me explain:

there are two types of requests sent to the server, queries and commands. queries are those requests that are expecting return data for processing, while commands take an action on the server and (typically) doesn't send things back.

queries require the from/qty in the cli command, while commands explicitly do not.

tagged cli commands can deal with an erroneous from/qty in the args, because they will just be ignored. But there are some legacy cli commands on the server side that do not use the tagged structure, and sending from and qty as the first two args to those will cause the command to fail or produce incorrect results.

in summary, if there is a cli command callback in squeezeplay that
a. is a command, not a query
b. does not use tags
c. has a nextWindow param that uses a named window (i.e., calls the _hideToX() method)

if a-c are all met, that will be a bug. My guess is that situation will never come up, but that's the risk.

Joerg uses hiding to named windows in iPeng. cc:ing him here to see if he knows if those callbacks would hit the bug I describe anywhere in iPeng. I will poke around myself in SP and the server for this.

FYI, the potential bug that I described in the last comment will not happen for anything delivered from SBS or SP.

I am not sure about mysb.com code, but my guess is that it's fine there, because tagged cli commands were the norm by the time that code was written.

So let me try to understand this:

There is some strange bug in SP that makes the App Gallery app adding not work and the workaround is to always add from/qty values to every command, is this what you are talking about?

iPeng _does_ indeed use the named "nextWindow" thing and I do also see that the App Gallery fails in the way you describe it in iPeng, too.

Am I supposed to do some change? If so, what kind of change? Add paging parameters also to any commands?

That's basically it, yes. Send the from/qty values in case the json request to be sent is a query style command that requires them (e.g, return to gallery)

Where you are using the named nextWindow param, what cli command is being issued on the named window you push back to (the json command used to create a given window is sent again to refresh the data of the named window)?

But how do I know the command requires them? So far I was using them whenever there was a "go" command, should I now also add them ... when? If a "nextWindow" parameter is present?

On the window being returned to: yes, that is being refreshed by re-sending the original query.

The question I'm asking is what is the original query? If I know what the original query is, I can make an assessment if there's an issue to worry about. My hunch is no, but I'm trying to verify before green lighting Felix's patch.

Sorry, Joerg- strike that previous comment. The json of the named window doesn't matter here. What I'm interested in is the json of the command for the action of a menu item that is tied to the named nextWindow param.

Felix, let's talk on the phone next week about this. It could be that this should be changed in the app code, not on the SP side.

Hm... Isn't that provided by the server?
I'll attach a log of what happens when I try to register mediafly.
Sorry if this should be incomplete, it's currently a bit hard for me to log cometd, the server creates several 10,000 lines of log per minute due to all my SP based players constantly disconnecting and reconnecting.

Created attachment 6750 [details]
log file

 == Auto-comment from SVN commit #8700 to the jive repo by fmueller ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8700 ==

Bug: 15960 
Description: Fix app install when returning to App Gallery

I can now select 'Return to app gallery' after install (regardless of whether I have chosen to add the icon to the home page)