Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31
  1. #11
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,975
    No, there is nothing particular about "nextWindow => parent" or "nextWindow => grandparent" a lot of menus do that, for example a lot if entries in context menus.

    That's exactly the problem.
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  2. #12
    Senior Member
    Join Date
    Nov 2008
    Posts
    152
    pippin, I have a problem understanding your point.

    What's a difference between refreshing the menu and making the user go there again (thus refresh it)? Both will update exactly this menu and nothing more. I know it because I see what my plugin sends to the client.

    Reloading the menu takes as much time as loading it initially (or faster, because underlying data is already cached somewhere). If the server is of poor performance and would refresh it 20 seconds, it would also initially load it for 20 sec. or more.

    Or do you mean any memory considerations? (Ie. the client caches every menu but never frees it, and dynamic nature of the menus would screw up things?)

  3. #13
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,975
    1. Making the user go there will work. Now. Since menus that are popped from the stack are completely reloaded afterwards.
    2. It's a solution that only applies to _your_ plugin and doesn't require client to make a change that affects general performance.
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  4. #14
    Senior Member erland's Avatar
    Join Date
    Dec 2005
    Location
    Sweden
    Posts
    10,940
    Quote Originally Posted by pippin View Post
    1. Making the user go there will work. Now. Since menus that are popped from the stack are completely reloaded afterwards.

    2. It's a solution that only applies to _your_ plugin and doesn't require client to make a change that affects general performance.
    Just to make sure I understand this.

    If I understand you correctly, the issue is that currently when a context menu specifies nextWindow=parent, SqueezePlay implementations doesn't refresh the parent menu ?

    And if the SqueezePlay implementations would be changed, so they did always refresh all items in the parent menu when nextWindow=parent is specified, it would result in performance issues in a lot of other places where a full refresh isn't actually needed ?

    And currently there is no way to instruct the SqueezePlay implementation that it needs to do a full refresh of the parent menu ?

    Is that correct ?

    If it is, I can agree with your suggested solution, at least on short terms. On longer terms, it would be nice if context menus that required a full refresh could instruct the SqueezePlay implementation about this.
    Erland Isaksson (My homepage)
    (Developer of many plugins/applets (both free and commercial).
    If you like to encourage future presence on this forum and/or third party plugin/applet development, consider purchasing some plugins)

    Interested in the future of music streaming ? ickStream - A world of music at your fingertips.

  5. #15
    Senior Member
    Join Date
    Nov 2008
    Posts
    152
    Quote Originally Posted by pippin View Post
    1. Making the user go there will work. Now. Since menus that are popped from the stack are completely reloaded afterwards.
    I'm just trying to add menu IDs and will try to say nextWindow=id, then see if this would reload the menu.

    2. It's a solution that only applies to _your_ plugin and doesn't require client to make a change that affects general performance.
    I still have no idea what is this issue with general performance...

    Quote Originally Posted by erland View Post
    Just to make sure I understand this.

    If I understand you correctly, the issue is that currently when a context menu specifies nextWindow=parent, SqueezePlay implementations doesn't refresh the parent menu ?

    And if the SqueezePlay implementations would be changed, so they did always refresh all items in the parent menu when nextWindow=parent is specified, it would result in performance issues in a lot of other places where a full refresh isn't actually needed ?

    And currently there is no way to instruct the SqueezePlay implementation that it needs to do a full refresh of the parent menu ?

    Is that correct ?

    If it is, I can agree with your suggested solution, at least on short terms. On longer terms, it would be nice if context menus that required a full refresh could instruct the SqueezePlay implementation about this.
    Saying 'parent' or 'grandparent' does refresh (well, except of the bug in questions if there are many items) and it is supposed to do so.

    If one doesn't want to have a refresh, there's 'parentNoRefresh' available (but grandparentNoRefresh seems to be missing). See

    http://wiki.slimdevices.com/index.ph...Play_interface
    (search for parent or nextWindow).

    Overall, either I'm missing something or need it to be explained in more details.

  6. #16
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,161
    Erland, you got it right.

    Right now almost every context menu uses parent or grandparent (which have the semantic to refresh) to close it. The option 'parentnorefresh' is not used a lot (if at all).

    So if someone would fix the implementation a lot of places everywhere in SqueezePlay would be affected (to the worse).
    So just fixing the client wouldn't help you had to do full review of all menu related code in the server.
    Did you know: SqueezePlayer will stream all your music to your Android device. Take your music everywhere!
    Remote Control + Streaming to your iPad? Squeezebox + iPad = SqueezePad
    Want to see a Weather Forecast on your Radio/Touch/Controller ? => why not try my Weather Forecast Applet
    Want to use the Headphones with your Controller ? => why not try my Headphone Switcher Applet

  7. #17
    Senior Member
    Join Date
    Nov 2008
    Posts
    152
    Quote Originally Posted by bluegaspode View Post
    Erland, you got it right.

    Right now almost every context menu uses parent or grandparent (which have the semantic to refresh) to close it. The option 'parentnorefresh' is not used a lot (if at all).

    So if someone would fix the implementation a lot of places everywhere in SqueezePlay would be affected (to the worse).
    So just fixing the client wouldn't help you had to do full review of all menu related code in the server.
    Well, I see your point. But the thing is, it DOES refresh now, if you use 'parent' or 'grandparent'. It just doesn't do this properly if there are too many items (and this is a rare case). So what would be worse when this would be fixed?

  8. #18
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,975
    Yes, but if you've got an 10.000 albums menu on a ReadyNAS it currently only refreshes 200 of these when you close a context menu while with your "fix" you'd be in for a nice cup of coffee or two until your server stops working under heavy load.
    Add CustomBrowse et al and we are talking about serious performance hits on all levels.

    I have never seen an instance of parentnorefresh.

    This change is not a good suggestion.
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  9. #19
    Senior Member
    Join Date
    Nov 2008
    Posts
    152
    Quote Originally Posted by pippin View Post
    Yes, but if you've got an 10.000 albums menu on a ReadyNAS it currently only refreshes 200 of these when you close a context menu while with your "fix" you'd be in for a nice cup of coffee or two until your server stops working under heavy load.
    Add CustomBrowse et al and we are talking about serious performance hits on all levels.

    I have never seen an instance of parentnorefresh.

    This change is not a good suggestion.
    OK, I see your point now.

    Summarizing, we have two bugs.

    Bug #1 causes the menus to be refreshed if any context menu action is used, even if it's not needed. That's because 'parent' is used everywhere instead of parentNoRefresh all around the server code.

    But #2 causes only one chunk of data to be refreshed during menu refresh, which makes the performance impact of the first bug less terrible on big menus. But this prevents me and other developers from creating plugins with dynamic menus with more than 100 items (for iPeng) or 200 items (for Squeezeplay).

    Still I vote for fixing both of them.

    Any Logitech developer to comment on these issues?

  10. #20
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,975
    I'd vote for #3, which I believe is the only realistic one:
    Add new "parentrefreshall", "refreshall", "grandparentrefreshall" qualifiers for nextWindow.

    I could volunteer to add these to the next version of iPeng but they would only be of use once SqueezePlay also support them (unless you use the usterInterfaceIdiom = iPeng qualifier iPeng sends to differentiate the behavior).
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •