SB Touch UI: Favorites refresh not correct after deletion when > 200 favorites

[darrell-k]

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",
                           },
                           ...

[darrell-k]

In case it's helpful, this is the call stack when the post-deletion @events is sent:

Slim::Web::Cometd /usr/share/perl5/Slim/Web/Cometd.pm 582 Slim::Web::Cometd::Manager::deliver_events
Slim::Web::Cometd /usr/share/perl5/Slim/Web/Cometd.pm 112 Slim::Web::Cometd::handler
Slim::Web::HTTP /usr/share/perl5/Slim/Web/HTTP.pm 484 Slim::Web::Cometd::webHandler
Slim::Networking::IO::Select /usr/share/perl5/Slim/Networking/IO/Select.pm 122 Slim::Web::HTTP::processHTTP
Slim::Networking::IO::Select /usr/share/perl5/Slim/Networking/IO/Select.pm 118 (eval)
Slim::Networking::IO::Select /usr/share/perl5/Slim/Networking/IO/Select.pm 167 Slim::Networking::IO::Select::__ANON__
Slim::Networking::IO::Select /usr/share/perl5/Slim/Networking/IO/Select.pm 167 (eval)
main /usr/sbin/squeezeboxserver 724 Slim::Networking::IO::Select::loop
main /usr/sbin/squeezeboxserver 674 main::idle
main /usr/sbin/squeezeboxserver 1211 main::main

[michaelherger]

Or worse: a bug in Squeezeplay purging the first 200 when only the second junk should be refreshed?

That's really nothing I'm familiar with. I'm only surprised this is only cropping up now... the above is for a regular Favorite, not related to Qobuz?

[darrell-k]

It happens for local favourites and Qobuz favourites.

[darrell-k]

Attached are two debug logs, log1.txt for deleting a favorite in the first 200, log2.txt for deleting a favorite > 200. You will see that they both respond to the deletion by resending the second chunk, but only the second scenario then resends the first chunk. See the final deliver_events in each log. (There is a difference in the call stack here, in the first scenario it goes through the Slim::Utils::Timers route.)

log1.txt log2.txt

[darrell-k]

I've captured the post-deletion requests from the Touch. Shows problem is on the Touch side?

When deletion is from the bottom of a list of >200 Favorites (2 requests):

[{"id":919,"data":{"request":["00:04:20:23:41:b1",["favorites","items",200,200,"menu:favorites","useContextMenu:1"]],"response":"\/7a44518a\/slim\/request"},"channel":"\/slim\/request"}]
[{"id":920,"data":{"request":["00:04:20:23:41:b1",["favorites","items",0,200,"menu:favorites","useContextMenu:1"]],"response":"\/7a44518a\/slim\/request"},"channel":"\/slim\/request"}]

When deletion is from the top of a list of >200 Favorites (1 request):

[{"id":929,"data":{"request":["00:04:20:23:41:b1",["favorites","items",200,200,"menu:favorites","useContextMenu:1"]],"response":"\/7a44518a\/slim\/request"},"channel":"\/slim\/request"}]

When deletion is from the top of a list of <200 Favorites (1 request):

[{"id":948,"data":{"request":["00:04:20:23:41:b1",["favorites","items",0,200,"menu:favorites","useContextMenu:1"]],"response":"\/7a44518a\/slim\/request"},"channel":"\/slim\/request"}]