slimserver
slimserver copied to clipboard
SB Touch UI: Favorites refresh not correct after deletion when > 200 favorites
When the user has > 200 favorites, after deleting one of the first 200, the list refreshes with the first 200 entries blank. Scroll down and you'll see that entries 201 onwards are present.
Note: This behaviour can be avoided if you scroll down to the bottom of the list first, then back up to the top, before initiating the deletion.
The problem seems to be in Slim::Web::Cometd::Manager::deliver_events
- the favourites are loaded in two chunks, but after deletion is confirmed, the list is refreshed only from the second chunk. Here is the item_loop sent after deletion, which can be seen to start at item_id 200. This results in 200 empty items being loaded ahead of this.
item_loop => [
{
goAction => "playControl",
"icon-id" => "/music/34fc5898/cover",
params => { isContextMenu => 1, item_id => 200 },
playControlParams => { "xmlbrowserPlayControl" => 200 },
presetParams => {
favorites_title => "Rachmaninoff: Piano Concerto No. 3 - Prokofiev: Piano Concerto No. 3",
favorites_type => "audio",
favorites_url => "qobuz:album:0886443943612",
icon => "/music/34fc5898/cover",
},
text => "Rachmaninoff: Piano Concerto No. 3 - Prokofiev: Piano Concerto No. 3",
type => "audio",
},
{
goAction => "playControl",
"icon-id" => "/music/4610cf8e/cover",
params => { isContextMenu => 1, item_id => 201 },
playControlParams => { "xmlbrowserPlayControl" => 201 },
presetParams => {
favorites_title => "Rachmaninoff: Piano Concertos Nos. 2 & 3",
favorites_type => "audio",
favorites_url => "qobuz:album:lg239m0x1kz7b",
icon => "/music/4610cf8e/cover",
},
text => "Rachmaninoff: Piano Concertos Nos. 2 & 3",
type => "audio",
},
...