Created attachment 2741 [details]
info screen on a favorite

*** Bug 6177 has been marked as a duplicate of this bug. ***

I've got add and delete favorites working at a satisfactory level in jive, but there's a remaining quirk that I don't know what to do about.

I put in some code to check whether the url is already a favorite, and that decides whether the menu item is 'Add Favorite' or 'Delete Favorite'. works fine.

but descend into either of those and then do that action, and you are dropped back to the parent window, as designed. BUT, that item is not updated accordingly ('add favorite' remains 'add favorite' after it's been added)

I see there being two options-- 

1. don't show 'add favorite' or 'delete favorite' on the first screen, but instead just one catch-all 'add/delete favorites'. The subsequent window can decide whether it's an 'add' or 'delete' and display those items with specific text. This kind of sucks, but the rest of the jive behavior can be the same as far as exiting to the parent window after the add/delete action.
 	
2. make the next window after adding or deleting not be the parent window (e.g., go to home or nowPlaying). This also kind of sucks, and doing this seems to kill the showBriefly that comes up for the favorites add/delete.

Can I get some guidance on this one?

Can we have a confirmation screen come up ("Cancel" and "Add Favorite" or "Remove Favorite") and then once it's chosen, have it pop out two screens so that if the user goes back in again, the new choice is there?

Richard, I need a consult on this one...

I have everything working except when a user adds/deletes a favorite in the confirmation screen and exits to the parent, the parent isn't updated.

2 examples:
...->current playlist->songinfo for track 1->add favorite
after adding the favorite, we go back to songinfo for track 1, which still has an option for adding the favorite. This should now read 'delete favorite'

Home Menu->Favorites->list of favorites->delete favorite
after deleting the favorite, we go back to the list of favorites, which still displays the favorite we just deleted.

Dean suggested going to the SlimBrowser 'grandparent' instead of the 'parent', which works except for example 2, because there is no SlimBrowser grandparent in that example (Home Menu is not a SlimBrowser menu).

So ideally what I'd like to do is have a method to re-execute the cli command that was used to create a SlimBrowser menu, and update and show the new menu accordingly. Seems non-trivial. What do you think?

updating summary to reflect remaining issue with the bug

Richard, I know your cup runneth over, so I'm just assigning this to you so it doesn't go off your radar. I'm stuck on the remaining issue, discussed in comment#5.

Just push it back to me after you can provide some input.

In theory it should be easy to refresh the menu in a SlimBrowser menu. If the request is performed again with the same sink the the menu should automatically update. The request action could be stored in _performJSONAction, and the request stored in the step. Then a _refreshJSONAction function could resend the request to SC.

The possible pitfall here is the timing of the request, old data would be displayed and then refresh. If the first part of this idea works then we can consider how to tackle that problem.

I'm close, but can't get the server request to work.

-- this is the stored JSON action for the menu I want to refresh. It is correct, IMO:

{ --[[table: 0x160ca970]]
  "tracks",
  0,
  200,
  "menu_all:1",
  "album_id:134",
  "menu:songinfo",
  "favorites_url:db:album.titlesearch=10000 Hz Legend",
  "favorites_title:10000 Hz Legend - Air",
  "textkey:1",
  "sort:tracknum",
}

but when I try to do a server request using this request table, I throw this error:

135636:8544 ERROR (RequestHttp.lua:67) - Response sink:...nches/7.0/jive/src/pkg/jive/share/jive/net/Comet.lua:826: attempt to call local 'func' (a table value)
stack traceback:
        .../7.0/jive/src/pkg/jive/share/jive/utils/coxpcall.lua:28: in function <.../7.0/jive/src/pkg/jive/share/jive/utils/coxpcall.lua:26>
        (tail call): ?
        (tail call): ?
        (tail call): ?
        ...7.0/jive/src/pkg/jive/share/jive/net/RequestHttp.lua:64: in function 'snk'
        .../branches/7.0/jive/build/osx/share/lua/5.1/ltn12.lua:262: in function 'mySink'
        ....0/jive/src/pkg/jive/share/jive/net/CometRequest.lua:135: in function 't_setResponseBody'
        .../7.0/jive/src/pkg/jive/share/jive/net/SocketHttp.lua:596: in function 'snk'
        .../branches/7.0/jive/build/osx/share/lua/5.1/ltn12.lua:277: in function 'step'
        .../7.0/jive/src/pkg/jive/share/jive/net/SocketHttp.lua:662: in function 'pump'
        ...s/7.0/jive/src/pkg/jive/share/jive/net/SocketTcp.lua:202: in function 'readPump'
        ...ches/7.0/jive/src/pkg/jive/share/jive/net/Socket.lua:143: in function <...ches/7.0/jive/src/pkg/jive/share/jive/net/Socket.lua:141>

I can post my full patch as it stands, but here is the _refreshJSONAction() function---

-- for a given step, rerun the json request that created that slimbrowser menu
local function _refreshJSONAction(step)
        if not _player then
                return
        end

        if not step.jsonAction then
                log:warn('No jsonAction request defined for this step')
                return
        end

        local playerid = _player:getId()
        if not playerid then
                log:warn('no player!')
                return
        end

        debug.dump(step.jsonAction, -1)

        _server:request(step, playerid, step.jsonAction)

end

fixed in r1790

Description: Refresh parent window after adding/deleting favorite

pass step to performJSONAction so request table can be stored in it
add _refreshJSONAction function for refreshing a menu that has a stored cli call

I had to put the cli request on a 1 sec timer because otherwise the cli command in _actionHandler was called *after* the menu was already refreshed.

Also note: the stored request will be the *last* request used to construct a menu. This has implications for menus that are constructed with multiple chunked requests.

I have to reopen this because the behavior of `delete favorite` when executed from within the favorites menu isn't acceptable.

I reload the 'parent' window after executing this command, but in this particular case the parent window is the details for the favorite. reloading the details of a deleted favorite is not recommended :(

so, what needs to happen in this case (probably for all 'delete favorite' actions) is that we go to the 'grandparent' window instead of the parent window, and reload that one.

fixed in jive r1917 and SC change 17435

after issuing a favorites delete, user is taken back to the 'grandparent' window

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html