Problem with Jive / nextWindow - bug in SBS?

[pippin]

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.

[azaz44]

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?)

[pippin]

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.

[erland]

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.

[azaz44]

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...

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.

[bluegaspode]

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.

[azaz44]

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?

[pippin]

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.

[azaz44]

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?

[pippin]

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).