Problem with Jive / nextWindow - bug in SBS?

[azaz44]

Hi there. I have another problem with JIVE.

I have a menu created with a command (not sure if there's any other way to create dynamic menus) and it has submenus. In a submenu I want to execute the action which changes some pref, go back to the previous menu (or two of them) and refresh it.

I do it this way (action of some submenu item).

actions => {
	do => {
		cmd => [ ... ],
		nextWindow => 'parent',
		params => {
			context => $context,
		},
	},
},

Or I use 'grandparent' if I want to go two menus back.

Specifying 'parent' or 'grandparent' in nextWindow causes it to go to this menu and refresh it, as stated in the wiki.

And the problem is, this works fine as long, as the menu (the one to refresh) was read in one chunk. At my system Squeezeplay reads the menu in chunks per 200 items (every query for JIVE has to support this kind of reading). And now, if the menu is longer then 200 items, only items above 200 are refreshed. My guess is, only the last 'read-chunk' command is executed.

Am I doing something wrong or is this a bug? If a bug, server-side or client-size?

I also tested on iPeng, this also behaves wrong, but different - it refreshes first 100 of items (iPeng reads in chunks of 100).

I think I also got SqueezePlay refresh only first 200 items each time (which would be similar to iPeng and would suggest it's a server-side isssue), but I cannot reproduce it anymore.


--------------------------------
UPDATE
I tried on the Radio as well - behaves same as SqueezePlay - same bug, also uses 200 items chunks.

I also reproduced this other behaviour on it. It is this way:
- I go to the menu, there are over 220 items.
- I go to submenu, and execute it.
- it goes back to the menu, only last 20 items are refreshed.
- now I go back to the parent of this menu, and then go to the menu again.
- now it reads first 200 items and the whole menu is displayed correctly. The last 20 items are not refreshed, but they are fine (refreshed before).
- from this point, when using submenu action, it will always refresh first 200 items and leave the rest unrefreshed. (again, probably because it was the last command used to build this menu).

[bluegaspode]

This is not consistent, but there are rarely menus that even need a refresh.
For instance reloading the full albums or artist menu when returning from any-context menu there wouldn't make sense as well (and those context menus just use 'parent' and 'grandparent' if I remember correctly).

So first someone would need to send 'parentnorefresh' or (not existing) 'grandparentnorefresh' all the time before one would implement correct behaviour with paging for full lists.

Actually a refresh is only needed in the alarm menu, favourites and playlist. These are all menus with less then 20 entries.
That's why noone bothered to care for paging at all I guess.

In my opinion there shouldn't be a need to refresh a list of >200 items when returning from a command or context-menu.
This would be a usability nightmare anyway.

[erland]

In my opinion there shouldn't be a need to refresh a list of >200 items when returning from a command or context-menu.
This would be a usability nightmare anyway.

Depends on what the context menu does, as an example, it would make a lot of sense if there was a context menu that selected a different sorting order. I don't think there is a sorting order context menu at the moment but I could see this happening in the future.

[azaz44]

That's exactly what I do - one of my menus is changing sorting order. I don't see any other place to put it, which would as easy to find and so convenient to use.

I also need to have so many entries sometimes. I could split the menu for some players, but scrolling 200 items works just perfectly on iPeng (scrolling is just great), Boom and Radio (wheel), and I guess Touch as well (touch-scrollbar).

Even squeezebox classic would handle it perfectly, if the list would be something which is letter-based, because one can select first letter with a remote.

[pippin]

I agree with bluegaspode, let's state this more pointed:

You.Must.Not.Require.Refreshes.Of.Huge.Menus

Anything else will hurt performance too badly.

iPeng, btw, DOES refresh the whole menu if it finds changes in the first 100 items, I believe
--
EDIT: Reading you last post: obviously not
--
but continuously updating lists with thousands of items - which can take minutes on some servers - is definitely not a good idea.

If you really, really need it, pop enough menus from the stack that the user has to enter a previous menu again, this will always refresh the whole menu, I believe.

[azaz44]

Guys, I don't think 200 items is what constitutes to a HUGE menu.
They just load in one second over my WiFi network, this includes a database query.

We have 200 cantatas of Bach, 104 symphonies of Haydn, over 50 of Mozart - these are just normal numbers. I bet you can even find some CDs with 100 tracks...

[erland]

but continuously updating lists with thousands of items - which can take minutes on some servers - is definitely not a good idea.

If you really, really need it, pop enough menus from the stack that the user has to enter a previous menu again, this will always refresh the whole menu, I believe.

If you have a sorting option context menu, why would I want to pop more menus from the stack when I know the user wants to get into the menu where he was ?

Is it better to move out of the menu and ask the user to enter it than just asking for an automatic refresh ?

[pippin]

Guys, I don't think 200 items is what constitutes to a HUGE menu.
They just load in one second over my WiFi network, this includes a database query.

This depends on the server.
You can also transfer 20.000 items over WiFi in 1s. But it can take a slow server ten minutes to process them.

I bet you can even find some CDs with 100 tracks...

I have one with more than 1.000 tracks.
That's not the point. The point is, that the menu refresh, once it is being done for more than one page for _your_ menu would have to be done for all pages for _any_ menu and that can have really, really bad impact on performance. This is what bluegaspode wanted to say with his "norefresh" statements, I believe.

I'd recommend to step out one more page and have the user re-enter the menu to refresh it.
Are you aware you can name pages and use that name as a "nextWindow" parameter?

[pippin]

If you have a sorting option context menu, why would I want to pop more menus from the stack when I know the user wants to get into the menu where he was ?

Because it means you don't have to do a change to the clients which will potentially dramatically impact their performance on all other pages.

[erland]

Because it means you don't have to do a change to the clients which will potentially dramatically impact their performance on all other pages.

Maybe I'm just tired, but I don't understand what you are trying to say.

Doesn't the refresh only happen in the menus that have this particular context menu item and only after the user has selected this particular context menu item ?

If the user has selected a context item which sets another sorting order, the user always wants the menu to be refreshed, so I don't understand why it shouldn't be done automatically.